阿粉在前面的幾篇文章中，說了索引的分析，索引的原理，以及慢查詢應該怎么去做合理的優化，接下來阿粉也給大家說說這個 MySQL 的組從復制到底是個怎么回事。

主從模式

MySQL主從模式是指數據可以從一個MySQL數據庫服務器主節點復制到一個或多個從節點。MySQL 默 認采用異步復制方式，這樣從節點不用一直訪問主服務器來更新自己的數據，從節點可以復制主數據庫 中的所有數據庫，或者特定的數據庫，或者特定的表。

mysql主從復制用途：

• 實時災備，用于故障切換（高可用）
• 讀寫分離，提供查詢服務（讀擴展）
• 數據備份，避免影響業務（高可用）

主從部署必要條件：

• 從庫服務器能連通主庫
• 主庫開啟binlog日志（設置log-bin參數）
• 主從server-id不

上面這些就是我們如果想要部署一套屬于自己的 MySQL 的主從復制時，需要的條件，那么主從復制都是什么原理呢？

主從復制的步驟

主從復制整體分為以下三個步驟：

第一步：主庫將數據庫的變更操作記錄到Binlog日志文件中

第二步：從庫讀取主庫中的Binlog日志文件信息寫入到從庫的Relay Log中繼日志中

第三步：從庫讀取中繼日志信息在從庫中進行Replay,更新從庫數據信息

上面的是文字描述，

我們再來一張原理圖看看：

在上述三個過程中，涉及了Master的BinlogDump Thread和Slave的I/O Thread、SQL Thread，它們的作用如下：

• Master服務器對數據庫更改操作記錄在Binlog中，BinlogDump Thread接到寫入請求后，讀取 Binlog信息推送給Slave的I/O Thread。
• Slave的I/O Thread將讀取到的Binlog信息寫入到本地Relay Log中。
• Slave的SQL Thread檢測到Relay Log的變更請求，解析relay log中內容在從庫上執行。 上述過程都是異步操作，俗稱異步復制，存在數據延遲現象。

但是如果我們這么看主從復制的話，是不是會發現一些問題呢？

MySQL主從復制的問題：

• 主庫宕機后，數據可能丟失
• 從庫只有一個SQL Thread，主庫寫壓力大，復制很可能延時

一般的，如果我們做了主從復制的話，那么數據庫一定出現過復制延遲的情況，如果你沒遇到過，說明你沒有發現過，但是實際上是肯定有過的，除非你已經想到了如何去解決這個問題了，那么解決這個問題的方式是什么呢？

• 半同步復制---解決數據丟失的問題
• 并行復制----解決從庫復制延遲的問題

那么什么是半同步復制，什么是并行復制呢？

半同步復制

為了提升數據安全，MySQL讓Master在某一個時間點等待Slave節點的 ACK（Acknowledge character）消息，接收到ACK消息后才進行事務提交，這也是半同步復制的基礎。

• 當Master不需要關注Slave是否接受到Binlog Event時，即為傳統的主從復制。
• 當Master需要在第三步等待Slave返回ACK時，即為 after-commit，半同步復制（MySQL 5.5引入）。
• 當Master需要在第二步等待 Slave 返回 ACK 時，即為 after-sync，增強半同步（MySQL 5.7引入）。

主庫等待從庫寫入 relay log 并返回 ACK 后才進行Engine Commit。

并行復制

其實 MySQL 的并行復制，每個版本都是不一樣的，因為他們的實現原理是不一樣的。

MySQL從5.6版本開始追加了并行復制功能，目的就是為了改善復制延遲問題，并行復制稱為enhanced multi-threaded slave（簡稱MTS）。

在從庫中有兩個線程IO Thread和SQL Thread，都是單線程模式工作，因此有了延遲問題，我們可以采 用多線程機制來加強，減少從庫復制延遲。

MySQL5.7版本，基于組提交的并行復制，這個才是真正意義的并行復制，從庫的并行復制跟master庫的是一致，并行復制基于一個前提，即所有已經處于prepare階段的事務，都是可以并行提交的。

MySQL8.0版本，基于write-set的并行復制，MySQL會有一個集合變量用來存儲事務修改的記錄信息（主鍵哈希值），當新的修改時已提交時，會進行判斷是否沖突，不沖突即可合并，這樣的并行的顆粒度就到row級別了，并行復制的速度更快

其實如果你想要進行并行復制的話，那么你還需要知道如何去進行并行復制的調優，只有這樣，你才能掌握好這個主從復制。

binlog_transaction_dependency_history_size 用于控制集合變量的大小。

binlog_transaction_depandency_tracking 用于控制binlog文件中事務之間的依賴關系，即last_committed值。

transaction_write_set_extraction用于控制事務的檢測算法，參數值為：OFF、 XXHASH64、MURMUR32

master_info_repository開啟MTS功能后，務必將參數master_info_repostitory設置為TABLE，這樣性能可以有50%~80%的提升。這是因為并行復制開啟后對于元master.info這個文件的更新將會大幅提升，資源的競爭也會變大。

slave_parallel_workers若將slave_parallel_workers設置為0，則MySQL 5.7退化為原單線程復制，但將 slave_parallel_workers設置為1，則SQL線程功能轉化為coordinator線程，但是只有1個worker線程進行回放，也是單線程復制。然而，這兩種性能卻又有一些的區別，因為多了一次coordinator線程的轉發，因此slave_parallel_workers=1的性能反而比0還要差。

這些參數實際上都是非常要掌握的，不然你再設置并行復制的時候，會遇到各種各樣的問題，所以你學會了么？

文章參考

《MySQL海量數據優化》 

《MySQL必知必會》 

《MySQL拍錯指南》