簡單談?wù)凪ySQL的半同步復(fù)制

簡介

MySQL通過復(fù)制（Replication）實現(xiàn)存儲系統(tǒng)的高可用。目前，MySQL支持的復(fù)制方式有：

1. 異步復(fù)制（Asynchronous Replication）：原理最簡單，性能最好。但是主備之間數(shù)據(jù)不一致的概率很大。
2. 半同步復(fù)制（Semi-synchronous Replication）：相比異步復(fù)制，半同步復(fù)制犧牲了一定的性能，提升了主備之間數(shù)據(jù)的一致性（有一些情況還是會出現(xiàn)主備數(shù)據(jù)不一致）。
3. 組復(fù)制（Group Replication）：基于Paxos算法實現(xiàn)分布式數(shù)據(jù)復(fù)制的強一致性。只要大多數(shù)機器存活就能保證系統(tǒng)可用。相比半同步復(fù)制，Group Replication的數(shù)據(jù)一致性和系統(tǒng)可用性更高。
   

本文主要討論MySQL半同步復(fù)制。

半同步復(fù)制的基本流程

MySQL半同步復(fù)制的實現(xiàn)是建立在MySQL異步復(fù)制的基礎(chǔ)上的。MySQL支持兩種略有不同的半同步復(fù)制：AFTER_SYNC和AFTER_COMMIT（受rpl_semi_sync_master_wait_wait_point控制）。

開啟半同步復(fù)制時，Master在返回之前會等待Slave的響應(yīng)或超時。當(dāng)Slave超時時，半同步復(fù)制退化成異步復(fù)制。這也是MySQL半同步復(fù)制存在的一個問題。本文不討論Salve超時的情形（不討論異步復(fù)制）。

半同步復(fù)制AFTER_SYNC模式的基本流程

AFTER_SYNC模式是MySQL 5.7才支持的半同步復(fù)制方式，也是MySQL5.7默認(rèn)的半同步復(fù)制方式：

• Prepare the transaction in the storage engine(s).
  
• Write the transaction to the binlog, flush the binlog to disk.
  
• Wait for at least one slave to acknowledge the reception for the binlog events for the transaction.
  
• Commit the transaction to the storage engine(s).
  

半同步復(fù)制AFTER_COMMIT模式的基本流程

MySQL 5.5和5.6的半同步復(fù)制只支持AFTER_COMMIT：

• Prepare the transaction in the storage engine(s).
  
• Write the transaction to the binlog, flush the binlog to disk.
  
• Commit the transaction to the storage engine(s).
  
• Wait for at least one slave to acknowledge the reception for the binlog events for the transaction.
  

AFTER_SYNC和AFTER_COMMIT兩種方式的小結(jié)

AFTER_SYNC： 日志復(fù)制到Slave之后，Master再commit。
所有在master上commit的事務(wù)都已經(jīng)復(fù)制到slave。
所有已經(jīng)復(fù)制到slave的事務(wù)在master不一定commit了（比如，master將日志復(fù)制到slave之后，在commit之前宕機了）

AFTER_COMMIT：Master commit之后再將日志復(fù)制到Slave。
所有master上commit的事務(wù)不一定復(fù)制到slave。（比如，master commit之后，還沒來得及將日志復(fù)制到slave就宕機了）
所有已經(jīng)復(fù)制到slave的事務(wù)在master上一定commit了。
很明顯，AFTER_COMMIT在master宕機的情況下，無法保證數(shù)據(jù)的一致性（master commit之后，還沒來得及將日志復(fù)制到slave就宕機了）。本文接下來只討論AFTER_SYNC模式。
MySQL5.7.3開始支持配置半同步復(fù)制等待Slave應(yīng)答的個數(shù)：rpl_semi_sync_master_wait_slave_count 。

AFTER_SYNC模式下的異常情況分析

異常情況1：master宕機后，主備切換。

master執(zhí)行事務(wù)T，在將事務(wù)T的binlog刷到硬盤之前，master發(fā)生宕機。slave升級為master。master重啟后，crash recovery會對事務(wù)T進行回滾。主備數(shù)據(jù)一致。

master執(zhí)行事務(wù)T，在將事務(wù)T的binlog刷到硬盤之后，收到slave的ACK之前，master發(fā)生宕機（存在pendinglog）。slave升級為master。

2.1 slave還沒有收到事務(wù)T的binlog，master重啟后，crash recovery會直接提交pendinglog。主備數(shù)據(jù)不一致。

2.2 slave已經(jīng)收到事務(wù)T的binlog。主備數(shù)據(jù)一致。

異常情況2：master宕機后，不切換主機。只需考慮異常情況1中的2.1。

master重啟后，直接提交pendinglog，此時，主備數(shù)據(jù)不一致：

slave連接上master，通過異步復(fù)制的方式獲得事務(wù)T的binlog。主備數(shù)據(jù)一致。
slave還沒來得及復(fù)制事務(wù)T的binlog，如果master又發(fā)生宕機，磁盤損壞。主備數(shù)據(jù)不一致，事務(wù)T的數(shù)據(jù)丟失。
異常情況處理

從上面異常情況的簡單分析我們得知，半同步復(fù)制需要處理master宕機后重啟存在pendinglog（slave沒有應(yīng)答的binlog）的特殊情況。

針對master宕機后，不進行主備切換的情形：

在crash recovery之后，master等到slave的連接和復(fù)制，直到至少有一個slave復(fù)制了所有已提交的事務(wù)的binlog。（SHOW MASTER STATUS on master and SELECT master_pos_wait()  on slave）。

針對master宕機后，進行主備切換的情形：

舊master重啟后，在crash recovery時，對pendinglog進行回滾。（人工截斷master的binlog未復(fù)制的部分？）

思考

為什么master重啟之后，crash recovery的過程中，是直接commit pendinglog，而不是重試請求slave的應(yīng)答呢？

MySQL的異步復(fù)制和半同步復(fù)制都是由slave觸發(fā)的，slave主動去連接master同步binlog。

沒有發(fā)生主備切換，機器重啟后無法知道哪臺機器是slave。
如果發(fā)生主備切換，它已經(jīng)不是master了，則不會再有slave連上來。如果繼續(xù)等待，則無法正常運行。

總結(jié)

MySQL半同步復(fù)制存在以下問題：

1. 當(dāng)Slave超時時，會退化成異步復(fù)制。
2. 當(dāng)Master宕機時，數(shù)據(jù)一致性無法保證，需要人工處理。
3. 復(fù)制是串行的。

正因為MySQL在主備數(shù)據(jù)一致性存在著這些問題，影響了互聯(lián)網(wǎng)業(yè)務(wù)7*24的高可用服務(wù)，因此各大公司紛紛祭出自己的“補丁”：騰訊的TDSQL、微信的PhxSQL、阿里的AliSQL、網(wǎng)易的InnoSQL。

MySQL官方已經(jīng)在MySQL5.7推出新的復(fù)制模式——MySQL Group Replication。

參考文獻

MySQL半同步復(fù)制的數(shù)據(jù)一致性探討

MySQL High Availability Solutions

Loss-less Semi-Synchronous Replication on MySQL 5.7.2

Enhanced semisync replication