MySQL高可用（一）主備同步：MySQL是如何保證主備一致的

主備同步，也叫主從複製，是MySQL提供的一種高可用的解決方案，保證主備數據一致性的解決方案。

在生產環境中，會有不少不可控因素，例如數據庫服務掛了。爲了保證應用的高可用，數據庫也必需要是高可用的。

所以在生產環境中，都會採用主備同步。在應用的規模不大的狀況下，通常會採用一主一備。

除了上面提到的數據庫服務掛了，可以快速切換到備庫，避免應用的不可用外，採用主備同步還有如下好處：

提高數據庫的讀併發性，大多數應用都是讀比寫要多，採用主備同步方案，當使用規模愈來愈大的時候，能夠擴展備庫來提高讀能力。

備份，主備同步能夠獲得一份實時的完整的備份數據庫。

快速恢復，當主庫出錯了（好比誤刪表），經過備庫來快速恢復數據。對於規模很大的應用，對於數據恢復速度的容忍性很低的狀況，經過配置一臺與主庫的數據快照相隔半小時的備庫，當主庫誤刪表，就能夠經過備庫和binlog來快速恢復，最多等待半小時。

說了主備同步是什麼和好處，下面讓咱們來了解一下主備同步是怎麼實現的。

主備同步的實現原理

咱們先來了解一下主備同步的原理，下面以一個update語句來介紹主庫與備庫間是如何進行同步的。

上圖是一個update語句在節點A執行，而後同步到節點B的完整流程圖，具體步驟有：

1. 主庫接受到客戶端發送的一條update語句，執行內部事務邏輯，同時寫binlog。
2. 備庫經過 change master 命令，設置主庫的IP、端口、用戶名和密碼，以及要從哪一個位置開始請求 binlog。這個位置包含文件名和偏移量。
3. 在備庫上執行start slave命令，啓動兩個線程 io_thread 和 sql_thread，其中 io_thread 負責與主機進行鏈接。
4. 主庫校驗完用戶名和密碼，按照接收到的位置去讀取binlog，發給備庫。
5. 備庫接收到binlog後，寫到本地文件（relay log，中轉文件）。
6. 備庫讀取中轉文件，解析出命令，而後執行。

主備同步的工做原理其實就是一個徹底備份加上二進制日誌備份的還原。不一樣的是這個二進制日誌的還原操做基本上是實時的。

備庫經過兩個線程來實現同步：

• 一個是 I/O 線程，負責讀取主庫的二進制日誌，並將其保存爲中繼日誌。
• 一個是 SQL 線程，負責執行中繼日誌。

從上面的流程能夠看出，主備同步的關鍵是binlog，在前面的文章裏也有介紹過binlog的相關內容，感興趣的小夥伴能夠點擊查看。

常見的兩種主備切換流程

M-S結構

M-S結構，兩個節點，一個當主庫、一個當備庫，不容許兩個節點互換角色。

在狀態1中，客戶端的讀寫都直接訪問節點A，而節點B是A的備庫，只是將A的更新都同步過來，到本地執行。這樣能夠保持節點B和A的數據是相同的。

當須要切換的時候，就切成狀態2。這時候客戶端讀寫訪問的都是節點B，而節點A是B的備庫。

雙M結構

雙M結構，兩個節點，一個當主庫，一個當備庫，容許兩個節點互換角色。

對比前面的M-S結構圖，能夠發現，雙M結構和M-S結構，其實區別只是多了一條線，即節點A和B之間老是互爲主備關係。這樣在切換的時候就不用再修改主備關係。

雙M結構的循環複製問題

在實際生產使用中，多數狀況是使用雙M結構的。可是，雙M結構還有一個問題須要解決。

業務邏輯在節點A執行更新，會生成binlog並同步到節點B。節點B同步完成後，也會生成binlog。（log_slave_updates設置爲on，表示備庫也會生成binlog）。

當節點A同時也是節點B的備庫時，節點B的binlog也會發送給節點A，形成循環複製。

解決辦法：

• 設置節點的server-id，必須不一樣，否則不容許設置爲主備結構
• 備庫在接到binlog後重放時，會記錄原記錄相同的server-id，即誰產生即爲誰的。
• 每一個節點在接受binlog時，會判斷server-id，若是是本身的就丟掉。

解決後的流程：

1. 業務邏輯在節點A執行更新，會生成帶有節點A的server-id的binlog。
2. 節點B接受到節點A發過來的binlog，並執行完成後，會生成帶有節點A的server-id的binlog。
3. 節點A接受到binlog後，發現是本身的，就丟掉。死循環就在這裏斷掉了。

參考資料

• 24 | MySQL是怎麼保證主備一致的？