遠程數(shù)據(jù)復(fù)制技術(shù)利用通信技術(shù)、計算機技術(shù)實現(xiàn)遠程的數(shù)據(jù)備份，減少數(shù)據(jù)丟失帶來的損失。在遠程數(shù)據(jù)備份的數(shù)據(jù)復(fù)制傳輸規(guī)則方面,目前傳統(tǒng)的規(guī)則有同步、異步和半同步復(fù)制規(guī)則,可以基本保證不同應(yīng)用對數(shù)據(jù)復(fù)制的需求。自MySQL5.5版本以來，MySQL以插件的形式支持半同步復(fù)制。MySQL半同步復(fù)制逐漸成為MySQL遠程數(shù)據(jù)復(fù)制技術(shù)的主要規(guī)則之一。

在我們正式介紹MySQL半同步復(fù)制之前，我們先來看看異步復(fù)制和全同步復(fù)制的概念：

異步復(fù)制（Asynchronous replication）：

MySQL默認的復(fù)制即是異步的，主庫在執(zhí)行完客戶端提交的事務(wù)后會立即將結(jié)果返給給客戶端，并不關(guān)心從庫是否已經(jīng)接收并處理，這樣就會有一個問題，主如果crash掉了，此時主上已經(jīng)提交的事務(wù)可能并沒有傳到從上，如果此時，強行將從提升為主，可能導(dǎo)致新主上的數(shù)據(jù)不完整。

全同步復(fù)制（Fully synchronous replication）：

指當主庫執(zhí)行完一個事務(wù)，所有的從庫都執(zhí)行了該事務(wù)才返回給客戶端。因為需要等待所有從庫執(zhí)行完該事務(wù)才能返回，所以全同步復(fù)制的性能必然會收到嚴重的影響。

介于異步復(fù)制和全同步復(fù)制之間，主庫在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個從庫接收到并寫到relay log中才返回給客戶端。相對于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步復(fù)制最好在低延時的網(wǎng)絡(luò)中使用。

下面來看看半同步復(fù)制的原理圖：

客戶端事務(wù)在存儲引擎層提交后，在得到從庫確認的過程中，主庫宕機了，此時，可能的情況有兩種：

1.事務(wù)還沒發(fā)送到從庫上

此時，客戶端會收到事務(wù)提交失敗的信息，客戶端會重新提交該事務(wù)到新的主上，當宕機的主庫重新啟動后，以從庫的身份重新加入到該主從結(jié)構(gòu)中，會發(fā)現(xiàn)，該事務(wù)在從庫中被提交了兩次，一次是之前作為主的時候，一次是被新主同步過來的。

2.事務(wù)已經(jīng)發(fā)送到從庫上

此時，從庫已經(jīng)收到并應(yīng)用了該事務(wù)，但是客戶端仍然會收到事務(wù)提交失敗的信息，重新提交該事務(wù)到新的主上。

針對上述的潛在問題，MySQL 5.7引入了一種新的半同步方案：Loss-Less半同步復(fù)制。“Waiting Slave dump”被調(diào)整到“Storage Commit”之前。

當然，之前的半同步方案同樣支持，MySQL 5.7.2引入了一個新的參數(shù)進行控制-rpl_semi_sync_master_wait_point，rpl_semi_sync_master_wait_point有兩種取值：

1.AFTER_SYNC

這個即新的半同步方案，Waiting Slave dump在Storage Commit之前。

2.AFTER_COMMIT

老的半同步方案，如原理圖所示。

當半同步復(fù)制發(fā)生超時時（由rpl_semi_sync_master_timeout參數(shù)控制，單位是毫秒，默認為10000，即10s），會暫時關(guān)閉半同步復(fù)制，轉(zhuǎn)而使用異步復(fù)制。當master dump線程發(fā)送完一個事務(wù)的所有事件之后，如果在rpl_semi_sync_master_timeout內(nèi)，收到了從庫的響應(yīng)，則主從又重新恢復(fù)為半同步復(fù)制。因此，在某種程度上說，半同步復(fù)制并不是嚴格意義上的半同步復(fù)制。或許在我們看完本站的MySQL教程中的異步復(fù)制和全同步復(fù)制的詳細介紹之后，我們會有自己的答案。