【MySQL】5.7版本 Semisync Replication 增强
发表于:2025-02-24 作者:千家信息网编辑
千家信息网最后更新 2025年02月24日,一 前言前文 介绍了5.5/5.6 版本的MySQL semi sync 基础原理和配置,随着MySQL 5.7 的发布,新版本的MySQL修复了semi sync 的一些bug 并且增强了功能。支持
千家信息网最后更新 2025年02月24日【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安全错误
数据库的锁怎样保障安全
电脑玩原神老重新连接服务器
濮阳网络技术参数
化学物数据库
土地承包经营权数据库标准
进入游戏所选的服务器在哪看
关于5G网络技术
河北小型软件开发it技术
国家安全日网络安全封面
服务器的级别
app软件开发 东莞
通过网址查询云服务器
关于网络安全长句子
sbu数据库是啥
技术创新网络安全工程
网络安全和网络应用大专
机械运动仿真软件开发
中国人保寿险技术软件开发
智能运维管理服务器综合能源
计算机软件开发哪个学校
方舟新服务器
网络安全手抄报简单又好看步骤
国内外著名软件开发企业
服务器带宽跟宽带带宽的区别
数据库结构 展示系统
网络安全购物信息稿
数据库为什么有两个图表
信息网络安全教程
景仁网络技术
华信傲天网络技术有限公司知乎
知网数据库版权问题