MySql主從同步介紹

語言: CN / TW / HK

1 引言

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

2 MySql主從同步概述

MySQL主從同步,即MySQL Replication,可以實現將資料從一臺資料庫伺服器同步到多臺資料庫伺服器。MySQL資料庫自帶主從同步功能,經過配置,可以實現基於庫、表結構的多種方案的主從同步。

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

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

上圖中,可以看到,我們增加了2個從庫,這2個從庫可以一起抗下大量的讀請求,分擔主庫壓力。從庫會通過主從複製,從主庫中不斷的同步資料,以此來保證從庫的資料和主庫資料的一致。

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

3 主從同步的作用

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

言歸正傳,主從同步不僅可以提升資料庫的吞吐量,還有以下三個方面的作用:

3.1 讀寫分離

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

3.2 資料備份

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

3.3 高可用性

資料備份實際就是一種冗餘的機制,通過這種冗餘的方式可以換取資料庫的高可用性,當伺服器出現故障、宕機等無可用的情況下,可以迅速進行故障切換,讓從庫充當主庫,保障服務正常執行。大家可以瞭解下電商系統資料庫高可用SLA指標。

4 主從同步的原理

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

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

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

  1. 當master節點接收到一個寫請求時,這個寫請求可能是增刪改操作,此時會把寫請求的更新操作都記錄到binlog日誌中。
  2. master節點會把資料複製給slave節點,如圖中的slave01節點和slave02節點,這個過程,首先得要每個slave節點連線到master節點上,當slave節點連線到master節點上時,master節點會為每一個slave節點分別建立一個binlog dump執行緒,用於向各個slave節點發送binlog日誌。
  3. binlog dump執行緒會讀取master節點上的binlog日誌,然後將binlog日誌傳送給slave節點上的I/O執行緒。當主庫讀取事件的時候,會在Binglog上加鎖,讀取完成之後,再將鎖釋放掉。
  4. slave節點上的I/O執行緒接收到binlog日誌後,會將binlog日誌先寫入到本地的relaylog中,relaylog中就儲存了binlog日誌。
  5. 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的高可用架構。


 

作者:劉鄧忠