在分布式数据库架构中，我们近期遇到一个典型案例：某业务系统采用跨机房MySQL主从部署并启用半同步复制后，主库写入延迟显著增加至40毫秒。由于该业务对数据写入时效性要求极高，最终通过关闭从库半同步参数（rpl_semi_sync_slave_enabled），切换为异步复制模式，成功将写入延迟优化至2毫秒。这个案例充分说明，在跨机房部署且对性能敏感的场景下，需要谨慎评估半同步复制的适用性，网络延迟可能成为关键性能瓶颈。这一问题的解决过程，也促使我们更深入地研究了MySQL半同步复制的核心工作机制。
1. 主库事务确认机制参数解析（rpl_semi_sync_master_wait_point）
MySQL 5.7.2版本对该参数的默认值做出了重要调整，从after_commit变更为after_sync。在传统after_commit模式下，存在一个潜在风险窗口：当主库完成事务提交但尚未收到从库确认时，其他客户端可能查看到未最终确认的数据。若此时发生主从切换，可能导致数据不一致现象。而after_sync机制通过调整确认时序，确保所有客户端只有在从库确认且主库完成持久化后，才能看到数据变更。这种改进方案有效解决了数据一致性问题，因此被称为"增强型半同步"或"无损半同步"复制。
2. 从库日志持久化机制探讨
对比其他数据库系统的复制机制，MySQL在从库确认策略上采用了独特设计。其核心特点是：从库只需将中继日志（relaylog）写入内存缓冲区即可向主库发送确认信号，而不必等待磁盘持久化完成。关于日志刷盘频率，由sync_relay_log参数调控，默认配置为每10000个事务执行一次刷盘操作。当该参数设为0时，系统将完全依赖操作系统自身的缓存管理机制来控制刷盘行为，这种设计在性能与可靠性之间提供了灵活的平衡点。
文章整理自互联网，只做测试使用。发布者：Lomu，转转请注明出处：https://www.it1024doc.com/9266.html
