乾貨分享；MySQL主從同步那點事兒

1、前言

關於mysql主從同步，相信你們都不陌生，隨着系統應用訪問量逐漸增大，單臺數據庫讀寫訪問壓力也隨之增大，當讀寫訪問達到必定瓶頸時，將數據庫的讀寫效率驟然降低，甚至不可用；爲了解決此類問題，一般會採用mysql集羣，當主庫宕機後，集羣會自動將一個從庫升級爲主庫，繼續對外提供服務；那麼主庫和從庫之間的數據是如何同步的呢？本文針對MySQL 5.7版本進行下面的分析，下面隨筆者一塊兒探究一下mysql主從是如何同步的。

 

2、MySQL主從複製原理

爲了減輕主庫的壓力，應該在系統應用層面作讀寫分離，寫操做走主庫，讀操做走從庫，下圖爲MySQL官網給出的主從複製的原理圖，從圖中能夠簡單的瞭解讀寫分離及主從同步的過程，分散了數據庫的訪問壓力，提高整個系統的性能和可用性，下降了大訪問量引起數據庫宕機的故障率。

 

乾貨分享；MySQL主從同步那點事兒

 

3、binlog簡介

MySQL主從同步是基於binlog文件主從複製實現，爲了更好的理解主從同步過程，這裏簡單介紹一下binlog日誌文件。

 

binlog日誌用於記錄全部更新了數據或者已經潛在更新了數據（例如，沒有匹配任何行的一個DELETE）的全部語句。語句以「事件」的形式保存，它描述數據更改，它是以二進制的形式保存在磁盤中。咱們能夠經過mysql提供的查看工具mysqlbinlog查看文件中的內容，例如 mysqlbinlog mysql-bin.00001 | more，這裏注意一下binlog文件的後綴名00001，binlog文件大小和個數會不斷的增長，當MySQL中止或重啓時，會產生一個新的binlog文件，後綴名會按序號遞增，例如mysql-bin.0000二、mysql-bin.00003，而且當binlog文件大小超過 max_binlog_size系統變量配置時也會產生新的binlog文件。（一）binlog日誌格式

 

（1） statement ： 記錄每一條更改數據的sql;

 

優勢：binlog文件較小，節約I/O，性能較高。

缺點：不是全部的數據更改都會寫入binlog文件中，尤爲是使用MySQL中的一些特殊函數（如LOAD_FILE()、UUID()等）和一些不肯定的語句操做，從而致使主從數據沒法複製的問題。

（2） row ： 不記錄sql，只記錄每行數據的更改細節

 

優勢：詳細的記錄了每一行數據的更改細節，這也意味着不會因爲使用一些特殊函數或其餘狀況致使不能複製的問題。

缺點：因爲row格式記錄了每一行數據的更改細節，會產生大量的binlog日誌內容，性能不佳，而且會增大主從同步延遲出現的概率。

（3） mixed：通常的語句修改使用statment格式保存binlog，如一些函數，statement沒法完成主從複製的操做，則採用row格式保存binlog，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。

 

（二）binlog日誌內容

好好mysql binlog命令查看的內容以下：

 

 

根據事件類型查看的binlog內容：

 

乾貨分享；MySQL主從同步那點事兒

 

（三）binlog事件類型

 

MySQL binlog記錄的全部操做實際上都有對應的事件類型的，譬如STATEMENT格式中的DML操做對應的是QUERY_EVENT類型，ROW格式下的DML操做對應的是ROWS_EVENT類型，若是想了解更多請參考官方文檔，有關binlog日誌內容不在這裏過多贅述，簡單介紹一下是爲了更好的理解主從複製的細節，下面咱們進入正題。

 

4、MySQL主從複製原理

mysql主從複製須要三個線程，master（binlog dump thread）、slave（I/O thread 、SQL thread）。

 

master

 

（1）binlog dump線程：當主庫中有數據更新時，那麼主庫就會根據按照設置的binlog格式，將這次更新的事件類型寫入到主庫的binlog文件中，此時主庫會建立log dump線程通知slave有數據更新，當I/O線程請求日誌內容時，會將此時的binlog名稱和當前更新的位置同時傳給slave的I/O線程。

 

slave

 

（2）I/O線程：該線程會鏈接到master，向log dump線程請求一份指定binlog文件位置的副本，並將請求回來的binlog存到本地的relay log中，relay log和binlog日誌同樣也是記錄了數據更新的事件，它也是按照遞增後綴名的方式，產生多個relay log（ host_name-relay-bin.000001）文件，slave會使用一個index文件（ host_name-relay-bin.index）來追蹤當前正在使用的relay log文件。

 

（3）SQL線程：該線程檢測到relay log有更新後，會讀取並在本地作redo操做，將發生在主庫的事件在本地從新執行一遍，來保證主從數據同步。此外，若是一個relay log文件中的所有事件都執行完畢，那麼SQL線程會自動將該relay log 文件刪除掉。

 

下面是整個複製過程的原理圖：

 

—4、主從同步延遲

mysql的主從複製都是單線程的操做，主庫對全部DDL和DML產生binlog，binlog是順序寫，因此效率很高，slave的I/O線程到主庫取日誌，效率也比較高，可是，slave的SQL線程將主庫的DDL和DML操做在slave實施。DML和DDL的IO操做是隨即的，不是順序的，成本高不少，還可能存在slave上的其餘查詢產生lock爭用的狀況，因爲SQL也是單線程的，因此一個DDL卡住了，須要執行很長一段事件，後續的DDL線程會等待這個DDL執行完畢以後才執行，這就致使了延時。當主庫的TPS併發較高時，產生的DDL數量超過slave一個sql線程所能承受的範圍，延時就產生了，除此以外，還有可能與slave的大型query語句產生了鎖等待致使。

 

因爲主從同步延遲是客觀存在的，咱們只能從咱們本身的架構上進行設計， 儘可能讓主庫的DDL快速執行。下面列出幾種常見的解決方案：

 

1業務的持久化層的實現採用分庫架構，mysql服務可平行擴展，分散壓力。

服務的基礎架構在業務和mysql之間加入memcache或者Redis的cache層。下降mysql的讀壓力；

使用比主庫更好的硬件設備做爲slave；

sync_binlog在slave端設置爲0；

–logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日誌。

禁用slave的binlog