一文徹底搞懂MySql主從同步

這篇文章為大家帶來了關於MySql的相關知識，其中主要給大家介紹MySQL的主從同步及其作用原理等等，有興趣的朋友下面一起來看一下吧，歡迎大家收藏學習！

1 引言

大家好，Mysql是大家最常用的資料庫，以下為大家帶來mysql主從同步知識點的分享，以便鞏固mysql基礎知識，如有錯誤，還請各位大佬們指正。

2 MySql主從同步概述

MySQL主從同步，也就是MySQL Replication，可以實作將資料從一台資料庫伺服器同步到多台資料庫伺服器。 MySQL資料庫自備主從同步功能，經過配置，可實現基於函式庫、表格結構的多種方案的主從同步。

Redis是一種高效能的記憶體資料庫，但不是今天的主角；MySQL是基於磁碟檔案的關係型資料庫，相較於Redis來說，讀取速度會慢一些，但是功能強大，可以用於儲存持久化的資料。在實際工作中，我們常將Redis作為快取與MySQL配合來使用，當有資料存取請求的時候，首先會從快取中進行查找，如果存在就直接取出，如果不存在再存取資料庫，這樣就提升了讀取的效率，也減少了後端資料庫的存取壓力。使用Redis這種快取架構是高並發架構中非常重要的一環。

隨著業務量的不斷成長，資料庫的壓力會不斷變大，快取的頻繁變更也強烈依賴資料的查詢結果，導致資料查詢效率低，負載很高，連線過多等問題。對於電商場景來說，往往存在著許多典型的讀多寫少場景，我們可以對MySQL做主從架構並且進行讀寫分離，讓主伺服器（Master）處理寫入請求，從伺服器（Slave）處理讀取請求，這樣可以進一步提升資料庫的並發處理能力。如下圖：

上圖中，可以看到，我們增加了2個從函式庫，這2個從函式庫可以一起抗下大量的讀取請求，分擔主庫壓力。從庫會透過主從複製，從主庫中不斷的同步數據，以此來確保從庫的數據和主庫數據的一致。

接下來，我們來看看主從同步有哪些作用，以及主從同步具體是怎麼實現的。

3 主從同步的作用

一般來說，不是所有的系統都需要對資料庫進行主從架構的設計，因為架構本身就是有一定成本的，如果我們的目的在於提升資料庫高並發存取的效率，那麼我們首先應該優化SQL語句及索引，充分發揮資料庫的最大效能；其次是採用快取的策略，如使用Redis、MongoDB等快取工具，透過其高效能的優勢把資料保存在記憶體資料庫中，提升讀取的效率，最後才是對資料庫採用主從架構，進行讀寫分離。系統的使用和維護成本是根據架構的升級逐漸升高的。

言歸正傳，主從同步不僅可以提升資料庫的吞吐量，還有以下三個面向的功能：

3.1 讀寫分離

我們可以透過主從複製的方式來同步數據，然後透過讀寫分離來提升資料庫的同時處理能力。簡單來說就是我們的資料被放在了多個資料庫中，其中一個是Master主函式庫，其餘的就是Slave從函式庫。當主庫數據變化時，會自動將數據同步到從庫中，而我們程式可以從從庫讀取數據，也就是採用讀寫分離的方式。電商的應用往往是“讀多寫少”，採用讀寫分離就實現了更高的並發訪問。原本所有的讀寫壓力都由一台伺服器承擔，現在有多個伺服器共同處理讀取請求，減少了對主函式庫的壓力。另外還可以對從伺服器進行負載平衡，讓不同的讀取請求依照策略均勻的分配到不同的從伺服器中，讓讀取更加順暢。讀取順暢的另一個原因，就是減少了鎖表的影響，例如我們讓主庫負責寫，當主庫出現寫鎖的時候，不會影響到從庫的查詢操作。

3.2 資料備份

主從同步也相當於是一種資料熱備份機制，在主庫正常運作下進行備份，不影響提供資料服務。

3.3 高可用性

資料備份實際上是一種冗餘的機制，透過這種冗餘的方式可以換取資料庫的高可用性，當伺服器發生故障、當機等無可用的情況下，可以快速進行故障切換，讓從庫充當主庫，保障服務正常運作。大家可以了解下電商系統資料庫高可用SLA指標。

