MySQL 主从复制全解析：从基础原理到高级实战简介（附架构图）

本文将带你系统性梳理 MySQL 主从复制的核心机制与高级特性，涵盖：

• ✅ 复制原理

• ✅ 五种复制模式（异步/半同步/增强半同步/组复制等）

• ✅ 级联复制、延迟复制、多源复制

• ✅ 点位复制 vs GTID 复制

• ✅ 生产常见问题与避坑指南

如上图所示，主库及从库中涉及的组件主要做如下动作：

1.1 主库的记录与发送：Binlog 与 Dump 线程

• 二进制日志 (Binlog): 这是复制的基石。主库上任何修改数据的SQL语句（如INSERT, UPDATE, DELETE）都会按顺序被记录到Binlog中。Binlog有三种格式，默认是基于语句的复制 (SBR)，记录SQL本身，日志量小但某些函数可能导致主从不一致；基于行的复制 (RBR) 记录每行数据的变化，更安全但日志量大；混合模式复制 (MBR) 由MySQL自动选择最佳格式。

• Log Dump 线程: 当从库连接后，主库会为每个从库创建一个专用的Log Dump线程。这个线程负责“盯住”Binlog，一旦有新的内容，就主动推送给从库的I/O线程。

1.2 从库的接收与重放：I/O 线程和 SQL 线程

• I/O 线程: 它负责与主库的Dump线程通信，接收Binlog内容，并将其顺序写入到从库本地的中继日志 (Relay Log) 中。这种设计将数据获取和数据应用解耦，即使SQL线程执行慢，I/O线程也能先快速拉取并保存最新日志。

• SQL 线程: 这是真正干活儿的线程。它会不间断地读取Relay Log中的指令，解析成SQL语句并在从库上顺序执行，从而保持数据同步

根据主库事务提交后等待从库确认的策略可分为异步复制、半同步（增强半同步）复制、全复制，后面新增了组复制（MGR）。

异步复制是最常见也是默认的复制模式。主库不需要等待任何从库确认就完成事务提交，这使得性能最高，但牺牲了一定程度的数据一致性，当主库宕机后从库可能丢失未同步的数据。

• 半同步复制要求至少一个从库确认已接收到并持久化了二进制日志后，主库才认为事务提交成功。这种方式提高了数据的安全性，但也可能导致一定程度的延迟。

• 增强版的半同步复制确保在事务被提交前，至少有一个从库已经确认接收到了事务的日志。这种模式提供了更高的数据一致性保证。

半同步或增强半同步需要安装插件，模式根据参数rpl_semi_sync_master_wait_point = AFTER_SYNC、AFTER_COMMIT控制

全同步指的是所有节点必须全部确认才能提交（类似 Galera Cluster）。这个模式性能极低，一般不用于生产。MySQL原生不支持全同步模式，所以后续出现了组复制。

MySQL 5.7引入的组复制是一种基于Paxos协议的多主复制解决方案，支持单主或多主模式，自动处理故障转移和冲突检测，提供更强的一致性和高可用性

级联复制适用场景如下：

• 跨机房/跨地域部署：主库在中心机房，中继从库在区域机房，再分发给本地应用

• 减轻主库压力：避免大量从库直连主库，导致主库 I/O 或网络带宽瓶颈

• 分层读扩展：核心业务读中继从库，边缘业务读叶子从库

从库故意延迟一段时间再应用主库的二进制日志，提供一个人为的数据恢复窗口，防止误操作。

延迟复制就像一个“时间胶囊”。当主库发生误操作（如误删重要数据），在延迟时间内，从库上的数据还未被更新。这时可以立即停止从库的复制，将其作为正确数据的来源，快速恢复主库数据。其本质是SQL线程在执行中继日志前会等待设定的延迟时间。

延迟复制适用场景如下：

• 防误操作兜底：如 DBA 误删表（DROP TABLE），可在延迟窗口内暂停从库，跳过该语句，快速恢复数据

• 审计回溯：保留历史某一时刻的数据快照，用于合规或分析

• 灰度验证：先在延迟从库上观察变更影响，再决定是否全量发布

关于延迟复制有经典的案例，咱们下次再详细说明。

一台从库可以同时从多个主库（数据源）进行复制， 将多个实例的数据合并到一个实例，便于统计分析或集中备份。

多源复制 从MySQL 5.7.6版本开始支持，一台从库最多可连接64个主库。配置时，每个主库的连接使用独立的通道（Channel），例如 FOR CHANNEL 'channel_name'。这要求各主库同步到从库的数据库名最好不同，以避免冲突。例如：

-- 配置主库 A
CHANGE MASTER TO
  MASTER_HOST='master_a',
  MASTER_USER='repl',
  MASTER_PASSWORD='xxx',
  MASTER_AUTO_POSITION=1
FOR CHANNEL 'master_a';
-- 配置主库 B
CHANGE MASTER TO
  MASTER_HOST='master_b',
  MASTER_USER='repl',
  MASTER_PASSWORD='xxx',
  MASTER_AUTO_POSITION=1
FOR CHANNEL 'master_b';
-- 启动两个通道
START SLAVE FOR CHANNEL 'master_a';
START SLAVE FOR CHANNEL 'master_b';

多源复制适用场景如下：

• 数据聚合：将多个业务系统的数据汇聚到一个分析库

• 分库合并：原有多套独立 MySQL 实例，需统一查询入口

• 灾备整合：多个主库的备份集中到一个从库进行管理

点位复制 vs GTID 复制 对比表如下

3. 常见问题与排查技巧

3.1  复制中断（Error 1062 1032）

1062：主键冲突（从库已有数据）

1032：找不到要更新/删除的行

原因：主从数据不一致、跳过事务、手动改从库数据。

解决：

• 跳过错误（临时）：SET GLOBAL sql_slave_skip_counter = 1; 

• 或者临时改为幂等复制方式（参考历史文章MySQL数据库修改小众参数解决大众问题）

• 当复制正常后再使用 pt-table-sync 工具修复数据（参考历史文章MySQL数据库主从数据对比及修复）。

根本解决：

• 确保只写主库，避免直接操作从库

• 也需要保证参数合理（例如之前讨论过的双1参数问题 “我这显示转账成功了你没收到钱？"--MySQL Redo Log和binlog两阶段提交到底在防什么?）

  
  

3.2 主从延迟过大

原因：

• 从库硬件弱（CPU/IO 不足）

• 大事务（如 ALTER TABLE）

• 网络带宽不足

• 单线程 SQL Thread（MySQL 5.6 前）

优化：

• 升级到 MySQL 5.7+，启用 并行复制（parallel replication）

slave_parallel_workers = 8;
slave_parallel_type = LOGICAL_CLOCK;

• 拆分大事务

• 监控 Seconds_Behind_Master

  
  

3.3  GTID 模式下无法切换主库

• 确保新主包含所有 GTID（SELECT @@global.gtid_executed;）

• 使用 MHA mysqlfailover 或 Orchestrator 自动化工具

  
  

3.4 主库 binlog 被自动清理

从库还没拉取完，主库就 purge 了 binlog。

解决：设置合理的 expire_logs_days，或使用 PURGE BINARY LOGS TO 'xxx'; 手动清理。