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

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

異步復制（Asynchronous replication）：

MySQL默認的復制即是異步的，主庫在執行完客戶端提交的事務后會立即將結果返給給客戶端，并不關心從庫是否已經接收并處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能并沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的數據不完整。

全同步復制（Fully synchronous replication）：

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

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

下面來看看半同步復制的原理圖：

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

1.事務還沒發送到從庫上

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

2.事務已經發送到從庫上

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

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

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

1.AFTER_SYNC

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

2.AFTER_COMMIT

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

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