MySQL 主从复制工作流程深度解析

MySQL 主从复制是实现数据冗余、容灾和负载分担的核心机制，其工作流程涉及底层日志记录、网络传输、事件执行等多个环节。以下从初始化阶段、增量同步阶段、关键线程协作三个维度，详细拆解主从复制的完整工作流程。

一、初始化阶段：从库数据基线构建

主从复制的前提是从库获取主库的初始数据副本，该阶段决定了复制链路的起点，具体流程如下：

1. 主库配置准备
   • 启用 Binlog 日志：在my.cnf中配置log_bin=mysql-bin，并设置唯一的server_id（如主库设为 1，从库设为 2）。
   • 记录当前 Binlog 位置：执行FLUSH TABLES WITH READ LOCK;锁定所有表，然后通过SHOW MASTER STATUS;获取当前 Binlog 文件名（如mysql-bin.000001）和偏移量（如 154）。
2. 从库数据初始化
   • 方式一：物理备份（推荐）
     使用mysqldump全量备份主库数据，通过mysql -h slave_host导入从库，确保数据一致性。
   • 方式二：逻辑复制（适用于小数据量）
     从库执行CHANGE MASTER TO命令，指定主库地址、端口、复制账号及初始 Binlog 位置：
     sql

      

      

     CHANGE MASTER TO
     MASTER_HOST='master_ip',
     MASTER_PORT=3306,
     MASTER_USER='repl_user',
     MASTER_PASSWORD='repl_pass',
     MASTER_LOG_FILE='mysql-bin.000001',
     MASTER_LOG_POS=154;
     

      
3. 主库解锁与复制启动
   • 主库执行UNLOCK TABLES;释放锁，从库执行START SLAVE;启动复制线程，正式建立主从连接。

二、增量同步阶段：实时数据同步流程

初始化完成后，主从复制进入持续增量同步阶段，该阶段通过三大核心线程协作实现数据同步：

1. 主库 Binlog Dump 线程：事件发送

• 触发条件：主库接收到 DML（INSERT/UPDATE/DELETE）或 DDL（CREATE/TABLE）操作时，将变更记录到 Binlog。
• 工作流程：
  1. 主库按事务顺序将 Binlog 事件封装成数据包（Packet）。
  2. 监听从库 I/O 线程的连接请求，建立 TCP 连接后发送 Binlog 事件。
  3. 保持长连接，持续推送新产生的 Binlog 事件，直至从库 I/O 线程断开。

2. 从库 I/O 线程：事件抓取与缓存

• 核心职责：从主库拉取 Binlog 事件并写入中继日志（Relay Log）。
• 工作流程：
  1. 连接主库 Binlog Dump 线程，发送请求获取最新 Binlog 事件。
  2. 接收 Binlog 数据包，解析后写入本地中继日志（如relay-bin.000001）。
  3. 记录当前中继日志位置（Relay Log Position），用于故障恢复时定位断点。

3. 从库 SQL 线程：事件执行与数据应用

• 核心职责：读取中继日志并在从库执行，确保数据与主库一致。
• 工作流程：
  1. 监控中继日志文件更新，读取新写入的 Binlog 事件。
  2. 将事件转换为 SQL 语句（如基于行复制的 Event 会被解析为具体 SQL）。
  3. 在从库执行 SQL，更新数据并记录执行位置（Exec_Master_Log_Pos）。

三、关键流程细节与机制解析

1. Binlog 格式对复制的影响

• 基于语句复制（Statement-Based Replication, SBR）
  • 记录 SQL 语句文本，优点是日志量小，缺点是可能因函数（如 NOW ()）或存储过程导致主从数据不一致。
• 基于行复制（Row-Based Replication, RBR）
  • 记录行数据变更前后的镜像，优点是一致性高（如 UPDATE 只记录变更行），缺点是日志量大。
• 混合模式（Mixed-Based Replication, MBR）
  • MySQL 默认模式，自动选择 SBR 或 RBR：简单语句用 SBR，复杂语句用 RBR。

2. 中继日志（Relay Log）的作用

• 解耦主从依赖：即使主库宕机，从库仍可通过中继日志继续执行未完成的事件。
• 断点续传：当复制链路中断后，从库从中继日志记录的位置重新拉取 Binlog，避免全量同步。

3. 复制状态监控关键点

通过SHOW SLAVE STATUS\G命令可查看核心状态：

• Slave_IO_Running和Slave_SQL_Running：均为Yes表示复制正常。
• Seconds_Behind_Master：复制延迟时间（理想值为 0，高并发场景可能短暂升高）。
• Master_Log_File与Read_Master_Log_Pos：从库当前读取的主库 Binlog 位置。

四、异常场景下的流程处理

1. 主库宕机后的流程切换

1. 确认主库不可恢复，选择一个从库（如延迟最低的）提升为主库：

   STOP SLAVE;
   RESET MASTER;  -- 清除中继日志，成为新主库
   

    
2. 其他从库修改复制配置，指向新主库：

   CHANGE MASTER TO MASTER_HOST='new_master_ip'...;
   START SLAVE;
   

    

2. 复制延迟过高的处理流程

• 定位延迟原因：
  1. 检查从库负载（如 CPU/IO 是否瓶颈），可能需增加从库资源或拆分读负载。
  2. 查看主库 Binlog 生成速度是否超过从库执行能力（如大事务导致中继日志堆积）。
• 优化措施：
  • 启用从库多线程复制（MySQL 5.6 + 的 MTS 机制），并行执行不同库的事件。
  • 调整slave_parallel_workers参数（默认 0，建议设为 CPU 核心数的 1-2 倍）。

五、GTID 模式下的复制流程优化

MySQL 5.6 引入的全局事务标识符（GTID）简化了复制流程：

1. GTID 工作原理：每个事务在主库生成唯一的GTID=server_id:transaction_id，随 Binlog 传递到从库。
2. 流程优化点：
   • 无需手动指定 Binlog 位置，从库通过CHANGE MASTER TO MASTER_AUTO_POSITION=1自动定位事务起点。
   • 主从切换时，新从库可通过 GTID 直接找到未同步的事务，避免传统流程中的手动定位。

总结：主从复制全流程架构图

 

主库(Master)                              从库(Slave)
+----------------+     +----------------+     +----------------+
| 应用写入操作   |---->| Binlog Dump线程 |---->| I/O线程        |
| 记录到Binlog   |     | 发送Binlog事件  |     | 写入中继日志   |
+----------------+     +----------------+     +----------------+
                                                     |
                                                     v
                                             +----------------+
                                             | SQL线程        |
                                             | 执行中继日志   |
                                             +----------------+
                                                     |
                                                     v
                                               从库数据更新完成

 

 

主从复制的核心本质是通过 “日志记录 - 传输 - 重放” 的三段式流程，实现主从节点的数据一致性。理解该流程中的每个环节（从初始化的基线同步到增量阶段的线程协作），是优化复制性能、解决同步故障的基础。在实际应用中，结合 GTID、多线程复制等机制，可进一步提升主从架构的可靠性与效率。