扩展：MySQL5.7新特性半同步复制之AFTER_SYNC/AFTER_COMMIT的过程分析和总结

最新推荐文章于 2023-12-22 16:41:08 发布

xiaoleinb

最新推荐文章于 2023-12-22 16:41:08 发布

阅读量277

点赞数

分类专栏： mysql

本文链接：https://blog.csdn.net/xiaoleinb/article/details/112143541

版权

本文详细解析了MySQL5.7中半同步复制的新特性，重点讨论了AFTER_SYNC和AFTER_COMMIT两种模式下的事务处理流程。在AFTER_COMMIT模式下，主库在等待从库ACK后才返回提交成功；而在AFTER_SYNC模式中，主库在收到ACK后再进行InnoDB引擎提交，确保无损复制。同时介绍了5.7版本中引入的ack线程优化，提高了复制效率。

摘要由CSDN通过智能技术生成

MySQL 5.7增强了半同步复制，rpl_semi_sync_master_wait_point增加了AFTER_SYNC的值，由该参数AFTER_SYNC/AFTER_COMMIT两个值选择是否启用增强半同步.

当半同步模式为 AFTER_COMMIT时:
过程分析如下：
1 > session 发出commit请求
2 > flush binlog and fsync binlog
3 > InnoDB 引擎层 commit
4 > 发送binlog到SLAVE，等待slave发送ack确认
5 > slave 接受binlog 写入relay log ，刷盘完成发送ack确认包给master
6 > master 返回 commit ok 信息给session

另外 (master 等待事务A 的 ACK的时候宕机，此时新事务B在宕机之前开启)：
1> binlog 未发送到从库:
事务B获取到事务A提交的内容，此时宕机故障切换到slave，事务B获取到的内容却丢失了。事务A commit没有收到反馈信息(则需要业务判断了)。
2> binlog 已经发送给从库 :
事务B获取到事务A提交的内容，故障切换到salve ，B仍然获取到A提交的内容，没毛病。事务A commit没有收到反馈信息，若重新执行该事务，则相当于执行两次A事务(则需要业务判断了)。
在这里插入图片描述