异步复制_半同步复制_增强半同步复制

1. 同步

1.1 异步复制

MySQL 默认的复制策略，Master处理事务过程中，将其写入Binlog就会通知Dump thread线程处理，然后完成事务的提交，不会关心是否成功发送到任意一个slave中

问题：一旦Master 崩溃，发送主从切换将会发送数据不一致性的风险。

1.2 半同步复制

Master处理事务过程中，提交完事务后，必须等至少一个Slave将收到的binlog写入relay log返回ack才能继续执行处理用户的事务。

Master处理事务过程中，提交完事务后，必须等至少一个Slave将收到的binlog写入relay log返回ack才能继续执行处理用户的事务。

配置

1. rpl_semi_sync_master_wait_point = AFTER_COMMIT （什么时间点开始等ack）
2. rpl_semi_sync_master_wait_for_slave_count = 1 （最低必须收到多少个slave的ack）
3. rpl_semi_sync_master_timeout = 100（等待ack的超时时间）

问题：

1. 半同步的问题是因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户又看到老数据。
2. 一旦Ack超时，将退化为异步复制模式，那么异步复制的问题也将发送
3. 性能下降，增多至少一个RTT时间

1.3 增强半同步复制

增强半同步和半同步不同是，等待ACK时间不同

rpl_semi_sync_master_wait_point = AFTER_SYNC（唯一区别）

问题：

1. 增强半同步将等待ACK的点放在提交Commit之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题。
2. 一旦Ack超时，将退化为异步复制模式，那么异步复制的问题也将发送
3. 性能下降，增多至少一个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)