MySQL主從同步那點(diǎn)事兒

作者：佚名 2017-09-12 08:03:29

關(guān)于mysql主從同步，相信大家都不陌生，隨著系統(tǒng)應(yīng)用訪問量逐漸增大，單臺數(shù)據(jù)庫讀寫訪問壓力也隨之增大，當(dāng)讀寫訪問達(dá)到一定瓶頸時(shí)，將數(shù)據(jù)庫的讀寫效率驟然下降，甚至不可用;為了解決此類問題，通常會采用mysql集群，當(dāng)主庫宕機(jī)后，集群會自動將一個(gè)從庫升級為主庫，繼續(xù)對外提供服務(wù);那么主庫和從庫之間的數(shù)據(jù)是如何同步的呢?

一、前言

二、MySQL主從復(fù)制原理

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

三、binlog簡介

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

binlog日志用于記錄所有更新了數(shù)據(jù)或者已經(jīng)潛在更新了數(shù)據(jù)(例如，沒有匹配任何行的一個(gè)DELETE)的所有語句。語句以“事件”的形式保存，它描述數(shù)據(jù)更改，它是以二進(jìn)制的形式保存在磁盤中。我們可以通過mysql提供的查看工具mysqlbinlog查看文件中的內(nèi)容，例如 mysqlbinlog mysql-bin.00001 | more，這里注意一下binlog文件的后綴名00001，binlog文件大小和個(gè)數(shù)會不斷的增加，當(dāng)MySQL停止或重啟時(shí)，會產(chǎn)生一個(gè)新的binlog文件，后綴名會按序號遞增，例如mysql-bin.00002、mysql-bin.00003，并且當(dāng)binlog文件大小超過 max_binlog_size系統(tǒng)變量配置時(shí)也會產(chǎn)生新的binlog文件。

(一)binlog日志格式

(1) statement ：記錄每一條更改數(shù)據(jù)的sql;

優(yōu)點(diǎn)：binlog文件較小，節(jié)約I/O，性能較高。
缺點(diǎn)：不是所有的數(shù)據(jù)更改都會寫入binlog文件中，尤其是使用MySQL中的一些特殊函數(shù)(如LOAD_FILE()、UUID()等)和一些不確定的語句操作，從而導(dǎo)致主從數(shù)據(jù)無法復(fù)制的問題。

(2) row ：不記錄sql，只記錄每行數(shù)據(jù)的更改細(xì)節(jié)

優(yōu)點(diǎn)：詳細(xì)的記錄了每一行數(shù)據(jù)的更改細(xì)節(jié)，這也意味著不會由于使用一些特殊函數(shù)或其他情況導(dǎo)致不能復(fù)制的問題。
缺點(diǎn)：由于row格式記錄了每一行數(shù)據(jù)的更改細(xì)節(jié)，會產(chǎn)生大量的binlog日志內(nèi)容，性能不佳，并且會增大主從同步延遲出現(xiàn)的幾率。

(3) mixed：一般的語句修改使用statment格式保存binlog，如一些函數(shù)，statement無法完成主從復(fù)制的操作，則采用row格式保存binlog，MySQL會根據(jù)執(zhí)行的每一條具體的sql語句來區(qū)分對待記錄的日志形式，也就是在Statement和Row之間選擇一種。

(二)binlog日志內(nèi)容

mysqlbinlog命令查看的內(nèi)容如下：

根據(jù)事件類型查看的binlog內(nèi)容：

(三)binlog事件類型

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

四、MySQL主從復(fù)制原理

mysql主從復(fù)制需要三個(gè)線程，master(binlog dump thread)、slave(I/O thread 、SQL thread)。

master

(1)binlog dump線程：當(dāng)主庫中有數(shù)據(jù)更新時(shí)，那么主庫就會根據(jù)按照設(shè)置的binlog格式，將此次更新的事件類型寫入到主庫的binlog文件中，此時(shí)主庫會創(chuàng)建log dump線程通知slave有數(shù)據(jù)更新，當(dāng)I/O線程請求日志內(nèi)容時(shí)，會將此時(shí)的binlog名稱和當(dāng)前更新的位置同時(shí)傳給slave的I/O線程。

slave

(2)I/O線程：該線程會連接到master，向log dump線程請求一份指定binlog文件位置的副本，并將請求回來的binlog存到本地的relay log中，relay log和binlog日志一樣也是記錄了數(shù)據(jù)更新的事件，它也是按照遞增后綴名的方式，產(chǎn)生多個(gè)relay log( host_name-relay-bin.000001)文件，slave會使用一個(gè)index文件( host_name-relay-bin.index)來追蹤當(dāng)前正在使用的relay log文件。

(3)SQL線程：該線程檢測到relay log有更新后，會讀取并在本地做redo操作，將發(fā)生在主庫的事件在本地重新執(zhí)行一遍，來保證主從數(shù)據(jù)同步。此外，如果一個(gè)relay log文件中的全部事件都執(zhí)行完畢，那么SQL線程會自動將該relay log 文件刪除掉。

下面是整個(gè)復(fù)制過程的原理圖：

四、主從同步延遲

mysql的主從復(fù)制都是單線程的操作，主庫對所有DDL和DML產(chǎn)生binlog，binlog是順序?qū)懀孕屎芨撸瑂lave的I/O線程到主庫取日志，效率也比較高，但是，slave的SQL線程將主庫的DDL和DML操作在slave實(shí)施。DML和DDL的IO操作是隨即的，不是順序的，成本高很多，還可能存在slave上的其他查詢產(chǎn)生lock爭用的情況，由于SQL也是單線程的，所以一個(gè)DDL卡住了，需要執(zhí)行很長一段事件，后續(xù)的DDL線程會等待這個(gè)DDL執(zhí)行完畢之后才執(zhí)行，這就導(dǎo)致了延時(shí)。當(dāng)主庫的TPS并發(fā)較高時(shí)，產(chǎn)生的DDL數(shù)量超過slave一個(gè)sql線程所能承受的范圍，延時(shí)就產(chǎn)生了，除此之外，還有可能與slave的大型query語句產(chǎn)生了鎖等待導(dǎo)致。

由于主從同步延遲是客觀存在的，我們只能從我們自己的架構(gòu)上進(jìn)行設(shè)計(jì)，盡量讓主庫的DDL快速執(zhí)行。下面列出幾種常見的解決方案：