|
張巖 作者
張巖邢羔，2016年加入京東他去，熟悉大型分布式系統(tǒng)設(shè)計(jì)及開(kāi)發(fā)妄均，有豐富的web開(kāi)發(fā)實(shí)戰(zhàn)經(jīng)驗(yàn)柱锹，對(duì)spring等開(kāi)源框架有源碼級(jí)了解哪自，目前主要負(fù)責(zé)京麥插件市場(chǎng)及交易平臺(tái)的研發(fā)工作。
|
|
一禁熏、前言
關(guān)于mysql主從同步壤巷，相信大家都不陌生，隨著系統(tǒng)應(yīng)用訪問(wèn)量逐漸增大瞧毙，單臺(tái)數(shù)據(jù)庫(kù)讀寫訪問(wèn)壓力也隨之增大胧华，當(dāng)讀寫訪問(wèn)達(dá)到一定瓶頸時(shí)，將數(shù)據(jù)庫(kù)的讀寫效率驟然下降宙彪，甚至不可用矩动；為了解決此類問(wèn)題，通常會(huì)采用mysql集群释漆，當(dāng)主庫(kù)宕機(jī)后悲没，集群會(huì)自動(dòng)將一個(gè)從庫(kù)升級(jí)為主庫(kù)，繼續(xù)對(duì)外提供服務(wù)男图；那么主庫(kù)和從庫(kù)之間的數(shù)據(jù)是如何同步的呢示姿？本文針對(duì)MySQL 5.7版本進(jìn)行下面的分析，下面隨筆者一起探究一下mysql主從是如何同步的逊笆。
二栈戳、MySQL主從復(fù)制原理
為了減輕主庫(kù)的壓力，應(yīng)該在系統(tǒng)應(yīng)用層面做讀寫分離难裆，寫操作走主庫(kù)荧琼，讀操作走從庫(kù)，下圖為MySQL官網(wǎng)給出的主從復(fù)制的原理圖差牛，從圖中可以簡(jiǎn)單的了解讀寫分離及主從同步的過(guò)程命锄，分散了數(shù)據(jù)庫(kù)的訪問(wèn)壓力，提升整個(gè)系統(tǒng)的性能和可用性偏化，降低了大訪問(wèn)量引發(fā)數(shù)據(jù)庫(kù)宕機(jī)的故障率脐恩。
三、binlog簡(jiǎn)介
MySQL主從同步是基于binlog文件主從復(fù)制實(shí)現(xiàn)侦讨，為了更好的理解主從同步過(guò)程驶冒，這里簡(jiǎn)單介紹一下binlog日志文件。
binlog日志用于記錄所有更新了數(shù)據(jù)或者已經(jīng)潛在更新了數(shù)據(jù)（例如韵卤，沒(méi)有匹配任何行的一個(gè)DELETE）的所有語(yǔ)句骗污。語(yǔ)句以“事件”的形式保存，它描述數(shù)據(jù)更改沈条，它是以二進(jìn)制的形式保存在磁盤中需忿。我們可以通過(guò)mysql提供的查看工具mysqlbinlog查看文件中的內(nèi)容，例如 mysqlbinlog mysql-bin.00001 | more，這里注意一下binlog文件的后綴名00001屋厘，binlog文件大小和個(gè)數(shù)會(huì)不斷的增加涕烧，當(dāng)MySQL停止或重啟時(shí)，會(huì)產(chǎn)生一個(gè)新的binlog文件汗洒，后綴名會(huì)按序號(hào)遞增议纯，例如mysql-bin.00002、mysql-bin.00003溢谤，并且當(dāng)binlog文件大小超過(guò) max_binlog_size系統(tǒng)變量配置時(shí)也會(huì)產(chǎn)生新的binlog文件瞻凤。
（一）binlog日志格式
（1） statement ： 記錄每一條更改數(shù)據(jù)的sql;
優(yōu)點(diǎn)：binlog文件較小，節(jié)約I/O世杀，性能較高鲫构。
缺點(diǎn)：不是所有的數(shù)據(jù)更改都會(huì)寫入binlog文件中，尤其是使用MySQL中的一些特殊函數(shù)（如LOAD_FILE()玫坛、UUID()等）和一些不確定的語(yǔ)句操作结笨，從而導(dǎo)致主從數(shù)據(jù)無(wú)法復(fù)制的問(wèn)題。
（2） row ： 不記錄sql湿镀，只記錄每行數(shù)據(jù)的更改細(xì)節(jié)
優(yōu)點(diǎn)：詳細(xì)的記錄了每一行數(shù)據(jù)的更改細(xì)節(jié)炕吸，這也意味著不會(huì)由于使用一些特殊函數(shù)或其他情況導(dǎo)致不能復(fù)制的問(wèn)題。
缺點(diǎn)：由于row格式記錄了每一行數(shù)據(jù)的更改細(xì)節(jié)勉痴，會(huì)產(chǎn)生大量的binlog日志內(nèi)容赫模，性能不佳，并且會(huì)增大主從同步延遲出現(xiàn)的幾率蒸矛。
（3） mixed：一般的語(yǔ)句修改使用statment格式保存binlog瀑罗，如一些函數(shù)，statement無(wú)法完成主從復(fù)制的操作雏掠，則采用row格式保存binlog斩祭，MySQL會(huì)根據(jù)執(zhí)行的每一條具體的sql語(yǔ)句來(lái)區(qū)分對(duì)待記錄的日志形式，也就是在Statement和Row之間選擇一種乡话。
（二）binlog日志內(nèi)容
mysqlbinlog命令查看的內(nèi)容如下：
根據(jù)事件類型查看的binlog內(nèi)容：
（三）binlog事件類型
MySQL binlog記錄的所有操作實(shí)際上都有對(duì)應(yīng)的事件類型的摧玫，譬如STATEMENT格式中的DML操作對(duì)應(yīng)的是QUERY_EVENT類型，ROW格式下的DML操作對(duì)應(yīng)的是ROWS_EVENT類型绑青，如果想了解更多請(qǐng)參考官方文檔诬像，有關(guān)binlog日志內(nèi)容不在這里過(guò)多贅述疫蔓，簡(jiǎn)單介紹一下是為了更好的理解主從復(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)主庫(kù)中有數(shù)據(jù)更新時(shí)，那么主庫(kù)就會(huì)根據(jù)按照設(shè)置的binlog格式喊熟，將此次更新的事件類型寫入到主庫(kù)的binlog文件中柏肪，此時(shí)主庫(kù)會(huì)創(chuàng)建log dump線程通知slave有數(shù)據(jù)更新姐刁，當(dāng)I/O線程請(qǐng)求日志內(nèi)容時(shí)芥牌，會(huì)將此時(shí)的binlog名稱和當(dāng)前更新的位置同時(shí)傳給slave的I/O線程。
slave
（2）I/O線程：該線程會(huì)連接到master聂使，向log dump線程請(qǐng)求一份指定binlog文件位置的副本壁拉，并將請(qǐng)求回來(lái)的binlog存到本地的relay log中，relay log和binlog日志一樣也是記錄了數(shù)據(jù)更新的事件柏靶，它也是按照遞增后綴名的方式弃理，產(chǎn)生多個(gè)relay log（ host_name-relay-bin.000001）文件，slave會(huì)使用一個(gè)index文件（ host_name-relay-bin.index）來(lái)追蹤當(dāng)前正在使用的relay log文件屎蜓。
（3）SQL線程：該線程檢測(cè)到relay log有更新后痘昌，會(huì)讀取并在本地做redo操作，將發(fā)生在主庫(kù)的事件在本地重新執(zhí)行一遍炬转，來(lái)保證主從數(shù)據(jù)同步辆苔。此外，如果一個(gè)relay log文件中的全部事件都執(zhí)行完畢扼劈，那么SQL線程會(huì)自動(dòng)將該relay log 文件刪除掉驻啤。
下面是整個(gè)復(fù)制過(guò)程的原理圖：
四、主從同步延遲
mysql的主從復(fù)制都是單線程的操作荐吵，主庫(kù)對(duì)所有DDL和DML產(chǎn)生binlog骑冗，binlog是順序?qū)懀孕屎芨呦燃澹瑂lave的I/O線程到主庫(kù)取日志贼涩，效率也比較高，但是薯蝎，slave的SQL線程將主庫(kù)的DDL和DML操作在slave實(shí)施磁携。DML和DDL的IO操作是隨即的，不是順序的良风，成本高很多谊迄，還可能存在slave上的其他查詢產(chǎn)生lock爭(zhēng)用的情況，由于SQL也是單線程的烟央，所以一個(gè)DDL卡住了统诺，需要執(zhí)行很長(zhǎng)一段事件，后續(xù)的DDL線程會(huì)等待這個(gè)DDL執(zhí)行完畢之后才執(zhí)行疑俭，這就導(dǎo)致了延時(shí)粮呢。當(dāng)主庫(kù)的TPS并發(fā)較高時(shí)，產(chǎn)生的DDL數(shù)量超過(guò)slave一個(gè)sql線程所能承受的范圍，延時(shí)就產(chǎn)生了啄寡，除此之外豪硅，還有可能與slave的大型query語(yǔ)句產(chǎn)生了鎖等待導(dǎo)致。
由于主從同步延遲是客觀存在的挺物，我們只能從我們自己的架構(gòu)上進(jìn)行設(shè)計(jì)懒浮， 盡量讓主庫(kù)的DDL快速執(zhí)行。下面列出幾種常見(jiàn)的解決方案：
1. 業(yè)務(wù)的持久化層的實(shí)現(xiàn)采用分庫(kù)架構(gòu)识藤，mysql服務(wù)可平行擴(kuò)展砚著，分散壓力。
2. 服務(wù)的基礎(chǔ)架構(gòu)在業(yè)務(wù)和mysql之間加入memcache或者Redis的cache層痴昧。降低mysql的讀壓力稽穆；
3. 使用比主庫(kù)更好的硬件設(shè)備作為slave；
4. sync_binlog在slave端設(shè)置為0赶撰；
5. –logs-slave-updates 從服務(wù)器從主服務(wù)器接收到的更新不記入它的二進(jìn)制日志舌镶。
6. 禁用slave的binlog
五、參考資料
https://dev.mysql.com/doc/refman/5.7/en/replication.html
http://www.linuxidc.com/Linux/2014-05/101450.htm
http://blog.csdn.net/xiongping_/article/details/49907095
http://www.cnblogs.com/martinzhang/p/3454358.html
轉(zhuǎn)載請(qǐng)并標(biāo)注: “本文轉(zhuǎn)載自 linkedkeeper.com (文／張巖)”
|
