參考：深度探索MySQL主從復(fù)制原理

MySQL 主從復(fù)制概念

MySQL 主從復(fù)制是指數(shù)據(jù)可以從一個(gè)MySQL數(shù)據(jù)庫(kù)服務(wù)器主節(jié)點(diǎn)復(fù)制到一個(gè)或多個(gè)從節(jié)點(diǎn)渔期。MySQL 默認(rèn)采用異步復(fù)制方式炊苫，這樣從節(jié)點(diǎn)不用一直訪問主服務(wù)器來更新自己的數(shù)據(jù)，數(shù)據(jù)的更新可以在遠(yuǎn)程連接上進(jìn)行，從節(jié)點(diǎn)可以復(fù)制主數(shù)據(jù)庫(kù)中的所有數(shù)據(jù)庫(kù)或者特定的數(shù)據(jù)庫(kù)醋虏，或者特定的表。

MySQL 主從復(fù)制主要用途

1.讀寫分離

在開發(fā)工作中，有時(shí)候會(huì)遇見某個(gè)sql 語句需要鎖表娇豫，導(dǎo)致暫時(shí)不能使用讀的服務(wù)，這樣就會(huì)影響現(xiàn)有業(yè)務(wù)畅厢，使用主從復(fù)制冯痢，讓主庫(kù)負(fù)責(zé)寫，從庫(kù)負(fù)責(zé)讀框杜，這樣浦楣，即使主庫(kù)出現(xiàn)了鎖表的情景，通過讀從庫(kù)也可以保證業(yè)務(wù)的正常運(yùn)作咪辱。

2.數(shù)據(jù)實(shí)時(shí)備份振劳，當(dāng)系統(tǒng)中某個(gè)節(jié)點(diǎn)發(fā)生故障時(shí)，可以方便的故障切換

3.高可用HA

4.架構(gòu)擴(kuò)展

隨著系統(tǒng)中業(yè)務(wù)訪問量的增大油狂，如果是單機(jī)部署數(shù)據(jù)庫(kù)历恐，就會(huì)導(dǎo)致I/O訪問頻率過高。有了主從復(fù)制专筷，增加多個(gè)數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)弱贼，將負(fù)載分布在多個(gè)從節(jié)點(diǎn)上，降低單機(jī)磁盤I/O訪問的頻率磷蛹，提高單個(gè)機(jī)器的I/O性能吮旅。

MySQL 主從形式

1.一主一從

2.一主多從，提高系統(tǒng)的讀性能

image

一主一從和一主多從是最常見的主從架構(gòu)味咳，實(shí)施起來簡(jiǎn)單并且有效鸟辅，不僅可以實(shí)現(xiàn)HA氛什，而且還能讀寫分離，進(jìn)而提升集群的并發(fā)能力匪凉。

3.多主一從 （從5.7開始支持）

image

多主一從可以將多個(gè)mysql數(shù)據(jù)庫(kù)備份到一臺(tái)存儲(chǔ)性能比較好的服務(wù)器上枪眉。

4.雙主復(fù)制

雙主復(fù)制，也就是互做主從復(fù)制再层，每個(gè)master既是master贸铜，又是另外一臺(tái)服務(wù)器的slave。這樣任何一方所做的變更聂受，都會(huì)通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫(kù)中蒿秦。

5.級(jí)聯(lián)復(fù)制

image

級(jí)聯(lián)復(fù)制模式下，部分slave的數(shù)據(jù)同步不連接主節(jié)點(diǎn)蛋济，而是連接從節(jié)點(diǎn)棍鳖。因?yàn)槿绻鞴?jié)點(diǎn)有太多的從節(jié)點(diǎn)，就會(huì)損耗一部分性能用于replication碗旅，那么我們可以讓3~5個(gè)從節(jié)點(diǎn)連接主節(jié)點(diǎn)渡处，其它從節(jié)點(diǎn)作為二級(jí)或者三級(jí)與從節(jié)點(diǎn)連接，這樣不僅可以緩解主節(jié)點(diǎn)的壓力祟辟，并且對(duì)數(shù)據(jù)一致性沒有負(fù)面影響医瘫。

