MySQL主從復(fù)制原理詳解

什么是主從復(fù)制

簡單講，MySQL主從復(fù)制就是數(shù)據(jù)寫入一臺服務(wù)器(主服務(wù)器)后，同時還會額外寫入另外的服務(wù)器(從服務(wù)器)。也就是說數(shù)據(jù)會寫多份，這樣做的目的主要有兩個：

1)備份數(shù)據(jù);

2)做負(fù)載均衡，對于寫來說沒有效果，但是對于讀是可以做到負(fù)載均衡的。

主從復(fù)制原理

1)主上將所有變更事件記錄到binlog里

2)從發(fā)起請求連接主

3)主的binlog備份線程將binlog傳給從

4)從的I/O線程將binlog解析成自己的relay log

5)從的SQL線程根據(jù)relay log來執(zhí)行具體的SQL語句

MySQL主從復(fù)制是一個異步的復(fù)制過程，主庫發(fā)送更新事件到從庫，從庫讀取更新記錄，并執(zhí)行更新記錄，使得從庫的內(nèi)容與主庫保持一致。

概念解釋

Binlog：binary log，主庫中保存所有更新事件日志的二進制文件。binlog是數(shù)據(jù)庫服務(wù)啟動的一刻起，保存數(shù)據(jù)庫所有變更記錄(數(shù)據(jù)庫結(jié)構(gòu)和內(nèi)容)的文件。在主庫中，只要有更新事件出現(xiàn)，就會被依次地寫入到binlog中，之后會推送到從庫中作為從庫進行復(fù)制的數(shù)據(jù)源。

Binlog dump線程：每當(dāng)有從庫連接到主庫的時候，主庫都會創(chuàng)建一個線程然后發(fā)送binlog內(nèi)容到從庫。對于每一個即將發(fā)送給從庫的sql事件，binlog dump線程會將其鎖住。一旦該事件被線程讀取完之后，該鎖會被釋放，即使在該事件完全發(fā)送到從庫的時候，該鎖也會被釋放。

在從庫中，當(dāng)復(fù)制開始時，從庫就會創(chuàng)建從庫I/O線程和從庫的SQL線程進行復(fù)制處理。

從庫I/O線程：當(dāng)START SLAVE語句在從庫開始執(zhí)行之后，從庫創(chuàng)建一個I/O線程，該線程連接到主庫并請求主庫發(fā)送binlog里面的更新記錄到從庫上。從庫I/O線程讀取主庫的binlog輸出線程發(fā)送的更新并拷貝這些更新到本地文件，其中包括relay log文件。

從庫的SQL線程：從庫創(chuàng)建一個SQL線程，這個線程讀取從庫I/O線程寫到relay log的更新事件并執(zhí)行。

基于GTID的主從復(fù)制

1)什么是GTID

GTID(Global Transaction ID)是對于一個已提交事務(wù)的編號，并且是一個全局唯一的編號。GTID實際上是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一標(biāo)識，保存在mysql數(shù)據(jù)目錄下的auto.cnf文件里。TID代表了該實例上已經(jīng)提交的事務(wù)數(shù)量，并且隨著事務(wù)提交單調(diào)遞增。下面是一個GTID的具體形式：3E11FA47-71CA-11E1-9E33-C80AA9429562:23

2)GTID的作用

根據(jù)GTID可以知道事務(wù)最初是在哪個實例上提交的，GTID的存在方便了Replication的Failover(故障切換)

3)GTID比傳統(tǒng)復(fù)制的優(yōu)勢

更簡單的實現(xiàn)failover，不用以前那樣在需要找log_file和log_Pos。更簡單的搭建主從復(fù)制。比傳統(tǒng)復(fù)制更加安全。GTID是連續(xù)沒有空洞的，因此主從庫出現(xiàn)數(shù)據(jù)沖突時，可以用添加空事物的方式進行跳過。

4)GTID的工作原理：

① master更新數(shù)據(jù)時，會在事務(wù)前產(chǎn)生GTID，一同記錄到binlog日志中。

② slave端的i/o線程將變更的binlog，寫入到本地的relay log中。

③ sql線程從relay log中獲取GTID，然后對比slave端的binlog是否有記錄。

④ 如果有記錄，說明該GTID的事務(wù)已經(jīng)執(zhí)行，slave會忽略。

⑤ 如果沒有記錄，slave就會從relay log中執(zhí)行該GTID的事務(wù)，并記錄到binlog。

⑥ 在解析過程中會判斷是否有主鍵，如果有就用二級索引，如果沒有就用全部掃描。

審核編輯：湯梓紅