快捷導(dǎo)航

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

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

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

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

這里面涉及到三個線程:

IO線程

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

log dump線程

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

sql線程

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

主從復(fù)制的方式

異步復(fù)制

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

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

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

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

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

半同步復(fù)制

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

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

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

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

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

讀寫分離

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

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

我們在做了主從復(fù)制之后，如果單個 master 節(jié)點或者單張表存儲的數(shù)據(jù)過大的時候，比如一張表有上億的數(shù)據(jù)，單表的查詢性能還是會下降，我們要進(jìn)一步對單臺數(shù)據(jù)庫節(jié)點的數(shù)據(jù)進(jìn)行拆分，而這個拆分就是分庫分表。