MySQL 主從復(fù)制原理

MySQL主從復(fù)制涉及到三個(gè)線程，一個(gè)運(yùn)行在主節(jié)點(diǎn)（log dump thread）旧困，其余兩個(gè)(I/O thread, SQL thread)運(yùn)行在從節(jié)點(diǎn)醇份，如下圖所示:

image

主節(jié)點(diǎn) binary log dump 線程

當(dāng)從節(jié)點(diǎn)連接主節(jié)點(diǎn)時(shí)，主節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè)log dump 線程吼具，用于發(fā)送bin-log的內(nèi)容僚纷。在讀取bin-log中的操作時(shí)，此線程會(huì)對(duì)主節(jié)點(diǎn)上的bin-log加鎖拗盒，當(dāng)讀取完成怖竭，甚至在發(fā)動(dòng)給從節(jié)點(diǎn)之前，鎖會(huì)被釋放锣咒。

從節(jié)點(diǎn)I/O線程

當(dāng)從節(jié)點(diǎn)上執(zhí)行start slave命令之后，從節(jié)點(diǎn)會(huì)創(chuàng)建一個(gè)I/O線程用來連接主節(jié)點(diǎn)赞弥，請(qǐng)求主庫(kù)中更新的bin-log毅整。I/O線程接收到主節(jié)點(diǎn)binlog dump 進(jìn)程發(fā)來的更新之后，保存在本地relay-log中绽左。

從節(jié)點(diǎn)SQL線程

SQL線程負(fù)責(zé)讀取relay log中的內(nèi)容悼嫉，解析成具體的操作并執(zhí)行，最終保證主從數(shù)據(jù)的一致性拼窥。

對(duì)于每一個(gè)主從連接戏蔑，都需要三個(gè)進(jìn)程來完成蹋凝。當(dāng)主節(jié)點(diǎn)有多個(gè)從節(jié)點(diǎn)時(shí)，主節(jié)點(diǎn)會(huì)為每一個(gè)當(dāng)前連接的從節(jié)點(diǎn)建一個(gè)binary log dump 進(jìn)程总棵，而每個(gè)從節(jié)點(diǎn)都有自己的I/O進(jìn)程鳍寂，SQL進(jìn)程。從節(jié)點(diǎn)用兩個(gè)線程將從主庫(kù)拉取更新和執(zhí)行分成獨(dú)立的任務(wù)情龄，這樣在執(zhí)行同步數(shù)據(jù)任務(wù)的時(shí)候迄汛，不會(huì)降低讀操作的性能。比如骤视，如果從節(jié)點(diǎn)沒有運(yùn)行鞍爱，此時(shí)I/O進(jìn)程可以很快從主節(jié)點(diǎn)獲取更新，盡管SQL進(jìn)程還沒有執(zhí)行专酗。如果在SQL進(jìn)程執(zhí)行之前從節(jié)點(diǎn)服務(wù)停止睹逃，至少I/O進(jìn)程已經(jīng)從主節(jié)點(diǎn)拉取到了最新的變更并且保存在本地relay日志中，當(dāng)服務(wù)再次起來之后祷肯，就可以完成數(shù)據(jù)的同步沉填。

要實(shí)施復(fù)制，首先必須打開Master 端的binary log（bin-log）功能躬柬，否則無法實(shí)現(xiàn)拜轨。

因?yàn)檎麄€(gè)復(fù)制過程實(shí)際上就是Slave 從Master 端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作。如下圖所示：

image

復(fù)制的基本過程如下:

從節(jié)點(diǎn)上的I/O 進(jìn)程連接主節(jié)點(diǎn)允青，并請(qǐng)求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內(nèi)容橄碾；

