MySQL主从复制之半同步(semi-sync replication)

半同步简介

• MASTER节点在执行完客户端提交的事务后不是立刻返回结果给客户端，而是等待至少一个SLAVE节点接收并写到relay log中才返回给客户端。
• 半同步相对于异步复制而言，提高了数据的安全性，同时也造成了一定程度的延迟，这个延迟最少是一个TCP往返的时间。所以，半同步复制最好在低延时的网络中使用。
• MySQL从5.5开始就支持半同步复制，在5.7.2版本的时候对半同步复制进行了一次改进；原先的半同步策略为 AFTER_COMMIT 改进后的策略为 AFTER_SYNC 两者的差异在于SLAVE节点ACK应答MASTER的时机不同。

两种模式介绍

• AFTER_COMMIT 模式介绍

MASTER将每个事务写入到二进制日志并刷盘保存，同时将事务发送给SLAVE，然后将事务提交给存储引擎处理并进行提交，然后等待SLAVE返回确认信息，在收到确认信息后，MASTER将结果返回给客户端，然后当前客户端可以继续工作。

• AFTER_SYNC 模式介绍

MASTER将每个事务写入到二进制日志并刷盘保存，同时将事务发送给SLAVE，然后等待SLAVE返回确认信息，收到确认信息后，将事务提交给存储引擎处理并进行提交，并将结果返回给客户端，然后当前客户端可以继续工作。

两种方式比较

• 对于第一种 AFTER_COMMIT 方式，当前客户端只有在服务器向存储引擎提交数据并收到SLAVE返回的确认后，才会收到事务的返回结果。在事务提交之后收到SLAVE返回确认信息之前，此刻其他客户端可以看到当前客户端提交的事务信息。

如果SLAVE节点由于网络等原因并未收到MASTER节点传递过来的事务，而MASTER节点此刻crash了。HA进行故障转移，客户端都连到SLAVE节点上，这时先前在MASTER节点看到的事务在SLAVE节点并未看到，就会发生事务丢失的情况。

• 对于第二种 AFTER_SYNC 方式，当事务被SLAVE确认后MASTER在存储引擎层面进行提交事务后，所有客户端才能看到事务造成的数据更改。因此，所有客户端在MASTER上同一时刻看到是相同的数据。

当MASTER节点crash的情况下，所有在MASTER上提交的事务都被复制到SLAVE(保存到中继日志中)。MASTER服务器意外crash。此刻HA进行故障转移到SALVE后，客户端看到的数据是无损的，因为SLAVE是最新的。注意，然而，在这种情况下，MASTER不能直接恢复使用，因为它的二进制日志可能包含未提交的事务，此刻当二进制日志恢复并用于业务需求时，可能会导致与SLAVE的冲突。

如何开启半同步

• 方式1：半同步以插件的形式存在，咱们可以直接在线开启即可（本次采用这次方式）

# 主节点开启
[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
Query OK, 0 rows affected (0.02 sec)

# 从节点开启
[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
Query OK, 0 rows affected (0.02 sec)

# PS：一般情况下所有节点都同步部署master和slave插件，这样故障切换的时候会比较方便处理

• 方式2：在my.cnf配置中进行开启

# 主从节点都同步配置开启
plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_sync_slave=semisync_slave.so"
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1

查看插件开启情况

• 方式1：查询plugin

# 主节点查看
[root@GreatSQL][test]>show plugins;
...
| rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
...
# 从节点查看
[root@Grea