揭秘MySQL的主從同步實現方案

ITPUB社群 發表於 2022-12-01
MySQL

關於MySQL主從複製主要同步的是binlog日誌,涉及到三個執行緒,一個執行在主節點(log dump thread),其餘兩個(I/O thread, SQL thread)執行在從節點,如下圖所示:

揭秘MySQL的主從同步實現方案


1、如何實現主從一致
(1)主節點 binary log dump 執行緒

當從節點連線主節點時,主節點會建立一個log dump 執行緒,用於傳送binlog的內容。在讀取binlog中的操作時,此執行緒會對主節點上的binlog加鎖,當讀取完成,在傳送給從節點之前,鎖會被釋放。


(2)從節點I/O執行緒

當從節點上執行`start slave`命令之後,從節點會建立一個I/O執行緒用來連線主節點,請求主庫中更新的binlog。I/O執行緒接收到主節點binlog dump 程式發來的更新之後,儲存在本地relay-log(中繼日誌)中。


(3)從節點SQL執行緒

SQL執行緒負責讀取relay log中的內容,解析成具體的操作並執行,最終保證主從資料的一致性。


2、一主多從同步?

       對於每一個主從連線,都需要三個程式來完成。當主節點有多個從節點時,主節點會為每一個當前連線的從節點建一個binlog dump 程式,而每個從節點都有自己的I/O程式,SQL程式。


從節點用兩個執行緒將從主庫拉取更新和執行分成獨立的任務,這樣在執行同步資料任務的時候,不會降低讀操作的效能。比如,如果從節點沒有執行,此時I/O程式可以很快從主節點獲取更新,儘管SQL程式還沒有執行。


如果在SQL程式執行之前從節點服務停止,至少I/O程式已經從主節點拉取到了最新的變更並且儲存在本地relay日誌中,當服務再次起來之後,就可以完成資料的同步。

揭秘MySQL的主從同步實現方案


3、主從複製的基本過程

(1)從節點上的I/O 程式連線主節點,並請求從指定日誌檔案的指定位置(或者從最開始的日誌)之後的日誌內容;


(2)主節點接收到來自從節點的I/O請求後,透過負責複製的I/O程式根據請求資訊讀取指定日誌指定位置之後的日誌資訊,返回給從節點。返回資訊中除了日誌所包含的資訊之外,還包括本次返回的資訊的binlog file 的以及binlog position;


(3)從節點的I/O程式接收到內容後,將接收到的日誌內容更新到本機的relay log中,並將讀取到的binlog檔名和位置儲存到master-info 檔案中,以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個binlog 的哪個位置開始往後的日誌內容,請發給我”;


(4)Slave 的 SQL執行緒檢測到relay-log 中新增加了內容後,會將relay-log的內容解析成在主節點上實際執行過的操作,並在本資料庫中執行。


4、MySQL 主從複製模式

MySQL 主從複製預設是非同步的模式。MySQL增刪改操作會全部記錄在binlog中,當slave節點連線master時,會主動從master處獲取最新的bin log檔案。並把bin log中的sql relay。

(1)非同步模式(mysql async-mode)

原理:客戶端提交 COMMIT 之後主庫,不需要等從庫返回任何結果,而是直接將結果返回給客戶端,這樣做的好處是不會影響主庫寫的效率,但可能會存在主庫當機(就涼了),而 Binlog 還沒有同步到從庫的情況,也就是此時的主庫和從庫資料不一致。


這時候從從庫中選擇一個作為新主,那麼新主則可能缺少原來主伺服器中已提交的事務。所以,這種複製模式下的資料一致性是最弱的。

揭秘MySQL的主從同步實現方案


(2)半同步模式(mysql semi-sync)

原理:在客戶端提交 COMMIT 之後不直接將結果返回給客戶端,而是等待至少有一個從庫接收到了 Binlog,並且寫入到中繼日誌中,再返回給客戶端。


這樣做的好處就是提高了資料的一致性,當然相比於非同步複製來說,至少多增加了一個網路連線的延遲,降低了主庫寫的效率。MySql5.7支援設定應答從庫的個數,保證N個從庫同步完成後進行返回。

揭秘MySQL的主從同步實現方案


半同步模式不是mysql內建的,從mysql 5.5開始整合,需要master 和slave 安裝外掛開啟半同步模式。

(3)全同步模式

全同步模式是指主節點和從節點全部執行了commit並確認才會向客戶端返回成功。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2926166/,如需轉載,請註明出處,否則將追究法律責任。