主節(jié)點(diǎn)接收到來自從節(jié)點(diǎn)的I/O請(qǐng)求后，通過負(fù)責(zé)復(fù)制的I/O進(jìn)程根據(jù)請(qǐng)求信息讀取指定日志指定位置之后的日志信息颠锉，返回給從節(jié)點(diǎn)法牲。

返回信息中除了日志所包含的信息之外，還包括本次返回的信息的bin-log file 的以及bin-log position琼掠；
從節(jié)點(diǎn)的I/O進(jìn)程接收到內(nèi)容后拒垃，將接收到的日志內(nèi)容更新到本機(jī)的relay log中，并將讀取到的binary log文件名和位置保存到master-info 文件中瓷蛙，以便在下一次讀取的時(shí)候能夠清楚的告訴Master“我需要從某個(gè)bin-log 的哪個(gè)位置開始往后的日志內(nèi)容悼瓮，請(qǐng)發(fā)給我”；

Slave 的 SQL線程檢測(cè)到relay-log 中新增加了內(nèi)容后艰猬，會(huì)將relay-log的內(nèi)容解析成在祝節(jié)點(diǎn)上實(shí)際執(zhí)行過的操作晨抡，并在本數(shù)據(jù)庫(kù)中執(zhí)行出牧。

MySQL 主從復(fù)制模式

MySQL 主從復(fù)制默認(rèn)是異步的模式结榄。MySQL增刪改操作會(huì)全部記錄在binary log中咧织，當(dāng)slave節(jié)點(diǎn)連接master時(shí)，會(huì)主動(dòng)從master處獲取最新的bin log文件。并把bin log中的sql relay胸蛛。

異步模式（mysql async-mode）

異步模式如下圖所示污茵，這種模式下，主節(jié)點(diǎn)不會(huì)主動(dòng)push bin log到從節(jié)點(diǎn)葬项，這樣有可能導(dǎo)致failover的情況下泞当，也許從節(jié)點(diǎn)沒有即時(shí)地將最新的bin log同步到本地。

image

半同步模式(mysql semi-sync)

這種模式下主節(jié)點(diǎn)只需要接收到其中一臺(tái)從節(jié)點(diǎn)的返回信息玷室，就會(huì)commit零蓉；否則需要等待直到超時(shí)時(shí)間然后切換成異步模式再提交；這樣做的目的可以使主從數(shù)據(jù)庫(kù)的數(shù)據(jù)延遲縮小穷缤，可以提高數(shù)據(jù)安全性敌蜂，確保了事務(wù)提交后，binlog至少傳輸?shù)搅艘粋€(gè)從節(jié)點(diǎn)上津肛，不能保證從節(jié)點(diǎn)將此事務(wù)更新到db中章喉。性能上會(huì)有一定的降低，響應(yīng)時(shí)間會(huì)變長(zhǎng)身坐。如下圖所示：

image

半同步模式不是mysql內(nèi)置的秸脱，從mysql 5.5開始集成，需要master 和slave 安裝插件開啟半同步模式部蛇。

全同步模式

全同步模式是指主節(jié)點(diǎn)和從節(jié)點(diǎn)全部執(zhí)行了commit并確認(rèn)才會(huì)向客戶端返回成功摊唇。

binlog記錄格式
MySQL 主從復(fù)制有三種方式：基于SQL語句的復(fù)制（statement-based replication，SBR）涯鲁，基于行的復(fù)制（row-based replication巷查，RBR)，混合模式復(fù)制（mixed-based replication,MBR)抹腿。對(duì)應(yīng)的binlog文件的格式也有三種：STATEMENT,ROW,MIXED岛请。

Statement-base Replication (SBR)就是記錄sql語句在bin log中，Mysql 5.1.4 及之前的版本都是使用的這種復(fù)制格式警绩。優(yōu)點(diǎn)是只需要記錄會(huì)修改數(shù)據(jù)的sql語句到binlog中崇败，減少了binlog日質(zhì)量，節(jié)約I/O肩祥，提高性能后室。缺點(diǎn)是在某些情況下，會(huì)導(dǎo)致主從節(jié)點(diǎn)中數(shù)據(jù)不一致（比如sleep(),now()等）混狠。

