MySQL(13)---MYSQL主從複製原理

MYSQL主從複製原理

最近在做項目的時候,因爲部署了 MYSQL主從複製 所以在這裏記錄下整個過程。這裏一共會分兩篇博客來寫:

1、Mysql主從複製原理
2、docker部署Mysql主從複製實戰

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

一、概述

1、什麼是主從複製?

概念 主從複製是用來建立一個和 主數據庫完全一樣的數據庫環境稱爲從數據庫;主數據庫一般是準實時的業務數據庫。

2、主從複製作用

我們來思考如果在企業網站中,後端MYSQL數據庫只有一臺時候,會有以下問題

1、單點故障服務不可用
2、無法處理大量的併發數據請求
3、數據丟失

所以通過主從複製後,它的優點就很明顯

1、如果主節點出現故障,那麼我們就直接將服務切到從節點,來保證服務立馬可用。
2、如果併發請求特別大的時候,我們可用進行讀寫分離操作,讓主庫負責寫,從庫負責讀。
3、如果主庫數據丟失,但從庫還保存一份,減少數據丟失的風險。

二、主從複製原理

1、主從複製原理

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

上面主要分成了三步,下面會詳細說明。

(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線程。

2、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設置的超時時長,半同步

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


三、Mysql主從同步延時

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

串行執行 SQL 的特點,所以從庫的數據一定會比主庫慢一些,是有延時的。所以經常出現,剛寫入主庫的數據可能是讀不到的,要過幾十毫秒,甚至幾百毫秒才能

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

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

通過監控 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: 數字越大表示從庫延遲越嚴重。

2、影響延遲因素

這裏整理了影響主從複製延遲大致有以下幾個原因:

1)主節點如果執行一個很大的事務,那麼就會對主從延遲產生較大的影響

2)網絡延遲,日誌較大,slave數量過多

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

4)機器性能問題,從節點是否使用了“爛機器”

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

3、優化主從複製延遲

這個沒有說去完全解決,要想解決那麼就只能採用同步複製策略。不過,一般不建議使用這種同步模式。顯而易見,如果寫操作必須等待更新同步完成,肯定會

極大地影響性能,除非你不在乎性能。

1)大事務:將大事務分爲小事務,分批更新數據

2)減少Slave的數量,不要超過5個,減少單次事務的大小

3)MySQL 5.7之後,可以使用多線程複製,使用MGR複製架構

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

5)針對鎖問題可以通過抓去processlist以及查看information_schema下面和鎖以及事務相關的表來查看

總結

主機與從機之間的物理延遲是無法避免的,既然無法避免就可以考慮嘗試通過緩存等方式,降低新修改數據被立即讀取的概率。


參考

1、Mysql主從延時

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

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



別人罵我胖,我會生氣,因爲我心裏承認了我胖。別人說我矮,我就會覺得好笑,因爲我心裏知道我不可能矮。這就是我們爲什麼會對別人的攻擊生氣。
攻我盾者,乃我內心之矛(32)
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章