544
MySQL5.7 & AliSQL5.6 半同步複製 rpl_semi_sync_master_wait_point參數
MySQL5.5 開始支持半同步複製，但實現的不完善，slave ack 是在 master
commit 之後。如果 master 宕機，會有數據丟失的風險。如下圖可以看出，主庫在 commit 之後宕機，如果從庫還未收到 binlog ，主從切換後可能會出現數據丟失的現象。
MySQL5.7 & AliSQL5.6 增加了 rpl_semi_sync_master_wait_point 參數來修複這個問題。先來看看這個參數是做什麼用的。官方文檔解釋如下：
The rpl_semi_sync_master_wait_point system variable controls the point at which a semisynchronous replication master waits for slave acknowledgment of transaction receipt before returning a status to the client that committed the transaction.
簡單來講就是控製 master 在哪個環節接收 slave ack，master 接收到 ack 後返回狀態給客戶端。
此參數一共有兩個選項 AFTER_SYNC（default） & AFTER_COMMIT。
我們先來看看舊的邏輯（AFTER_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 write binlog -> slave sync binlog -> master commit -> salve ack -> master return result。
這樣會有什麼問題呢？
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.
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.
- 會出現髒讀的情況，也就是在事務提交之後，slave 確認之前，客戶端A還沒有獲得結果返回，但是客戶端B能夠讀取A提交的結果；
- 可能會出現我們上文提到的數據丟失的問題；
這些問題對於數據一致性要求高的場景是無法滿足的，所以 MySQL5.7 提供了 AFTER_SYNC 模式來避免這些問題。
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 write binlog -> slave sync binlog -> salve ack -> master commit -> master return result。這樣就保證 master commit 的事務已經同步到 slave 了，防止數據丟失。
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.
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.
- 保證所有客戶端查詢到的結果都是相同的；
- 保證 slave 不會丟數據；
- master 宕機雖然不會導致數據丟失，但有一種情況可能會出現，那就是 salve 的數據比 master 多，大家可以回顧下流程，想想為什麼，該如何處理。
AliSQL5.6 半同步複製已經實現此功能，並且是整合到主代碼裏原生支持的，而 MySQL 半同步是通過插件的形式支持
最後更新：2017-07-20 17:02:35