MySQL半同步Semi-sync原理介紹

若是還不瞭解Semi-sync能夠閱讀（Manual | 概述）

1. 優勢

當事務返回客戶端成功後，則日誌必定在至少兩臺主機上存在。

MySQL在加載並開啓Semi-sync插件後，每個事務需等待備庫接收日誌後才返回給客戶端。若是作的是小事務，兩臺主機的延遲又較小，則Semi-sync能夠實如今性能很小損失的狀況下的零數據丟失。

2. 缺點

完成單條事務增長了額外的等待延遲，延遲的大小取決於網絡的好壞。

Semi-sync不是分佈式事務，主庫會在本身完成事務後，等待備庫接收事務日誌。

3. 主機Crash時的處理

 

備庫Crash時，主庫會在某次等待超時後，關閉Semi-sync的特性，降級爲普通的異步複製，這種狀況比較簡單。

主庫Crash後，那麼可能存在一些事務已經在主庫Commit，可是尚未傳給任何備庫，咱們姑且稱這類事務爲"牆頭事務"。"牆頭事務"都是沒有返回給客戶端的，因此發起事務的客戶端並不知道這個事務是否已經完成。

這時，若是客戶端不作切換，只是等Crash的主庫恢復後，繼續在主庫進行操做，客戶端會發現前面的"牆頭事務"都已經完成，能夠繼續進行後續的業務處理；另外一種狀況，若是客戶端Failover到備庫上，客戶端會發現前面的「牆頭事務」都沒有成功，則須要從新作這些事務，而後繼續進行後續的業務處理。

4. 其餘

能夠作多個備庫，任何一個備庫接收完成日誌後，主庫就能夠返回給客戶端了。

網絡傳輸在併發線程較多時，一次可能傳輸不少日誌，事務的平均延遲會下降。

"牆頭事務"在牆頭上的時候，是能夠被讀取的，可是這些事務在上面Failover的場景下，是被認爲沒有完成的。

 

semi-synchronous並非100%的保證數據不會丟失，若是master在完成事務並將其發送給slave的時候崩潰，仍然可能形成數據丟失。只是相比於傳統的異步複製，semi-synchronous replication能極大地提高數據安全。更爲重要的是，它並不慢，MHA的做者都說他們在facebook的生產環境中使用了semi-synchronous（這裏），因此我以爲真心不必擔憂它的性能問題，除非你的業務量級已經徹底超越了facebook或者google。

 

另外，若是是一主多備的話，能夠認爲備庫永遠不會掛掉(能夠作多個備庫，任何一個備庫接收完成日誌後，主庫就能夠返回給客戶端了)。若是主庫掛掉的話，自動或者人工切換到其中任何一個備庫，這樣客戶端會從新操做上面失敗的數據(主庫可能有了，可也也可能沒有上個事物的數據)，由於對於客戶端來講，不管crash的主庫是否成功，客戶端都會失敗，客戶端都會對備庫從新操做上客戶端認爲失敗的那個事物。基本能夠保證了數據的不丟失問題。