MySQL 5.7半同步复制after sync和after commit的示例分析

共计 2868 个字符，预计需要花费 8 分钟才能阅读完成。

这篇文章主要介绍了 MySQL 5.7 半同步复制 after sync 和 after commit 的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让丸趣 TV 小编带着大家一起了解一下。

如果你的生产库开启了半同步复制，那么对数据的一致性会要求较高，但在 MySQL5.5/5.6 里，会存在数据不一致的风险。有这么一个场景，客户端提交了一个事务，master 把 binlog 发送给 slave，在发送的期间，网络出现波动，此时 Binlog Dump 线程发送就会卡住，要等待 slave 把 binlog 写到本地的 relay-log 里，然后给 master 一个反馈，等待的时间以 rpl_semi_sync_master_timeout 参数为准，默认为 10 秒。在这等待的 10 秒钟里，在其他会话里，查看刚才的事务是可以看见的，此时一旦 master 发生宕机，由于 binlog 没有发送给 slave，前端 app 切到 slave 查看，就会发现刚才已提交的事务不见了。

为了解决这种问题，MySQL5.7 改善了半同步复制这个缺陷。通过 rpl_semi_sync_master_wait_point 这个参数加以控制，默认是 AFTER_SYNC，官方推荐用这个，它的工作原理是：master 把 binlog 发送给 slave，只有在 slave 把 binlog 写到本地的 relay-log 里，才提交到存储引擎层，然后把请求返回给客户端，客户端才可以看见刚才提交的事务。如果 slave 未保存到本地的 relay-log 里，客户端是看不见刚才的事务的，这样就不会造成上述那个场景发生。另一个值是 AFTER_COMMIT，这个值是采用老式的 MySQL5.5/5.6 半同步复制工作。

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.
主库把每一个事务写到二进制日志并保存磁盘上，且发送给从库。主库在等待从库写到自己的 relay-log 里确认信息。在接到确认信息后，主数据库把事务写到存储引擎里并把相应结果反馈给客户端，客户端将在那时进行处理。

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. 
主库把每一个事务写到二进制日志并保存磁盘上，且发送给从库，并把事务写到存储引擎里。主库在等待从库写到自己的 relay-log 里确认信息。在接到确认信息后，主库把相应结果反馈给客户端，客户端将在那时进行处理。

The replication characteristics of these settings differ as follows:
这两个参数不同之处在于：

With AFTER_SYNC, all clients see the committed transaction at the same time: After it has been acknowledged by the slave and committed to the storage engine on the master.。Thus, all clients see the same data on the master.
在设置为 AFTER_SYNC 参数，所有的客户端可以同时看到提交的数据：在得到从库写到自己的 relay-log 里的确认信息后，并把事务写到存储引擎里。这样，所有的客户端都可以在主库上看到同样的数据。

In the event of master failure, all transactions committed on the master have been replicated to the slave (saved to its relay log). A crash of the master and failover to the slave is lossless because the slave is up to date.
主库报错，所有已经写到从库的事务都已经保存到了 relay log 里。主库的崩溃，HA 切换到从库，不会带来任何损失，因为从库的 relay-log 的数据是最新的。

With AFTER_COMMIT, the client issuing the transaction gets a return status only after the server commits to the storage engine and receives slave acknowledgment. After the commit and before slave acknowledgment, other clients can see the committed transaction before the committing client.
在设置为 AFTER_COMMIT 参数，发起事务的客户端仅在服务器向存储引擎写入数据并接受从库得到确认之后才返回状态。在写入数据后和得到从库确认之前，其他的客户端可以看到在这一事务。

If something goes wrong such that the slave does not process the transaction, then in the event of a master crash and failover to the slave, it is possible that such clients will see a loss of data relative to what they saw on the master. 
如果出现了某种错误，比如说从库的 sql_thread 线程没有执行，那么主库崩溃和故障转移给从服务器的前提下，有可能这个客户端会丢失那些他们曾经在主库上看到的信息。

感谢你能够认真阅读完这篇文章，希望丸趣 TV 小编分享的“MySQL 5.7 半同步复制 after sync 和 after commit 的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持丸趣 TV，关注丸趣 TV 行业资讯频道，更多相关知识等着你来学习!