一 简介:今天来聊聊增强半同步复制这一强悍的特性
二 原理解析
1 AFTER_COMMIT（5.6默认值）
master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。
2 AFTER_SYNC（5.7默认值，但5.6中无此模式）
master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中
三 5.7改进点
1 模式改为after_commit,在收到ack回复信息后才进行事务层的提交和客户端的返回,进一步提高主从的一致性程度
2 ack信息确认有专门的线程处理,原来dump线程既要处理binlog传输又要确认ACK信息,极大的影响了主从的并发
3 新增rpl_semi_sync_master_wait_slave_count参数,这就是我们上面所说 只要有一个从库返回ack信息,就代表半同步复制完成.极大的调节了整个架构的灵活性
4 MySQL 5.7 对binlog lock进行了以下两方面优化:
1. 移除了dump thread对binlog的互斥锁
2. 加入了安全边际保证binlog的读安全
5 5.7新的并行复制特性更加可以应用到半同步复制上,提升了整体性能
四 半同步复制转化为异步复制的风险
1 主和从集群机器之间的网络,注意流量监控
2 从集群整体的复制是否健康,注意集群从库健康监控
3 从集群整体的IO较高,注意从库延迟和慢查询监控
五 相关重要参数和监控
一 状态监控,监控状态是否开启
show status like 'Rpl_semi_sync_master_status';
show status like 'Rpl_semi_sync_slave_status';
二 没有收到ACK应答的事务数
show status like 'Rpl_semi_sync_master_no_tx'
六 搭建
1 master
install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
install plugin rpl_semi_sync_master soname 'semisync_master.so';
set global rpl_semi_sync_master_enabled= 1;
set global rpl_semi_sync_slave_enabled = 1;
set global rpl_semi_sync_master_timeout=1000;
2 slave
install plugin rpl_semi_sync_master soname 'semisync_master.so';
install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
set global rpl_semi_sync_slave_enabled = 1;
set global rpl_semi_sync_master_enabled= 1;
set global rpl_semi_sync_master_timeout=1000;
3 slave
1 重启复制进程,进行角色注册
2 观察日志和相关变量
Start semi-sync replication to master 半同步复制开启
3 将配置写入配置文件中,同时开启是因为故障切换后继续执行半同步复制
4 小结
1 调节异步复制忍受时间为1s,防止影响业务
2 默认接收到一个client即可,不需要调节
七 上线部署
对增强复制状态进行监控,如果频频发生切换到异步情况一定要定位原因
八 增强半同步复制考虑的问题
如果主库binlog还没落盘,从库binlog已经接受,这时候主库挂掉,造成主库可能不一致
解决方式 半同步复制配合sync_binlog=1是最好的
九 最佳架构
MHA(0.57)+MYSQL(5.7.21)（并行复制+半同步增强)+sync-binlog=1(binlog刷新策略)