4 主從同步的原則

說到主從同步的原理，我們就需要了解在資料庫中的一個重要日誌文件，就是Binlog二進位文件，它記錄了對資料庫進行更新的事件，事實上主從同步的原理就是基於Binlog進行資料同步的。

在主從複製的過程中，會基於三個線程來操作，一個是binlog dump線程，位於master節點上，另外兩個線程分別是I/O線程和SQL線程，它們都分別位於slave節點上，如下圖：

結合以上圖片，我們一起來了解主從複製的核心流程：

• 當master節點接收到一個寫請求時，這個寫請求可能是增刪改操作，此時會把寫請求的更新操作都記錄到binlog日誌中。

• master節點會把資料複製給slave節點，如圖中的slave01節點和slave02節點，這個過程，首先得要每個slave節點連接到master節點上，當slave當節點連接到master節點上時，master節點會為每個slave節點分別建立一個binlog dump線程，用於向各個slave節點發送binlog日誌。

• binlog dump執行緒會讀取master節點上的binlog日誌，然後將binlog日誌傳送給slave節點上的I/O執行緒。當主庫讀取事件的時候，會在Binglog上加鎖，讀取完成之後，再將鎖釋放掉。

• slave節點上的I/O執行緒接收到binlog日誌後，會將binlog日誌先寫入本地的relaylog中，relaylog中就保存了binlog日誌。

• slave節點上的SQL線程，會來讀取relaylog中的binlog日誌，將其解析成具體的增刪改操作，把這些在master節點上進行過的操作，重新在slave節點上也重做一遍，達到資料還原的效果，這樣就可以保證master節點和slave節點的資料一致性了。

主從同步的資料內容其實是二進位日誌（Binlog），它雖然叫二進位日誌，實際上儲存的是一個又一個的事件（Event），這些事件分別對應著資料庫的更新操作，例如INSERT、UPDATE、DELETE等。

另外我們還要注意的是，不是所有版本的MySQL都預設開啟了伺服器的二進位日誌，在進行主從同步的時候，我們需要先檢查伺服器是否已經開啟了二進位日誌。

二進位日誌，它是一個文件，在進行網路傳輸的過程中就一定會存在一些延遲，例如200ms，這樣就可能造成用戶在從庫上讀取的數據不是最新的數據，也就會造成主從同步中的資料不一致的情況發生。例如我們對一筆記錄進行更新，這個操作是在主庫上完成的，而在很短的時間內，比如100ms，又對同一個記錄進行讀取，這時候從庫還沒有完成數據的同步，那麼，我們透過從庫讀取到的資料就是一條舊的資料。這種情況該怎麼辦呢？

5 如何解決主從同步的資料一致性問題

可以想像下，如果我們想要操作的資料都儲存在同一個資料庫中，那麼對資料進行更新的時候，可以對記錄進行加寫鎖，這樣在讀取的時候就不會發生資料不一致的情況了。但這時從函式庫的作用就是備份數據，沒有做到讀寫分離，分擔主庫的壓力。

因此我們還需要想辦法，在進行讀寫分離的時候，解決主從同步中資料不一致的問題，也就是解決主從之間資料複製方式的問題，如果按照資料一致性從弱到強來進行劃分，有以下三種複製方式。

5.1 全同步複製

首先，全同步複製，就是當主庫執行完一個事務之後，要求所有的從庫也都必須執行完該事務，才可以返回處理結果給客戶端；因此，雖然全同步複製資料一致性得到保證了，但是主庫完成一個事物需要等待所有從庫也完成，性能就比較低了。如下圖：

5.2 非同步複製

而非同步複製，就是當主函式庫提交事物後，會通知binlog dump執行緒發送binlog日誌給從函式庫，一旦binlog dump執行緒將binlog日誌傳送給從函式庫之後，不需要等到從函式庫也同步完成事務，主函式庫就會將處理結果傳回給客戶端。

因為主函式庫只管自己執行完事務，就可以將處理結果傳回給客戶端，而不用關心從函式庫是否執行完事務，這就可能導致短暫的主從資料不一致的問題了，例如剛在主庫插入的新數據，如果馬上在從庫查詢，就可能查詢不到。

