MySQL5.7半同步复制aftersync和aftercommit的示例分析

这篇文章主要介绍了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 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线程没有执行，那么主库崩溃和故障转移给从服务器的前提下，有可能这个客户端会丢失那些他们曾经在主库上看到的信息。

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

本文标题：MySQL5.7半同步复制aftersync和aftercommit的示例分析
分享路径：http://scjbc.cn/article/jdjoid.html