【MySQL】5.7版本 Semisync Replication 增强
发表于:2026-11-01 作者:千家信息网编辑
千家信息网最后更新 2026年11月01日,一 前言前文 介绍了5.5/5.6 版本的MySQL semi sync 基础原理和配置,随着MySQL 5.7 的发布,新版本的MySQL修复了semi sync 的一些bug 并且增强了功能。支持
千家信息网最后更新 2026年11月01日【MySQL】5.7版本 Semisync Replication 增强
二 优化
大体的实现思路是:
备库IO线程使用TCP协议和主库交互,读写socket可以同时进行,在开启主库semisync时,启动一个后台线程,使用select监听备库连接socket;
dump线程不再等待备库ACK;在ack reciver线程等待ACK时,dump线程还能继续发送下一组group commit的binlog,进而提升TPS.
该参数有两个值:
AFTER_SYNC (默认值):master 将每个事务写入binlog ,传递到slave,并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈,master在主库提交事务并且返回结果给会话。 在AFTER_SYNC模式下,所有的客户端在同一时刻查看已经提交的数据。假如发生主库crash,所有在主库上已经提交的事务已经同步到slave并记录到relay log。此时切换到从库,可以保障最小的数据损失。
AFTER_COMMIT: master 将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log),然后在主库提交事务。master在提交事务后等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈,master将结果反馈给客户端。
在AFTER_COMMIT模式下,如果slave 没有应用日志,此时master crash,系统failover到slave,app将发现数据出现不一致,在master提交而slave 没有应用。
[1] 5.7 Semisynchronous Replication
[2] loss-less-semi-synchronous-replication MySQL 5.7 修改了半同步中主库提交的事务的顺序,after sync 模式避免了幻读发生。
[3] enforced-semi-synchronous-replication
MySQL 5.7 半同步增强,增加 rpl_semi_sync_master_wait_slave_count 参数控制主库接收多少个slave 写事务成功反馈 才返回 成功给客户端 。
[4] faster-semisync-replication
修改原来有dump thread 发送event和接收slave ack 模式,独立出 单独 接收slave 返回 ack的进程,提高半同步模式的tps 。
一 前言
前文 介绍了5.5/5.6 版本的MySQL semi sync 基础原理和配置,随着MySQL 5.7 的发布,新版本的MySQL修复了semi sync 的一些bug 并且增强了功能。- 支持发送binlog和接受ack的异步化;
- 支持在事务commit前等待ACK;
- 在server层判断备库是否要求半同步以减少Plugin锁冲突;
- 解除binlog dump线程和lock_log的冲突等等。
二 优化
1 支持发送binlog和接受ack的异步化
通过前面的介绍,我们知道Semisynchronous Replication模式下,app在主库上提交一个事务/event,MySQL将每个事务写入binary并且同步到到slave ,master会等待至少一个slave通知:slave 已经接收到传过来的events并写入relay log,才返回给回话层 写入成功,或者直到传送日志发生超时,系统自动将为异步复制模式。
整体流程的逻辑图

5.5 版本semi sync 设计的缺点:
从原理以及上图来看,旧版本的semi sync 受限于dump thread ,原因是dump thread 承担了两份不同且又十分频繁的任务:传送binlog 给slave ,还需要等待slave反馈信息,而且这两个任务是串行的,dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈在高并发业务场景下,这样的机制会影响数据库整体的TPS .
为了解决上述问题,在5.7.4版本的semi sync 框架中,独立出一个 ack collector thread ,专门用于接收slave 的反馈信息。这样master 上有两个进程独立工作,可以同时发送binlog 到slave ,和接收slave的反馈。整体流程的逻辑图
大体的实现思路是:
备库IO线程使用TCP协议和主库交互,读写socket可以同时进行,在开启主库semisync时,启动一个后台线程,使用select监听备库连接socket;
dump线程不再等待备库ACK;在ack reciver线程等待ACK时,dump线程还能继续发送下一组group commit的binlog,进而提升TPS.
2 支持在事务commit前等待ACK;
新版本的semi sync 增加了rpl_semi_sync_master_wait_point参数 来控制半同步模式下 主库在返回给会话事务成功之前提交事务的方式。该参数有两个值:
AFTER_SYNC (默认值):master 将每个事务写入binlog ,传递到slave,并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈,master在主库提交事务并且返回结果给会话。 在AFTER_SYNC模式下,所有的客户端在同一时刻查看已经提交的数据。假如发生主库crash,所有在主库上已经提交的事务已经同步到slave并记录到relay log。此时切换到从库,可以保障最小的数据损失。
AFTER_COMMIT: master 将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log),然后在主库提交事务。master在提交事务后等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈,master将结果反馈给客户端。
在AFTER_COMMIT模式下,如果slave 没有应用日志,此时master crash,系统failover到slave,app将发现数据出现不一致,在master提交而slave 没有应用。
三 推荐阅读
注:最后三个来自于MySQL replication 开发小组的blog,需要翻墙,请自备梯子。[1] 5.7 Semisynchronous Replication
[2] loss-less-semi-synchronous-replication MySQL 5.7 修改了半同步中主库提交的事务的顺序,after sync 模式避免了幻读发生。
[3] enforced-semi-synchronous-replication
MySQL 5.7 半同步增强,增加 rpl_semi_sync_master_wait_slave_count 参数控制主库接收多少个slave 写事务成功反馈 才返回 成功给客户端 。
[4] faster-semisync-replication
修改原来有dump thread 发送event和接收slave ack 模式,独立出 单独 接收slave 返回 ack的进程,提高半同步模式的tps 。
事务
模式
同步
线程
版本
成功
数据
磁盘
系统
支持
两个
参数
客户
客户端
整体
独立
任务
信息
原理
同时
数据库的安全要保护哪些东西
数据库安全各自的含义是什么
生产安全数据库录入
数据库的安全性及管理
数据库安全策略包含哪些
海淀数据库安全审计系统
建立农村房屋安全信息数据库
易用的数据库客户端支持安全管理
连接数据库失败ssl安全错误
数据库的锁怎样保障安全
广州为想互联网科技有限公司
互联网科技行业发展
青岛互联网科技公司
未来的互联网科技
互联网金融科技委员会
佩信高科技互联网
成都玖崟互联网科技有限公司乐商圈怎么样
湖南诚度互联网科技有限公司
互联网科技与大数据专业
搜狐科技互联网
互联网科技人工智能实验室
洛阳共同富裕互联网科技有限公司
中和天地互联网科技有限公司
滨湖区互联网智能科技产品有哪些
沐思想互联网科技有限公司
互联网第三次科技革命特征
南京一网一红互联网科技有限公司
互联网科技创新创业项目
亚光科技低轨卫星互联网
互联网科技自媒体灵感
深圳九邦互联网科技有限公司
甘肃拓世互联网科技有限公司
恒生科技互联网指数分析
科技与互联网的利与弊
互联网营销推广黑科技
互联网领先科技宣传片
九思连强互联网电子科技有限公司
珠海东科互联网科技有限公司
吉林省码上互联网科技电话
北京军民互联网科技公司