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 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的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!