MySQL中的半同步複製
SQL/">MySQL當前存在的三種複製模式有：非同步模式、半同步模式和組複製模式。也有說是 同步複製、非同步複製和半同步複製。
從MySQL5.5開始，MySQL以外掛的形式支援半同步複製。
非同步複製（Asynchronous replication）
MySQL預設的複製即是非同步的 ，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能並沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的資料不完整。
非同步複製是MySQL最早的也是當前使用最多的複製模式，非同步複製提供了一種簡單的主-從複製方法，包含一個主庫（master）和備庫（一個，或者多個） 之間，主庫執行並提交了事務，在這之後（因此才稱之為非同步），這些事務才在從庫上重新執行一遍（基於statement）或者變更資料內容（基於 row），主庫不檢測其從庫上的同步情況。在伺服器負載高、服務壓力大的情況下主從產生延遲一直是其詬病。工作流程簡圖如下：
全同步複製（Fully synchronous replication）
指當主庫執行完一個事務， 所有的從庫 都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步複製的效能必然會收到嚴重的影響。
半同步複製（Semisynchronous replication）
介於非同步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待 至少一個 從庫接收到並寫到relay log中才返回給客戶端。相對於非同步複製，半同步複製提高了資料的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步複製最好在低延時的網路中使用。
MySQL5.5 的版本在非同步同步的基礎之上，以 外掛 的形式實現了一個變種的同步方案，稱之為半同步（semi-sync replication）。這個外掛在原生的非同步複製上，添加了一個同步的過程：當從庫接收到了主庫的變更（即事務）時，會通知主庫。主庫上的操作有兩種： 接收到這個通知以後才去commit事務 ； 接受到之後釋放session 。這兩種方式是由主庫上的具體配置決定的。 當主庫收不到從庫的變更通知超時時，由半同步複製自動切換到非同步同步 ，這樣就極大了保證了資料的一致性（至少一個從庫），但是在效能上有所下降，特別是在網路不穩定的情況下，半同步和同步之間來回切換，對正常的業務是有影響的。其工作流程簡圖如下：
下面來看看半同步複製的原理圖：
3、Group Replication（組複製）
不 論是非同步複製還是半同步複製，都是一個主下面一個從或是多個從的模式，在高併發下高負載下，都存在延遲情況，此時如果主節點出現異常，那麼就會出現資料不 一致的情況，資料可能會丟，在金融級資料庫中是不能容忍的。在這種情況下，急需出現一種模式來解決這些問題。在MySQL5.7.17的版本中，帶著這些 期待，新的複製模式組複製產生並GA了（本文的測試等資料均基於MySQL5.7.17）。
組複製的工作流程圖如下： 
組複製的工作原理: ofollow,noindex">http://www.sohu.com/a/124913450_354963
半同步複製的潛在問題
客戶端事務在儲存引擎層提交後，在得到從庫確認的過程中，主庫宕機了，此時，可能的情況有兩種：
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有兩種取值
AFTER_SYNC
這個即新的半同步方案，Waiting Slave dump在Storage Commit之前。
AFTER_COMMIT
老的半同步方案，如圖所示。
三種複製方案的區別
非同步複製
MySQL複製預設是非同步複製，Master將事件寫入binlog，提交事務，自身並不知道slave是否接收是否處理；
缺點：不能保證所有事務都被所有slave接收。
同步複製
Master提交事務，直到事務在所有slave都已提交，才會返回客戶端事務執行完畢資訊；
缺點：完成一個事務可能造成延遲。
半同步複製
當Master上開啟半同步複製功能時，至少有一個slave開啟其功能。當Master向slave提交事務，且事務已寫入relay-log中並重新整理到磁碟上，slave才會告知Master已收到；若Master提交事務受到阻塞，出現等待超時，在一定時間內Master 沒被告知已收到， 此時Master自動轉換為非同步複製機制 ；
注：半同步複製功能要在Master和slave上開啟才會起作用，只開啟一邊，依然是非同步複製。