Row-based Relication(RBR)是mysql master將SQL語句分解為基于Row更改的語句并記錄在bin log中岸霹，也就是只記錄哪條數(shù)據(jù)被修改了，修改成什么樣檀蹋。優(yōu)點(diǎn)是不會(huì)出現(xiàn)某些特定情況下的存儲(chǔ)過程松申、或者函數(shù)、或者trigger的調(diào)用或者觸發(fā)無法被正確復(fù)制的問題俯逾。缺點(diǎn)是會(huì)產(chǎn)生大量的日志贸桶，尤其是修改table的時(shí)候會(huì)讓日志暴增,同時(shí)增加bin log同步時(shí)間。也不能通過bin log解析獲取執(zhí)行過的sql語句桌肴，只能看到發(fā)生的data變更皇筛。

Mixed-format Replication(MBR)，MySQL NDB cluster 7.3 和7.4 使用的MBR坠七。是以上兩種模式的混合水醋，對(duì)于一般的復(fù)制使用STATEMENT模式保存到binlog，對(duì)于STATEMENT模式無法復(fù)制的操作則使用ROW模式來保存彪置，MySQL會(huì)根據(jù)執(zhí)行的SQL語句選擇日志保存方式拄踪。

GTID復(fù)制模式
在傳統(tǒng)的復(fù)制里面，當(dāng)發(fā)生故障拳魁，需要主從切換惶桐，需要找到binlog和pos點(diǎn)，然后將主節(jié)點(diǎn)指向新的主節(jié)點(diǎn)潘懊，相對(duì)來說比較麻煩姚糊，也容易出錯(cuò)。在MySQL 5.6里面授舟，不用再找binlog和pos點(diǎn)救恨，我們只需要知道主節(jié)點(diǎn)的ip，端口释树，以及賬號(hào)密碼就行肠槽，因?yàn)閺?fù)制是自動(dòng)的，MySQL會(huì)通過內(nèi)部機(jī)制GTID自動(dòng)找點(diǎn)同步躏哩。

多線程復(fù)制（基于庫(kù)）署浩，在MySQL 5.6以前的版本，slave的復(fù)制是單線程的扫尺。一個(gè)事件一個(gè)事件的讀取應(yīng)用筋栋。而master是并發(fā)寫入的，所以延時(shí)是避免不了的正驻。唯一有效的方法是把多個(gè)庫(kù)放在多臺(tái)slave弊攘，這樣又有點(diǎn)浪費(fèi)服務(wù)器。在MySQL 5.6里面姑曙，我們可以把多個(gè)表放在多個(gè)庫(kù)襟交，這樣就可以使用多線程復(fù)制。

基于GTID復(fù)制實(shí)現(xiàn)的工作原理

主節(jié)點(diǎn)更新數(shù)據(jù)時(shí)伤靠，會(huì)在事務(wù)前產(chǎn)生GTID捣域，一起記錄到binlog日志中。從節(jié)點(diǎn)的I/O線程將變更的bin log，寫入到本地的relay log中焕梅。SQL線程從relay log中獲取GTID迹鹅，然后對(duì)比本地binlog是否有記錄（所以MySQL從節(jié)點(diǎn)必須要開啟binary log）。如果有記錄贞言，說明該GTID的事務(wù)已經(jīng)執(zhí)行斜棚，從節(jié)點(diǎn)會(huì)忽略。如果沒有記錄该窗，從節(jié)點(diǎn)就會(huì)從relay log中執(zhí)行該GTID的事務(wù)弟蚀，并記錄到bin log。在解析過程中會(huì)判斷是否有主鍵酗失，如果沒有就用二級(jí)索引义钉，如果有就用全部掃描。