# 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主從延時](https://www.jianshu.com/p/55e110bc40cf) 2、[你知道MySQL主從複製的原理嗎](https://database.51cto.com/art/202004/614426.htm) 3、[MySQL主從同步機制和同步延時問題追查](https://segmentfault.com/a/1190000018153974)

``` 別人罵我胖，我會生氣，因為我心裡承認了我胖。別人說我矮，我就會覺得好笑，因為我心裡知道我不可能矮。這就是我們為什麼會對別人的攻擊生氣。 攻我盾者，乃我內心之矛(32) ```