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

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

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

簡介

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

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

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

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

MySQL半同步復(fù)制的實(shí)現(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之前宕機(jī)了）

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

AFTER_SYNC模式下的異常情況分析

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

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

master執(zhí)行事務(wù)T，在將事務(wù)T的binlog刷到硬盤之后，收到slave的ACK之前，master發(fā)生宕機(jī)（存在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宕機(jī)后，不切換主機(jī)。只需考慮異常情況1中的2.1。

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

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

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

針對master宕機(jī)后，不進(jìn)行主備切換的情形：

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

針對master宕機(jī)后，進(jìn)行主備切換的情形：

舊master重啟后，在crash recovery時，對pendinglog進(jìn)行回滾。（人工截?cái)鄊aster的binlog未復(fù)制的部分？）

思考

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

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

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

總結(jié)

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