而且，當主庫提交事物後，如果宕機掛掉了，此時可能binlog還沒來得及同步給從庫，這時候如果為了恢復故障切換主從節點的話，就會出現數據丟失的問題，所以異步複製雖然效能高，但資料一致性上是最弱的。

mysql主從複製，預設採用的就是非同步複製這種複製策略。

5.3 半同步複製

MySQL5.5版本之後開始支援半同步複製的方式。原理是在客戶端提交COMMIT之後不直接將結果傳回給客戶端，而是等待至少有一個從庫收到了Binlog，並且寫入到中繼日誌中，再傳回給客戶端。這樣做的好處就是提高了資料的一致性，當然相較於非同步複製來說，至少多增加了一個網路連線的延遲，降低了主庫寫的效率。

在MySQL5.7版本中也增加了一個rpl_semi_sync_master_wait_for_slave_count參數，我們可以對需要回應的從函式庫數量進行設置，預設為1，也就是說只要有一個從函式庫進行了回應，就可以傳回給客戶端。如果將這個參數調大，可以提升資料一致性的強度，但也會增加主庫等待從庫回應的時間。

但是，半同步複製也存在以下幾個問題：

• 半同步複製的效能，相較於非同步複製而言有所下降，相較於非同步複製是不需要等待任何從庫是否接收到資料的回應，而半同步複製則需要等待至少一個從庫確認接收到binlog日誌的回應，效能上是損耗較大的。
• 主庫等待從庫回應的最大時長是可以配置的，如果超過了配置的時間，半同步複製就會變成異步複製，那麼，異步複製的問題同樣也就會出現了。
• 在MySQL 5.7.2之前的版本中，半同步複製存在著幻讀問題的。

當主庫成功提交事物並處於等待從庫確認的過程中，這個時候，從庫都還來不及返回處理結果給客戶端，但因為主庫存儲引擎內部已經提交事務了，所以，其他客戶端是可以到從主庫讀到資料的。

但是，如果下一秒主庫突然掛了，此時正好下一次請求過來，因為主庫掛了，就只能把請求切換到從庫中，因為從庫還沒從主庫同步完數據，所以，從庫中當然就讀不到這條數據了，和上一秒讀取數據的結果對比，就造成了幻讀的現象了。

5.4 增強半同步複製

增強半同步複製，是mysql 5.7.2後的版本對半同步複製做的一個改進，原理上幾乎是一樣的，主要是解決幻讀的問題。

主庫配置了參數rpl_semi_sync_master_wait_point = AFTER_SYNC 後，主庫在儲存引擎提交事務前，必須先收到從庫資料同步完成的確認資訊後，才能提交事務，以此來解決幻讀問題。參考下圖：

6 總結

透過上述內容，我們了解了Mysql資料庫的主從同步，如果你的目標僅是資料庫的高並發，那麼可以先從SQL 優化，索引以及Redis 快取資料等這些方面來考慮最佳化，然後再考慮是否採用主從架構的方式。

在主從架構的配置中，如果想要採取讀寫分離的策略，我們可以自己編寫程序，也可以透過第三方的中間件來實現。

自己寫程式的好處就在於比較自主，我們可以自己判斷哪些查詢在從函式庫上來執行，針對即時性要求高的需求，我們還可以考慮哪些查詢可以在主函式庫上執行。同時程式直接連接資料庫，減少了中間件層，可以減少一些效能損耗。

而採用中間件的方法有很明顯的優勢，功能強大，使用簡單。但因為在客戶端和資料庫之間增加了中間件層會有一些效能損耗，同時商業中間件價格較高，所以有一定學習成本。另外，我們也可以考慮採用一些優秀的開源工具，像是 MaxScale。它是 MariaDB 開發的 MySQL 資料中間件。例如在下圖中，使用 MaxScale作為資料庫的代理，透過路由轉送完成了讀寫分離。同時我們也可以使用 MHA 工具作為強一致的主從切換工具，從而完成 MySQL的高可用架構。

推薦學習：《MySQL影片教學》

以上是一文徹底搞懂MySql主從同步的詳細內容。更多資訊請關注PHP中文網其他相關文章！