輕松讀懂MySQL主從復制演進過程

（1）前言

今天來和大家聊聊Mysql的復制演進過程，熟悉MySQL的同學應該都知道什么是MySQL復制mysql，關于這塊知識網絡上也有各種材料，筆者查找過很多資料，發現很多材料都描述得不夠全面，光看單篇文章難以建立整體概念，因此梳理了一版淺顯全面的文章出來，幫助大家輕松讀懂MySQL復制演進過程。

言歸正傳，一直以來，MySQL的主從復制都常常被大家詬病，總結原因有以下幾點：

1. 主從復制速度問題(這是最主要的)

mysql采取的復制方式是，主機執行提交之后將語句記錄進binlog，備機啟動一個IO線程從主傳輸binlog到本地，進入本地的relaylog；然后備機會另外啟動一個SQL線程負責順序執行relaylog中的語句，對語句在備機上重做，所以說這是一個異步的拷貝過程。這樣會導致一個問題，就是備機數據大部分情況下會延后。主機對本地磁盤的IO、備機從主機傳輸的網絡IO、備機本地的磁盤IO、最后備機重放數據的IO，經過了四個過程，即使服務器和網絡配置都很快，理論上也一定是有延遲的；如果服務器和網絡配置有瓶頸，這個延遲就會擴大化到影響業務的程度，最直接的就是讀寫分離的情況下，導致前端寫入操作明明已經返回完成了，后端讀數據時卻顯示沒有完成。

2. 主機宕機切換后臟數據問題

mysql的主備目的之一，就是在主宕機的情況下，能及時切換到備機繼續提供服務，不至于整個系統掛掉，即故障轉移。但就是因為主從復制要經過復制這一消耗IO的步驟，主在掛掉的一瞬間，一般主備機都會有一定量的數據區別，這些在主機執行完畢了但還未傳輸到備機上的數據，就是所謂的臟數據。這樣的臟數據，同樣會導致前后不一致，如果服務器和網絡配置不高，本來同步復制就慢的情況下，會導致極大的差別。

2009年oracle公司收購了sun，對mysql進行升級換代之后，有了巨大的改進，在5.5、5.6、5.7版本都針對主從有升級改造，在目前的5.7版本達到了非常高的可用性，配合最新的HA中間件mysql fabric，可以達到以前的幾倍的穩定性。下面來詳細講一講這三個版本中，oracle都對主從具體做了什么改進。

（2）MySQL5.5版本

1. 5.5版本添加了一個semi-sync replication（半同步復制）的插件，這個插件就是為了優化同步復制的臟數據問題而生的。

2.?半同步復制在提交過程中增加了一個延遲，在提交事務后，只有在備庫收到了該事務的binlog時才會給客戶端進行查詢結束的反饋。這會給客戶端查詢體驗增加一些延遲，不過問題不大，因為相對于寫入硬盤的時間，通過網絡傳輸些日志的時延不算什么。重要的是，半同步復制不會阻塞事務的提交，而是阻塞在給客戶端的反饋；當備庫一直沒有回應已收到事件，主庫會超時并轉化成正常的異步復制模式。

3. 順帶提一下半同步復制簡單原理：在傳輸binlog時，要求備機返回ack證明自己拿到了數據，在至少一個備機返回ack后，主機才將數據修改提交到本地，這樣能保證至少一個備機和主機是完全一致的。

4. 再舉個例吧：當在主機上持續不斷insert數據時，始終有一部分數據處在傳輸到備機的過程中，這部分數據在主機上已經是執行成功的狀態，但因為還沒傳輸完成收到任何一臺備機的回應，所以尚未持久化。這個瞬間主機宕機了，數據傳輸不完，備機的回應也收不到了，主機重啟后，主機上的這部分數據因為沒有收到回應進行持久化，所以消失了。而備機上的這部分數據因為尚未接收完全，也不能作為一個relaylog提交執行，所以備機也沒有這部分數據。最終的結果就是，這部分臟數據就被丟棄了，不會造成主從的不一致。

5. 優點：保證至少一個備機和主機在任何時候都是一致的，不會出現你比我多或者我比你多的情況，不需要進行主從恢復后的數據恢復行為。在只有一主一從的情況下，整個系統永遠不會有臟數據。

6. 缺點：顯而易見的，一主多備的情況下，除了只有一臺備機的情況外，其他備機都會有數據不一致現象。另外，沒有成功傳輸的數據就被直接丟棄了，找都找不回來，如果涉及金融交易，瞬時的數據丟失也是不可原諒的，所以這種架構在數據重要度非常高的業務里不能用。

（3）MySQL5.6版本

1.?5.6版本對主從同步進行了改進，加入了GTID（5.6.2開始，5.6.10完善）的事務區分標志，又加入了多線程復制和組提交的新模式。

2. GTID：在MySQL5.6以前對于主從復制出現問題有時候需要分析BINLOG找到POS點，然后再CHANG MASTER TO。容易犯錯，造成主從復制錯誤。引入GTID后,不需要再尋找BINLOG和POS點，只需要知道MASTER的IP、密碼、端口就可以，MySQL會從內部GTID機制自動找到同步點。加入GTID后，一是可以根據GTID可以知道事務最初是在哪個實例上提交的，二是GTID的存在也方便了Replication的Failover。

