Mysql主從原理

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主從複製的基本交互過程，以下：

一、slave端的IO線程鏈接上master端，並請求從指定binlog日誌文件的指定pos節點位置(或者從最開始的日誌)開始複製以後的日誌內容。

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

三、slave端的IO線程在接收到master端IO返回的信息後，將接收到的binlog日誌內容依次寫入到slave端的relaylog文件(mysql-relay-bin.xxxxxx)的最末端，並將讀取到的master端的binlog文件名和pos節點位置記錄到master-info（該文件存在slave端）文件中，以便在下一次讀取的時候可以清楚的告訴master「我須要從哪一個binlog文件的哪一個pos節點位置開始，請把此節點之後的日誌內容發給我」。

四、slave端的SQL線程在檢測到relaylog文件中新增內容後，會立刻解析該log文件中的內容。而後還原成在master端真實執行的那些SQL語句，並在自身按順豐依次執行這些SQL語句。這樣，實際上就是在master端和slave端執行了一樣的SQL語句，因此master端和slave端的數據是徹底同樣的。

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

一、master在執行sql以後，記錄二進制log文件（bin-log）。

二、slave鏈接master，並從master獲取binlog，存於本地relay-log中，而後從上次記住的位置起執行SQL語句，一旦遇到錯誤則中止同步。

從以上mysql的Replication原理能夠看出：

* 主從間的數據庫不是實時同步，就算網絡鏈接正常，也存在瞬間主從數據不一致的狀況。

* 若是主從的網絡斷開，則從庫會在網絡恢復正常後，批量進行同步。

* 若是對從庫進行修改數據，那麼若是此時從庫正在在執行主庫的bin-log時，則會出現錯誤而中止同步，這個是很危險的操做。因此通常狀況下，咱們要很是當心的修改從庫上的數據。

* 一個衍生的配置是雙主、互爲主從配置，只要雙方的修改不衝突，則能夠工做良好。

* 若是須要多主庫的話，能夠用環形配置，這樣任意一個節點的修改均可以同步到全部節點