簡單談談MySQL的半同步復制

更新時間：2017年03月12日 08:47:15 作者：linjinhe

從MySQL5.5開始，MySQL以插件的形式支持半同步復制。如何理解半同步呢？今天我們就來詳細講解下，希望大家能夠喜歡。

簡介

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

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

本文主要討論MySQL半同步復制。

半同步復制的基本流程

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

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

半同步復制AFTER_SYNC模式的基本流程

AFTER_SYNC模式是MySQL 5.7才支持的半同步復制方式，也是MySQL5.7默認的半同步復制方式：

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).

半同步復制AFTER_COMMIT模式的基本流程

MySQL 5.5和5.6的半同步復制只支持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兩種方式的小結

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

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

AFTER_SYNC模式下的異常情況分析

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

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

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

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

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

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

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

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

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

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

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