MySQL實(shí)現(xiàn)主從復(fù)制的原理詳解

更新時(shí)間：2023年07月02日 16:18:45 作者：DannyIdea

這篇文章主要為大家介紹了MySQL的主從復(fù)制是怎么實(shí)現(xiàn)的，文中有相關(guān)的圖文介紹和代碼示例，具有一定的參考價(jià)值,感興趣的同學(xué)跟著小編一起來學(xué)習(xí)吧

當(dāng)MySQL數(shù)據(jù)庫發(fā)生寫操作的時(shí)候會(huì)記錄下binlog，它是一種邏輯日志。有了這個(gè) binlog，從服務(wù)器會(huì)獲取主服務(wù)器的 binlog 文件，然后解析里面的 SQL 語句，在從服務(wù)器上面執(zhí)行一遍，保持主從的數(shù)據(jù)一致。

這里面涉及到三個(gè)線程:

IO線程

連接到 master 獲取 binlog，并且解析 binlog 寫入中繼日志，這個(gè)線程叫做 I/O 線程。

log dump線程

master 節(jié)點(diǎn)上有一個(gè) log dump 線程，是用來發(fā)送 binlog 給 slave 的。

sql線程

從庫的 sql 線程，是用來讀取 relay log，把數(shù)據(jù)寫入到數(shù)據(jù)庫的。

主從復(fù)制的方式

異步復(fù)制

在異步復(fù)制中，主庫執(zhí)行完操作后，寫入binlog日志后，就返回客戶端，這一動(dòng)作就結(jié)束了，并不會(huì)驗(yàn)證從庫有沒有收到，完不完整，所以這樣可能會(huì)造成數(shù)據(jù)的不一致。

說到底，復(fù)制過程中數(shù)據(jù)是否一致，主要取決于Binlog日志的安全性與完整性

在MySQL中，有sync_binlog=n這一參數(shù)，他的值表示每進(jìn)行n次事務(wù)提交，MySQL就將Binlog刷新到磁盤。如果這個(gè)值為1，就代表每提交一次事務(wù)（SQL），就將Binlog往磁盤刷新一次，這樣一來，就算數(shù)據(jù)庫宕機(jī)了，那么最多只能損失一次事務(wù)的數(shù)據(jù)。

但是，一旦多個(gè)事務(wù)并發(fā)提交時(shí)，由于受sync_binlog的限制，MySQL只能按順序來處理這些請(qǐng)求，另外，高頻率的刷新binlog對(duì)IO的影響也很大，進(jìn)一步影響了數(shù)據(jù)庫的性能，所以，一般這個(gè)值都設(shè)為0或者其他值，在數(shù)據(jù)的安全性和高并發(fā)下的性能之間取得一個(gè)平衡。

為了更加有效的保護(hù)Binlog的安全性和完整性，MySQL5 .5之后引入了半同步復(fù)制

半同步復(fù)制

在異步復(fù)制中，我們遇到的一個(gè)主要問題就是，在復(fù)制過程當(dāng)中，主庫不會(huì)去驗(yàn)證Binlog有沒有成功復(fù)制到從庫，那如果主庫提交一個(gè)事務(wù)并寫入Binlog中后，當(dāng)從庫還沒有從主庫得到Binlog時(shí)，主庫宕機(jī)了或因磁盤損壞等故障導(dǎo)致該事務(wù)的Binlog丟失了，那從庫就不會(huì)得到這個(gè)事務(wù)，也就造成了主從數(shù)據(jù)的不一致。

而半同步復(fù)制，當(dāng)主庫每提交一個(gè)事務(wù)后，不會(huì)立即返回，而是等待其中一個(gè)從庫接收到Binlog并成功寫入Relay-log中才返回客戶端，所以這樣就保證了一個(gè)事務(wù)至少有兩份日志，一份保存在主庫的Binlog，另一份保存在其中一個(gè)從庫的Relay-log中，從而保證了數(shù)據(jù)的安全性和一致性。

另外，在半同步復(fù)制時(shí)，如果主庫的一個(gè)事務(wù)提交成功了，在推送到從庫的過程當(dāng)中，從庫宕機(jī)了或網(wǎng)絡(luò)故障，導(dǎo)致從庫并沒有接收到這個(gè)事務(wù)的Binlog，此時(shí)主庫會(huì)等待一段時(shí)間（這個(gè)時(shí)間由rpl_semi_sync_master_timeout的毫秒數(shù)決定），如果這個(gè)時(shí)間過后還無法推送到從庫，那MySQL會(huì)自動(dòng)從半同步復(fù)制切換為異步復(fù)制，當(dāng)從庫恢復(fù)正常連接到主庫后，主庫又會(huì)自動(dòng)切換回半同步復(fù)制。

半同步復(fù)制的“半”體現(xiàn)在，雖然主從庫的Binlog是同步的，但主庫不會(huì)等待從庫執(zhí)行完Relay-log后才返回，而是確認(rèn)從庫接收到Binlog，達(dá)到主從Binlog同步的目的后就返回了，所以從庫的數(shù)據(jù)對(duì)于主庫來說還是有延時(shí)的，這個(gè)延時(shí)就是從庫執(zhí)行Relay-log的時(shí)間。所以只能稱為半同步。

總之這兩種策略，可以濃縮理解為，一個(gè)是“不管不問”，一個(gè)是“確認(rèn)到位就跑”。

讀寫分離

做了主從復(fù)制的方案之后，我們只把數(shù)據(jù)寫入 master 節(jié)點(diǎn)，而讀的請(qǐng)求可以分擔(dān)到slave 節(jié)點(diǎn), 這種方案我們稱之為讀寫分離。

讀寫分離可以一定程度低減輕數(shù)據(jù)庫服務(wù)器的訪問壓力，但是需要特別注意主從數(shù)據(jù)一致性的問題。

我們?cè)谧隽酥鲝膹?fù)制之后，如果單個(gè) master 節(jié)點(diǎn)或者單張表存儲(chǔ)的數(shù)據(jù)過大的時(shí)候，比如一張表有上億的數(shù)據(jù)，單表的查詢性能還是會(huì)下降，我們要進(jìn)一步對(duì)單臺(tái)數(shù)據(jù)庫節(jié)點(diǎn)的數(shù)據(jù)進(jìn)行拆分，而這個(gè)拆分就是分庫分表。