MySQL主从复制是指将一个MySQL实例（主库，Master）上的数据变更，通过日志机制同步到另外一个或多个MySQL实例（从库，Slave）上的过程。搭建主从架构后，主库一般承担写操作和核心读操作，从库主要承担读请求，从而在业务量增长时实现读写分离与负载分担。
一、主从架构的基本组成
主从架构最基础的形式是一主一从，但在生产环境中常见一主多从，甚至级联复制（从库下面再挂从库）。主库负责接收客户端的写请求，所有会改变数据的操作，例如INSERT、UPDATE、DELETE以及DDL语句，都会以特定格式记录在二进制日志（binlog）中。
从库则扮演数据消费者的角色。它内部有三个关键线程协同工作：I/O线程负责连接主库并拉取binlog；SQL线程负责读取本地的中继日志（relay log）并执行其中的事件；在多线程复制场景下还会有工作线程来并行回放。通过这样的分工，从库能够在主库不停机的情况下，逐步追上主库的数据状态。
二、主从复制的核心原理
复制流程可以概括为三个步骤。第一步，主库提交事务时，把变更写入binlog并刷盘；第二步，从库I/O线程请求主库dump线程发送binlog内容，主库dump线程读取binlog推送给从库，从库接收后写入本地relay log；第三步，从库SQL线程读取relay log中的事件，在本地执行，从而得到与主库一致的数据。
这种机制本质上是“日志重放”，而非直接同步数据文件。因此从库的数据是异步追赶得到的，主从之间天然存在一定延迟。下面是一段简化的主库配置示例，用于开启binlog并设定服务ID：
-- 主库 my.cnf 核心配置 [mysqld] server-id=1 log-bin=mysql-bin binlog-format=ROW
从库则需要指定主库地址、账号，并启动复制线程，示例语句如下：
-- 从库执行 CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='repl_pass', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; START SLAVE;
三、复制模式与数据一致性
MySQL支持异步复制、半同步复制和全同步复制。默认异步复制下，主库提交事务后立刻返回客户端成功，不等待从库接收，性能最高但可能丢数据。半同步复制要求主库提交时至少收到一个从库已接收relay log的确认，平衡了性能与安全性。
不同模式适用不同业务。例如订单类强一致场景可启用半同步，而日志统计类从库可用异步。需要特别注意的是，即使开启半同步，从库SQL线程执行仍可能落后，所以应用程序不能假设从库读取一定看到最新写入，否则会出现脏读错觉。
| 复制模式 | 主库等待条件 | 数据丢失风险 | 性能影响 |
|---|---|---|---|
| 异步复制 | 不等待从库 | 高 | 低 |
| 半同步复制 | 至少一个从库接收 | 较低 | 中 |
| 全同步复制 | 所有从库执行完 | 极低 | 高 |
四、主从架构的常见用途与误区
主从架构最常见的价值是读写分离与冷热备份。把报表查询、搜索索引构建等重读操作路由到从库，能显著降低主库压力。同时从库可作为逻辑备份源，避免在主库直接跑mysqldump影响线上。
但一个典型误区是把从库当作实时镜像用于金融扣款后的立即余额校验。由于复制延迟，刚写入主库就从从库查可能查不到。正确做法是对这类请求强制走主库，或引入一致性读中间件。此外，从库并非越多越好，过多从库会加重主库dump线程负担，应根据实际读负载规划数量。
五、排查复制异常的基础思路
当从库数据停止更新，首先应查看SHOW SLAVE STATUSG中的Slave_IO_Running与Slave_SQL_Running字段。若为No，说明线程异常；Last_Error会给出具体SQL报错，例如主键冲突或表不存在。
如果是网络闪断导致I/O线程断开，从库会自动重试连接。若是SQL线程因数据不一致报错，轻量修复可用跳过事务，但生产环境更推荐通过pt-table-checksum等工具比对差异再补齐，避免盲目跳过造成长期数据漂移。
-- 查看从库状态关键字段 SHOW SLAVE STATUSG -- 临时跳过错误事务（仅测试环境建议） SET GLOBAL sql_slave_skip_counter=1; START SLAVE;
理解主从复制的基本概念与原理，是设计MySQL高可用体系的第一步。只有清楚日志流向、线程职责和延迟来源，才能在故障时快速定位，在扩容时合理规划，让主从架构真正提升系统的稳定与吞吐能力。