有的网站为什么打不开怎么回事/天津关键词优化专家
一 前言
前文
- 支持发送binlog和接受ack的异步化;
- 支持在事务commit前等待ACK;
- 在server层判断备库是否要求半同步以减少Plugin锁冲突;
- 解除binlog dump线程和lock_log的冲突等等。
本文重点分析 第1,2个改进项，因为原来的模式的确会影响系统的tps，新的异步模式可以提高半同步模式下的系统事务处理能力。
二 优化
二 优化
1
通过前面的介绍，我们知道Semisynchronous Replication模式下,app在主库上提交一个事务/event，MySQL将每个事务写入binary并且同步到到slave ，master会等待至少一个slave通知:slave 已经接收到传过来的events并写入relay log，才返回给回话层 写入成功，或者直到传送日志发生超时,系统自动将为异步复制模式。
整体流程的逻辑图
5.5 版本semi sync 设计的缺点：
为了解决上述问题，在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
该参数有两个值：
AFTER_SYNC (默认值):master 将每个事务写入binlog ,传递到slave，并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈，master在主库提交事务并且返回结果给会话。
AFTER_COMMIT:
在AFTER_COMMIT模式下,如果slave 没有应用日志,此时master crash，系统failover到slave，app将发现数据出现不一致，在master提交而slave 没有应用。
三 推荐阅读
注：最后三个来自于MySQL replication 开发小组的blog，需要翻墙，请自备梯子。
[1]
[1]
[2]
MySQL 5.7 修改了半同步中主库提交的事务的顺序，after sync 模式避免了幻读发生。[3]
MySQL 5.7 半同步增强，增加 rpl_semi_sync_master_wait_slave_count 参数控制主库接收多少个slave 写事务成功反馈 才返回 成功给客户端 。
[4]
修改原来有dump thread 发送event和接收slave ack 模式，独立出 单独 接收slave 返回 ack的进程，提高半同步模式的tps 。