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

这篇文章主要介绍了MySQL 5.7半同步复制after sync和after commit的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
如果你的生产库开启了半同步复制，那么对数据的一致性会要求较高，但在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 h免费主机域名as 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线程没有执行，那么主库崩溃和故障转移给从服务器的前提下，有可能这个客户端会丢失那些他们曾经在主库上看到的信息。
感谢你能够认真阅读完这篇文章，希望小编分享的“MySQL 5.7半同步复制after sync和after commit的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持云技术，关注云技术行业资讯频道，更多相关知识等着你来学习!

相关推荐: MySQL5.6中sql_mode常用值的示例分析

这篇文章主要介绍了MySQL5.6中sql_mode常用值的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。 SQL Mode 定义了两个方面：MySQL应支持的SQL语法，以及应该在数据…