一、前言

關于mysql主從同步，相信大家都不陌生，隨著系統應用訪問量逐漸增大，單臺數據庫讀寫訪問壓力也隨之增大，當讀寫訪問達到一定瓶頸時，將數據庫的讀寫效率驟然下降，甚至不可用;為了解決此類問題，通常會采用mysql集群，當主庫宕機后，集群會自動將一個從庫升級為主庫，繼續對外提供服務;那么主庫和從庫之間的數據是如何同步的呢?本文針對MySQL 5.7版本進行下面的分析，下面隨筆者一起探究一下mysql主從是如何同步的。

二、MySQL主從復制原理

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

三、binlog簡介

MySQL主從同步是基于binlog文件主從復制實現，為了更好的理解主從同步過程，這里簡單介紹一下binlog日志文件。

binlog日志用于記錄所有更新了數據或者已經潛在更新了數據(例如，沒有匹配任何行的一個DELETE)的所有語句。語句以“事件”的形式保存，它描述數據更改，它是以二進制的形式保存在磁盤中。我們可以通過mysql提供的查看工具mysqlbinlog查看文件中的內容，例如 mysqlbinlog mysql-bin.00001 | more，這里注意一下binlog文件的后綴名00001，binlog文件大小和個數會不斷的增加，當MySQL停止或重啟時，會產生一個新的binlog文件，后綴名會按序號遞增，例如mysql-bin.00002、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日志內容

mysqlbinlog命令查看的內容如下：

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

(三)binlog事件類型

MySQL binlog記錄的所有操作實際上都有對應的事件類型的，譬如STATEMENT格式中的DML操作對應的是QUERY_EVENT類型，ROW格式下的DML操作對應的是ROWS_EVENT類型，如果想了解更多請參考官方文檔，有關binlog日志內容不在這里過多贅述，簡單介紹一下是為了更好的理解主從復制的細節，下面我們進入正題。

四、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 文件刪除掉。

下面是整個復制過程的原理圖：

四、主從同步延遲

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服務可平行擴展，分散壓力。
2. 服務的基礎架構在業務和mysql之間加入memcache或者Redis的cache層。降低mysql的讀壓力;
3. 使用比主庫更好的硬件設備作為slave;
4. sync_binlog在slave端設置為0;
5. –logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日志。
6. 禁用slave的binlog