MySQL的半同步复制机制

MySQL的半同步复制机制（Semisynchronous Replication）是一种在异步复制基础上增强数据一致性的技术，通过主库等待从库确认接收日志的机制，减少主从数据不一致的风险。以下是其核心实现原理及关键技术：

---

一、核心实现原理

1. ACK确认机制
   主库在事务提交时，需等待至少一个从库将事务的Binlog写入中继日志（Relay Log）并返回确认（ACK），才向客户端返回成功响应。这一机制确保事务在主库和至少一个从库中持久化，降低数据丢失风险。

2. 两种模式：AFTER_SYNC与AFTER_COMMIT

   • AFTER_COMMIT（默认于MySQL 5.5/5.6）：主库先提交事务，再等待从库ACK。若主库在等待期间崩溃，可能导致其他客户端读取到未同步到从库的已提交数据，造成主从不一致。
   • AFTER_SYNC（MySQL 5.7默认）：主库在事务写入Binlog并同步到从库后，再提交事务并返回客户端。即使主库崩溃，已确认的事务仍能从从库恢复，数据一致性更强。

3. 超时降级机制
   若主库在rpl_semi_sync_master_timeout（默认10秒）内未收到ACK，则自动降级为异步复制，避免阻塞事务提交。当从库恢复后，主库重新切换回半同步模式。

---

二、关键技术实现

1. 插件化支持
   半同步复制通过插件semisync_master.so（主库）和semisync_slave.so（从库）实现。需手动加载插件并启用参数rpl_semi_sync_master_enabled和rpl_semi_sync_slave_enabled。

2. 独立ACK接收线程（MySQL 5.7优化）
   MySQL 5.7引入独立的ACK Receiver线程，与主库的Binlog发送线程并行工作，解决了早期版本中单线程串行处理导致的性能瓶颈，提升了吞吐量。

3. 多从库ACK计数
   通过参数rpl_semi_sync_master_wait_for_slave_count，可设置主库需等待的从库ACK数量（默认1）。例如，设置为2时需至少两个从库确认，增强数据冗余。

---

三、数据一致性与故障处理

1. 数据一致性保障

   • AFTER_SYNC模式：事务仅在从库确认后提交，确保主库崩溃时已确认事务在从库中完整存在，避免数据丢失。
   • AFTER_COMMIT模式：主库提交后等待ACK，若主库崩溃，可能导致其他客户端读取到未同步的数据，需依赖外部工具（如MHA）修复。

2. 故障切换与恢复

   • 主库宕机时，从库基于已接收的Relay Log提升为新主，数据丢失风险显著降低。
   • 网络中断时，主库通过超时机制切换为异步复制，恢复后自动追补数据并重归半同步模式。

---

四、性能与适用场景

1. 性能影响

   • 延迟增加：每个事务需等待从库ACK，网络往返时间（RTT）直接影响吞吐量。
   • 优化建议：在低延迟网络（如同机房部署）中使用，或通过MySQL 5.7的并行ACK机制缓解性能损耗。

2. 适用场景

   • 金融级应用：要求高数据一致性，容忍一定延迟。
   • 异地多活：跨AZ/Region部署时，通过半同步减少数据差异。

---

五、与异步复制的对比

特性	异步复制	半同步复制
数据一致性	最终一致，可能丢失事务	至少一个从库持久化，降低丢失风险
性能	高吞吐，低延迟	吞吐量降低，延迟增加（取决于RTT）
适用场景	非关键业务，容忍数据差异	高可靠性要求的核心业务

---

总结

MySQL半同步复制通过ACK确认机制和超时降级策略，在异步复制的基础上实现了数据强一致性。其核心改进在于MySQL 5.7的AFTER_SYNC模式和独立ACK线程，既保障了数据安全，又优化了性能。实际应用中需权衡网络延迟与数据可靠性，合理配置参数（如rpl_semi_sync_master_wait_point和超时时间），适用于金融、电商等对数据一致性要求严苛的场景。