MySQL（13）---MYSQL主從複製原理

MYSQL主從複製原理

最近在作項目的時候，由於部署了 MYSQL主從複製 因此在這裏記錄下整個過程。這裏一共會分兩篇博客來寫:

一、Mysql主從複製原理
二、docker部署Mysql主從複製實戰

這篇只寫MYSQL主從複製原理。

1、概述

一、什麼是主從複製?

概念 主從複製是用來創建一個和 主數據庫徹底同樣的數據庫環境稱爲從數據庫；主數據庫通常是準實時的業務數據庫。

二、主從複製做用

咱們來思考若是在企業網站中，後端MYSQL數據庫只有一臺時候，會有如下問題

一、單點故障服務不可用
二、沒法處理大量的併發數據請求
三、數據丟失

因此經過主從複製後，它的優勢就很明顯

一、若是主節點出現故障，那麼咱們就直接將服務切到從節點，來保證服務立馬可用。
二、若是併發請求特別大的時候，咱們可用進行讀寫分離操做，讓主庫負責寫，從庫負責讀。
三、若是主庫數據丟失，但從庫還保存一份，減小數據丟失的風險。

2、主從複製原理

一、主從複製原理

這裏先放一張圖，這張圖很好的詮釋的主從複製的原理

上面主要分紅了三步，下面會詳細說明。

(1) Master的更新事件(update、insert、delete)會按照順序寫入bin-log中。當Slave鏈接到Master的後,Master機器會爲Slave開啓

binlog dump線程,該線程會去讀取bin-log日誌

(2) Slave鏈接到Master後,Slave庫有一個I/O線程 經過請求binlog dump thread讀取bin-log日誌,而後寫入從庫的relay log日誌中。

(3) Slave還有一個 SQL線程,實時監控 relay-log日誌內容是否有更新,解析文件中的SQL語句,在Slave數據庫中去執行。

總結

(1) 既然是要把事件記錄到bin-log日誌，那麼對於Master就必須開啓bin-log功能。

(2) 整個Mysql主從複製一共開啓了3個線程。Master開啓 IO線程，Slave開啓 IO線程 和 SQL線程。

(3) 這點也很重要那就是Master和Slave交互的時候，記住這裏是Slave去請求Master,而不是Master主動推給Slave。Slave經過IO線程

鏈接Master後發起請求,Master服務器收到Slave IO線程發來的日誌請求信息，io線程去將bin-log內容返回給slave IO線程。

二、MySQL主從複製同步方式

(1)異步複製

MySQL主從同步 默認是異步複製的。就是上面三步中,只有第一步是同步的(也就是Mater寫入bin log日誌),就是主庫寫入binlog日誌後便可成功返回客戶端，無須等待binlog

日誌傳遞給從庫的過程。Master 不關心 Slave 的數據有沒有寫入成功。所以若是Master和Slave之間有網絡延遲，就會形成暫時的數據不一致的現象；若是Master出故障，而數據

尚未複製過去，則會形成數據丟失；但也有好處，效率較其餘兩種複製方式最高。

（2)同步複製

對於同步複製而言，Master主機將事件發送給Slave主機後會觸發一個等待，直到全部Slave節點（若是有多個Slave）返回數據複製成功的信息給Master。這種複製方式最安

全，可是同時，效率也是最差的。

（3)半同步複製

對於半同步複製而言，Master主機將事件發送給Slave主機後會觸發一個等待，直到其中一個Slave節點（若是有多個Slave）返回數據複製成功的信息給Master。由此加強了

數據的一致性，可是由於Master主機的確認開銷，會損耗一部分的性能；另外，半同步複製除了不須要等待全部Slave主機確認事件的接收外，半同步數據複製並不要求那些事件

徹底地執行，所以，仍有可能看到在Slave主機上數據複製延遲的發生，若是由於網絡延遲等緣由形成Slave遲遲沒有返回複製成功的信息，超過了Master設置的超時時長，半同步

複製就降級爲異步複製方式，然後繼續數據複製。

3、Mysql主從同步延時

上面也說了，Mysql默認採用的異步操做，由於它的效率明顯是最高的。由於只要寫入bin log後事物就結束返回成功了。但因爲從庫從主庫異步拷貝日誌 以及

串行執行 SQL 的特色，因此從庫的數據必定會比主庫慢一些，是有延時的。因此常常出現，剛寫入主庫的數據多是讀不到的，要過幾十毫秒，甚至幾百毫秒才能

讀取到。這就是主從同步延時問題。

一、如何查看主從延遲時間

經過監控 show slave status 命令輸出的Seconds_Behind_Master參數的值來判斷：

mysql> show slave status\G;
    // 狀態一
    Seconds_Behind_Master: NULL
    // 狀態二
    Seconds_Behind_Master: 0
    // 狀態三
    Seconds_Behind_Master: 79

Seconds_Behind_Master=0: 表示主從複製良好；

Seconds_Behind_Master=NULL: 表示io_thread或是sql_thread有任何一個發生故障；

Seconds_Behind_Master=79: 數字越大表示從庫延遲越嚴重。

二、影響延遲因素

這裏整理了影響主從複製延遲大體有如下幾個緣由：

1）主節點若是執行一個很大的事務，那麼就會對主從延遲產生較大的影響

2）網絡延遲，日誌較大，slave數量過多

3）主上多線程寫入，從節點只有單線程同步

4）機器性能問題，從節點是否使用了「爛機器」

5）鎖衝突問題也可能致使從機的SQL線程執行慢

三、優化主從複製延遲

這個沒有說去徹底解決，要想解決那麼就只能採用同步複製策略。不過，通常不建議使用這種同步模式。顯而易見，若是寫操做必須等待更新同步完成，確定會

極大地影響性能，除非你不在意性能。

1）大事務：將大事務分爲小事務，分批更新數據

2）減小Slave的數量，不要超過5個，減小單次事務的大小

3）MySQL 5.7以後，可使用多線程複製，使用MGR複製架構

4）在磁盤、raid卡、調度策略有問題的狀況下可能會出現單個IO延遲很高的狀況，可用iostat命令查看DB數據盤的IO狀況，再進一步判斷

5）針對鎖問題能夠經過抓去processlist以及查看information_schema下面和鎖以及事務相關的表來查看

總結

主機與從機之間的物理延遲是沒法避免的，既然沒法避免就能夠考慮嘗試經過緩存等方式，下降新修改數據被當即讀取的機率。

參考

一、Mysql主從延時

二、你知道MySQL主從複製的原理嗎

三、MySQL主從同步機制和同步延時問題追查

別人罵我胖，我會生氣，由於我內心認可了我胖。別人說我矮，我就會以爲可笑，由於我內心知道我不可能矮。這就是咱們爲何會對別人的攻擊生氣。
攻我盾者，乃我心裏之矛(32)