爛泥：學習mysql資料庫主從同步複製原理

標籤：style   blog   http   io   ar   color   os   使用   sp   

本文由秀依林楓提供友情贊助，首發於爛泥行天下。

說明本篇文章部分轉載自互連網。

MySQL的Replication（英文為複製）是一個多MySQL資料庫做主從同步的方案，特點是非同步複製，廣泛用在各種對MySQL有更高效能、更高可靠性要求的場合。與之對應的是另一個同步技術是MySQL Cluster，但因為MySQL Cluster配置比較複雜，所以使用者較少。

MySQL的Replication是一個非同步複製的過程（mysql5.1.7以上版本分為非同步複製和半同步兩種模式），它是從一個Mysql instance（instance英文為執行個體）(我們稱之為Master)複製到另一個Mysql instance(我們稱之slave)。在master與slave之間實現整個複製過程主要由三個線程來完成，其中兩個線程(SQL線程和IO線程)在slave端，另外一個線程(IO線程)在master端。

要實現MySQL的Replication，首先必須開啟master端的binlog (mysql-bin.xxxxxx)日誌功能，否則無法實現mysql的主從複製。因為mysql的整個主從複製過程實際上就是：slave端從master端擷取binlog日誌，然後再在自己身上完全順序的執行該日誌中所記錄的各種SQL操作。

有關具體如何開啟mysql的binlog日誌功能，可以查看這篇文章《爛泥：學習mysql的binlog配置》。

MySQL主從複製的基本互動過程，如下：

1、slave端的IO線程串連上master端，並請求從指定binlog記錄檔的指定pos節點位置(或者從最開始的日誌)開始複製之後的日誌內容。

2、master端在接收到來自slave端的IO線程請求後，通知負責複製進程的IO線程，根據slave端IO線程的請求資訊，讀取指定binlog日誌指定pos節點位置之後的日誌資訊，然後返回給slave端的IO線程。該返回資訊中除了binlog日誌所包含的資訊之外，還包括本次返回的資訊在master端的binlog檔案名稱以及在該binlog日誌中的pos節點位置。

3、slave端的IO線程在接收到master端IO返回的資訊後，將接收到的binlog日誌內容依次寫入到slave端的relaylog檔案(mysql-relay-bin.xxxxxx)的最末端，並將讀取到的master端的binlog檔案名稱和pos節點位置記錄到master-info（該檔案存在slave端）檔案中，以便在下一次讀取的時候能夠清楚的告訴master“我需要從哪個binlog檔案的哪個pos節點位置開始，請把此節點以後的日誌內容發給我”。

4、slave端的SQL線程在檢測到relaylog檔案中新增內容後，會馬上解析該log檔案中的內容。然後還原成在master端真實執行的那些SQL語句，並在自身按順豐依次執行這些SQL語句。這樣，實際上就是在master端和slave端執行了同樣的SQL語句，所以master端和slave端的資料是完全一樣的。

以上mysql主從複製互動過程比較拗口，理解起來也比較麻煩，我簡化了該互動過程。如下：

1、master在執行sql之後，記錄二進位log檔案（bin-log）。

2、slave串連master，並從master擷取binlog，存於本地relay-log中，然後從上次記住的位置起執行SQL語句，一旦遇到錯誤則停止同步。

從以上mysql的Replication原理可以看出：

* 主從間的資料庫不是即時同步，就算網路連接正常，也存在瞬間主從資料不一致的情況。

* 如果主從的網路斷開，則從庫會在網路恢複正常後，批量進行同步。

* 如果對從庫進行修改資料，那麼如果此時從庫正在在執行主庫的bin-log時，則會出現錯誤而停止同步，這個是很危險的操作。所以一般情況下，我們要非常小心的修改從庫上的資料。

* 一個衍生的配置是雙主、互為主從配置，只要雙方的修改不衝突，則可以工作良好。

* 如果需要多主庫的話，可以用環形配置，這樣任意一個節點的修改都可以同步到所有節點。

爛泥：學習mysql資料庫主從同步複製原理