一文讲透MySQL的主从同步

MySQL的主从同步（Master-Slave Replication）是一种通过日志记录和重放实现数据复制的机制，其核心目标是将主库（Master）的数据变更实时或近实时地同步到从库（Slave），从而实现数据冗余、读写分离、高可用性等功能。以下是其详细原理和流程：

一、核心组件与角色

1. 主库（Master）

• 职责：处理所有写操作（INSERT、UPDATE、DELETE等），并将数据变更记录到**二进制日志（Binary Log）**中。
• 关键组件：
  • Binary Log：记录所有写操作的事件（如SQL语句或行变更）。
  • Binlog Dump线程：负责向从库发送Binary Log事件。

2. 从库（Slave）

• 职责：接收主库的Binary Log，本地重放事件以保持数据一致性。
• 关键组件：
  • I/O线程：连接主库，拉取Binary Log并写入本地中继日志（Relay Log）。
  • SQL线程：读取Relay Log中的事件并执行，更新本地数据。

二、主从同步的核心流程

1. 主库写操作与日志记录

   • 客户端向主库发起写操作（如INSERT、UPDATE）。
   • 主库在内存中修改数据，并将操作记录到Binary Log（按事务提交顺序记录）。
   • Binary Log包含事件类型（如INSERT、UPDATE）、涉及的表、字段值等信息。

2. 从库拉取Binary Log

   • 从库启动后，I/O线程连接主库，请求Binary Log。
   • 主库的Binlog Dump线程将Binary Log事件发送给从库。
   • 从库的I/O线程将接收到的Binary Log事件写入本地的Relay Log。

3. 从库重放日志

   • 从库的SQL线程读取Relay Log中的事件，并解析为具体的SQL语句或行变更操作。
   • 执行解析后的SQL语句，更新从库的数据，最终实现主从数据一致。

三、关键线程与日志

四、复制模式

MySQL支持三种复制模式，影响同步的一致性和性能：

1. 异步复制（默认模式）

• 流程：
  • 主库执行写操作并记录Binary Log后，立即返回客户端成功响应。
  • 从库异步拉取Binary Log并重放。
• 优点：性能高，主库无需等待从库确认。
• 缺点：主库宕机时可能导致从库数据丢失（未同步的Binary Log丢失）。

2. 半同步复制（推荐模式）

• 流程：
  • 主库执行写操作后，等待至少一个从库确认已接收Binary Log，再返回客户端成功响应。
  • 若从库在超时时间内未确认（默认10秒），自动切换为异步复制。
• 优点：减少数据丢失风险，兼顾性能与一致性。
• 配置：

  -- 主库配置
  SET GLOBAL rpl_semi_sync_master_enabled = 1;
  SET GLOBAL rpl_semi_sync_master_timeout = 1000; -- 超时时间（毫秒）
  
  -- 从库配置
  SET GLOBAL rpl_semi_sync_slave_enabled = 1;
  START SLAVE;
  

3. 全同步复制

• 流程：主库等待所有从库确认接收Binary Log后，才返回客户端成功响应。
• 优点：强一致性，数据零丢失。
• 缺点：性能开销大，网络延迟敏感，不适用于高并发场景。

五、主从同步的优缺点

优点

1. 读写分离：主库处理写操作，从库处理读操作，分担主库压力。
2. 数据冗余：从库作为数据备份，提升容灾能力。
3. 高可用性：主库故障时可快速切换到从库（需配合故障转移工具，如MHA）。

缺点

1. 主从延迟：从库重放日志的速度可能跟不上主库写入速度（常见于大事务或高并发场景）。
2. 一致性风险：异步复制可能导致主从数据不一致（需通过半同步或全同步缓解）。
3. 复杂性：需维护主从拓扑、监控延迟、处理故障切

六、主从延迟的解决方案

1. 硬件与网络优化：

   • 升级从库硬件（如SSD磁盘）、优化网络带宽。
   • 主从节点部署在同一机房，减少跨地域延迟。

2. 并行复制（MySQL 5.7+）：

   • 启用基于逻辑时钟的并行复制，提升SQL线程的执行效率：

     SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
     SET GLOBAL slave_parallel_workers = 4; -- 根据CPU核心数设置
     

3. 拆分大事务：

   • 避免单个事务过大（如批量插入/更新），拆分为多个小事务。

4. 监控与告警：

   • 使用 SHOW SLAVE STATUS\G 查看 Seconds_Behind_Master。
   • 集成Prometheus + Grafana监控主从延迟。

七、实际案例

场景：电商平台订单系统

• 问题：用户下单后，从库查询不到最新订单（主从延迟约5秒）。
• 根因：
  • 主库存在大事务（批量插入订单），导致Binary Log体积大。
  • 从库SQL线程单线程执行，无法及时处理。
• 解决方案：
  1. 启用并行复制：将 slave_parallel_workers 设置为8。
  2. 拆分大事务：将批量插入拆分为单条插入。
  3. 升级硬件：从库磁盘升级为SSD。
• 效果：主从延迟从5秒降至0.5秒以内。

八、总结

MySQL主从同步的核心是通过Binary Log记录主库变更，并由从库拉取日志、重放事件以保持数据一致。不同复制模式（异步、半同步、全同步）在性能与一致性之间做权衡。实际应用中需结合业务需求选择复制模式，并通过硬件优化、并行复制、监控等手段减少主从延迟，确保系统稳定运行。