3. GTID原理：分成兩部分，一部分是服務的UUID，保存在mysql數據目錄的auto.cnf文件中，這是一個非常重要的文件，不能刪除，這一部分是不會變的。另外一部分就是事務ID（TID）了，隨著事務的增加，其值依次遞增。

4.?多線程并發復制：在MySQL5.6之前，復制是單線程隊列式的,只能一個一個運行。在新版中支持基于庫的多線程復制，但是庫里的表不能多線程。針對多個庫的情況，開啟多線程，每個庫一個獨立IO線程，可以交叉并發傳輸。在不同庫同一時間進行的操作理論上是互不影響的，可以同步進行，你改你的，我改我的。極大改善了多庫業務的復制速度。貼個經典的圖。

5.?5.6的并行復制框架實際包含了一個協調線程和若干個工作線程，協調線程負責分發和解決沖突，工作線程只負責執行。

6.?但是多線程并發復制也不一定完全有效，其并行只是基于schema的，也就是基于庫的。如果用戶的MySQL數據庫實例中存在多個schema，對于備機復制的速度的確可以有比較大的幫助。但如果業務始終只有一個庫，或者數據庫壓力都集中在一個庫上，其他庫基本沒什么操作，那針對庫的多線程基本沒有意義，還是和以前的單線程復制是一樣的速度。所以說MySQL 5.6所謂的并行復制對真正用戶來說，有點雷聲大雨點小。

7.?組提交：極大提升了binlog和innodb的redolog的落盤（保存到磁盤）效率，可將多次磁盤IO可以合并成一次磁盤IO，減少讀寫次數，有效提高了寫日志的速度。也就意味著在主從同步過程中，磁盤IO這一塊的效率提高了。

8. 組提交的原理：多個事務同時執行完成，數據需要持久化到log中時，會全部進入一個待提交隊列。最先進入隊列的事務線程成為leader線程，其他后續進入的成為follower線程，leader線程將會獲得這個隊列的控制權，就是會獲得一個鎖，全權負責本次隊列中所有事務的落盤操作。接著聯系其他follower線程，將他們的提交內容獲取得到，并讓他們等待自己完成操作。接著這個leader線程會進入后續的落盤過程，等完成后，會通知本隊列中所有follower線程落盤已經完成，可以返回成功狀態了。

（4）MySQL5.7版本

1.?MySQL 5.6基于庫的并行復制出來后，基本無人問津，在沉寂了一段時間之后，MySQL 5.7出來了，它的并行復制以一種全新的姿態出現在用戶面前。MySQL 5.7才可稱為真正的并行復制，這其中最為主要的原因就是slave服務器的回放與master是一致的，即master服務器上是怎么并行執行的，那么slave上就怎樣進行并行回放。不再有庫的并行復制限制，對于binlog格式也無特殊的要求（基于庫的并行復制也沒有要求）。

2. 5.7之所以被看作mysql主從復制上一個劃時代的版本，主要原因是mysql將日志組提交的模式應用到了主從網絡IO上，在原來已經通過組提交優化了的磁盤IO效率基礎上，對網絡IO效率進行了同樣的優化，正是將困擾mysql主從復制多年的兩大難題解決的最重要版本。官方稱之為Enhanced Multi-Threaded Slave（簡稱MTS）。

3. MTS這么牛，再多點一下：增強的多線程復制，即通過備機開啟多個IO線程，主機通過組提交的模式并行地傳輸事務進行復制。具體思想簡單易懂，一言以蔽之：一個組提交的事務都是可以并行回放的，若這些事務都已進入到事務的prepare階段，則說明事務之間沒有任何沖突（否則就不可能提交），關于MTS的詳細原理和實現，可以查閱資料詳細學習一下，這里點到為止。

4. 但是前面提到的網絡IO是有先后順序的，和傳輸順序通常是不同的，收到事務后需要區分先后順序來執行，否則備機執行順序和主機不同，數據同樣會出錯。獲取事務先后順序的方法也很簡單，就是使用的MYSQL 5.6已經加入的GTID，因為每個事務在提交時已經按順序生成了唯一的GTID，備機讀到事務后按照GTID的順序執行就可以了。

5. 在這樣的模式下，從機可以同時消費主機的多個事務隊列，在同一時間接收到更多的數據傳輸，有效降低了數據來不及傳輸而導致的宕機數據丟失的概率。

6.最后提一個問：MySQL5.7是如何識別哪些事務是要一起提交的呢？

其實就是在GTID event 中增加了兩個字段：int64 last committed和int64 sequence number,同一個組提交里多個事務gtid不同，但last committed卻是一致的，同時一個組里的last?committed對應上一個事務的sequence?number。當slave的coordinator線程在分發這些event的時候，具有相同last committed 的事務(event的集合)就可以同時發送給不同的work線程，達到并行同步的目的。

總結一下，MySQL復制演進歷程大致可以概括為：從5.5的單線程復制，到5.6基于Schema級別的并行復制，再到5.7最大化還原主庫的支持事務級別的并行復制。其實總體來看其發展是有連貫的前因后果的，大致了解MySQL復制的來龍去脈之后，再去摳細節會清晰許多。

數據復制服務 DRS 數據庫 Mysql 云計算

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。