mysql中三種復制機制異步復制，半同步復制和并行復制詳細介紹

下面一起來了解下mysql中三種復制機制異步復制，半同步復制和并行復制，相信大家看完肯定會受益匪淺，文字在精不在多，希望mysql中三種復制機制異步復制，半同步復制和并行復制這篇短內容是你想要的。

**# 異步復制

異步復制是MySQL自帶的最原始的復制方式，主庫和備庫成功建立復制關系后，在備庫上會有一個IO線程去主庫拉取binlog，并將binlogx到本地，就是下圖中Relaylog，然后備庫會開啟另外一個SQL線程取回放Relay  log，通過這種方式達到Master-Slave數據同步的目的。

通常情況下，slave是只讀的，可以承擔一部分讀流量，而且可以根據實際需要，添加一個或者多個slave，這樣在一定程度上可以緩解主庫的讀壓力；

    另一方面，若Master出現異常（crash,硬件故障等），無法對外提供服務，此時Slave可以承擔起master的重任，避免了單點的產生，所以復制就是為容災和提高性能而生。

**  半同步復制**
**1.概念**
一般情況下，異步復制就已經足夠應付了，但由于是異步復制，備庫極有可能是落后于主庫，特別是極端情況下，我們無法保證主備數據是嚴格一致的（即使我們觀察到Seconds  Behind  Master這個值為0）

比如，當用戶發起commit命令時，Master并不關心slave的執行狀態，執行成功后，立即返回給用戶。試想下，若一個事務提交后，master成功返回給用戶后crash，這個事務的binlog還沒來得及傳遞到slave，那么slave相對于master而言就少了一個事務，此時主備就不一致了。對于要求強一致的業務是不可以接受的，半同步復制就是為了解決數據一致性而產生的。

為什么叫半同步復制？我們來先說說同步復制，所謂同步復制就是一個事務在master和slave都執行后，才返回給用戶執行成功。這里核心是說master和slave要么都執行，要么都不執行，涉及到2pc（2  phrase  commit)。而MySQL只實現了本地redo-log和binlog的2PC，但并沒有實現master和slave的2PC，所以不是嚴格意義上的同步復制。而MySQL半同步復制不要求slave執行，而僅僅是接收到日志后，就通知master可以返回了。

  這里關鍵點是slave 接受日志后是否執行，若執行后才通知master則是同步復制，若僅僅是接受日志成功，則是半同步復制。

     半同步復制如何實現？半同步復制實現的關鍵點是master對于事務提交過程特殊處理。目前實現半同步復制主要是有兩種模式，AFTER_SYNC模式和AFER_COMMIT模式。兩種方式的主要區別在與是否在存儲引擎提交后等待slave的ACK.

     2、AFTER_COMMIT模式
           先來看看AFTER_COMMIT模式，start和End分別表示用戶發起commit命令和master返回給用戶的時間點，中間部分就是整個commit過程master和slave做的事情。

                 master提交時，會首先將該事務的redo  log刷入磁盤（這里其實還涉及到兩階段提交的問題），然后進入Inodb  commit過程，這個步驟主要是釋放鎖，標記事務為提交狀態（其他用戶可以看到該事務的更新），這個過程完成后，等待slave發送ack消息，等到slave的響應后，master才成功返回給用戶，master和slave的同步邏輯，是master-slave一致性的保證。

        3、AFTER_SYNC模式
        與AFTER_COMMIT相比，Master在AFTER_SYNC模式下，fsync  binlog后，就開始等待slave同步，那么在進行第5步innodbcommit后，即其他事務能看到該事務的更新時，slave已經成功接收到binlog，即使發生切換，slave擁有與master同樣的數據，不會發生“幻讀”現象。但是對于上面描述的第一種情況，結果是一樣的。

        所以，在極端情況下，半同步復制的master-slave會有一個事務不一致，但是對于用戶而言，由于這個事務并沒有成功返回給用戶，所以無論事務提交與否都是可以接受的，用戶有必要進行查詢或重試，判讀是否更新成功。或者我們想想，對于單機而言，若事務執行成功后，返回給用戶時，網絡斷了，用戶也是面臨一樣的問題，所以，這不是半同步復制的問題，對于提交返回成功的事務，半同步復制保證master-slave一定是一致的，從這個角度來看，半同步復制不會丟數據，可以保證master-slave的強制性。

并行復制
半同步復制解決了Master-slave 強一致問題，那么性能問題呢？參與復制的兩個線程：IO線程和SQL線程，分別用于拉取和回放binlog。對于slave而言，所有拉取和解析binlog的動作都是串行的，相對與master并發處理用戶請求，在高負載下，若master產生binlog的速度超過slave消費binlog的速度，導致slave出現延遲，可以看到,users和master之間的管道遠遠大于master和salve之間的管道。

 那么如何并行化，并行io線程，還是并行sql線程？其實兩方面都可以并行，但是并行sql線程的收益更大，因為sql線程做的事情更多（解析，執行）。并行IO線程，可以將從master拉取和寫入relay  log分為兩個線程；并行sql線程則可以根據需要做到庫級并行，表級并行，事務級并行。庫級并行在MySQL官方版本5.6已經實現了。并行復制框架實際包含了一個協調線程和若干個工作線程。協調線程負責分發和解決沖突，工作線程只負責執行。

 DB1,DB2和DB3的事務 就可以并發執行，提高了復制的性能。有時候庫級并發可能不夠，需要做表級并發，或更細粒的事務級并發。

 **并行復制如何處理沖突？**
   并發的世界是美好的，但不能亂并發，否則數據就亂了。master上面通過鎖機制來保證并發的事務有序進行，那么并行復制呢？slave必需保證回放的順序與master上事務執行順序一致，因此只要做到順序讀取binlog，將不沖突的事務并發執行即可。對于庫級并發而言，協調線程要保證執行同一個庫的事務放在一個工作線程串行執行；對于表級并發而言，協調線程要保證同一個表的事務串行執行；對于事務級而言，則是保證操作同一行的事務串行執行。

     **是否粒度越細，性能越好？**
      這個并不是一定的。相對與串行復制而言，并行復制多了一個協調線程。協調線程一個重要作用是解決沖突，粒度越細的并發，可能會有更多的沖突，最終可能也是串行執行的，但消耗了 大量的沖突檢測代價。
看完mysql中三種復制機制異步復制，半同步復制和并行復制這篇文章后，很多讀者朋友肯定會想要了解更多的相關內容，如需獲取更多的行業信息，可以關注我們的行業資訊欄目。