mysql 半同步复制~ 整体概述与改进

一 简介:今天来聊聊增强半同步复制这一强悍的特性

二 原理解析

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刷新策略)