MySQL實現主從復制的原理詳解

主從復制是怎么實現的呢?

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

這里面涉及到三個線程:

IO線程

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

log dump線程

master 節點上有一個 log dump 線程，是用來發送 binlog 給 slave 的。

sql線程

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

主從復制的方式

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

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

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

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

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

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

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

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

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

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

讀寫分離

做了主從復制的方案之后，我們只把數據寫入 master 節點，而讀的請求可以分擔到slave 節點, 這種方案我們稱之為讀寫分離。

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

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

常見的分庫分表策略

把一個數據庫按照業務拆分成不同的數據庫：

把單張表的數據按照一定的規則分布到多個數據庫。

到此這篇關于MySQL實現主從復制的原理詳解的文章就介紹到這了,更多相關MySQL 主從復制內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！