1. 同步
1.1 异步复制
MySQL 默认的复制策略,Master处理事务过程中,将其写入Binlog就会通知Dump thread线程处理,然后完成事务的提交,不会关心是否成功发送到任意一个slave中
问题:一旦Master 崩溃,发送主从切换将会发送数据不一致性的风险。
1.2 半同步复制
Master处理事务过程中,提交完事务后,必须等至少一个Slave将收到的binlog写入relay log返回ack才能继续执行处理用户的事务。
Master处理事务过程中,提交完事务后,必须等至少一个Slave将收到的binlog写入relay log返回ack才能继续执行处理用户的事务。
配置
- rpl_semi_sync_master_wait_point = AFTER_COMMIT (什么时间点开始等ack)
- rpl_semi_sync_master_wait_for_slave_count = 1 (最低必须收到多少个slave的ack)
- rpl_semi_sync_master_timeout = 100(等待ack的超时时间)
问题:
- 半同步的问题是因为等待ACK的点是Commit之后,此时Master已经完成数据变更,用户已经可以看到最新数据,当Binlog还未同步到Slave时,发生主从切换,那么此时从库是没有这个最新数据的,用户又看到老数据。
- 一旦Ack超时,将退化为异步复制模式,那么异步复制的问题也将发送
- 性能下降,增多至少一个RTT时间
1.3 增强半同步复制
增强半同步和半同步不同是,等待ACK时间不同
rpl_semi_sync_master_wait_point = AFTER_SYNC(唯一区别)
问题:
- 增强半同步将等待ACK的点放在提交Commit之前,此时数据还未被提交,外界看不到数据变更,此时如果发送主从切换,新库依然还是老数据,不存在数据不一致的问题。
- 一旦Ack超时,将退化为异步复制模式,那么异步复制的问题也将发送
- 性能下降,增多至少一个RTT时间。如果超时时间设置很大,然后因为网络原来长时间收不到ACK,用户提交是被挂起的,可用性收到打击(半同步一样存在)
2. 配置增强半同步
- 安装插件:
主从:
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_wait_point = AFTER_SYNC
set global rpl_semi_sync_master_timeout =1000; // 等待多长时间就转为异步
- 查看插件
mysql> show plugins;
| rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
| rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |
+----------------------------+----------+--------------------+--------------------+---------+
46 rows in set (0.01 sec)