MySQL5.7 对半同步复制的改进


通过rpl_semi_sync_master_wait_point参数

有两种选择

AFTER_SYNC (the default):
The master writes each transaction to its binary log and the slave,and syncs the binary log to disk.

The master waits for slave acknowledgment of transaction receipt after the sync.

 Upon receiving acknowledgment, the master commits the transaction to the storage engine and returns a result to the client, which then can proceed.

master写每一个事务到binlog并同时发送给slave,且sync binlog到磁盘。

mater sync完成后，开始等待slave的确认。

确认后，master commit事务到存储引擎,并返回结果给客户端，客户端才可继续。

AFTER_COMMIT:
The master writes each transaction to its binary log and the slave, syncs the binary log,
and commits the transaction to the storage engine.

The master waits for slave acknowledgment of transaction receipt after the commit.

Upon receiving acknowledgment, the master returns a result to the client, which then can proceed.

master写每一个事务到binlog并同时发送给slave,且sync binlog到磁盘,并且commit事务到存储引擎里。

master commit完成后，开始等待slave确认。

确认后，master返回结果给客户端，客户端才可继续。

以前AFTER_COMMIT问题在于，虽然master一直没有告诉提交事务的客户端事务已经成功（在slave成功确认前），但是实际已经提交了，其它客户端此时已经可以看到事务的结果了。

也就是对于事务提交者自身，的确保证了只要收到成功就一定成功了。

但是其它客户端却可能存在发现事务成功了，但最后却没成功。

比如A客户端执行事务将字段Z从0（未确认）修改为1（确认）。

1.A提交事务到master

2.master写binlog

3.master发送给slave，同时master commit事务到存储引擎

4.master commit成功了！

  此时还未收到slave确认，此时A还在等待结果，但是此时另外客户端B已经可以看到字段Z为1了！

假如此时master崩溃，如果slave实际收到刚才的事务仅仅是master未收到确认，

那么此时slave的数据还是正确的也是z=1，客户端切换到slave后，都看到z=1

但是如果slave没有实际收到刚才的事务，那么此时slave上z=0，

对于客户端A，这个并没有问题，因为A先前提交的事务没有收到任何反馈，

所以A需要通过其它方式来确定先前事务是否成功，也就是A可以接受z=0或z=1。

但是对于B来说，已经z=1的变成z=0则很可能是无法接受的

（比如这个系统z只能从0未确认到1确认，从1确认到2取消）。

5.7的AFTER_SYNC则可以解决这个问题，同样刚才的例子：

1.A提交事务到master

2.master写binlog

3.master发送给slave

4.master等待slave确认

  此时z=0，没有任何客户端能看到z=1的结果

5.master收到slave确认，master开始commit到存储引擎

6.master commit成功了！master返回结果给客户端

假如第4步时master崩溃，客户端切换到slave，

如果slave实际接受到事务，那么此时z=1，

如果slave未接收到事务，那么此时z=0，

无论哪种状态，对于所有客户端数据库都是一致，事务都没有丢失。

同样客户端A需要自己检查事务状态，因为他没收到反馈，业务上他本身就接受两种可能。

结论,mysql5.7可以更进一步减少半同步复制时发生意外,数据不一致丢失问题.