前言
年后在進(jìn)行騰訊二面的時(shí)候，寫完算法的后問的第一個(gè)問題就是衫生，MySQL的半同步是什么裳瘪？我當(dāng)時(shí)直接懵了，我以為是問的MySQL的兩階段提交的問題呢罪针？結(jié)果確認(rèn)了一下后不是兩階段提交，然后面試官看我連問的是啥都不知道黄伊，就直接跳過這個(gè)問題泪酱，直接聊下一個(gè)問題了。所以這次總結(jié)一下這部分的知識(shí)內(nèi)容还最，文字內(nèi)容比較多墓阀，可能會(huì)有些枯燥，但對(duì)于這方面感興趣的人來說還是比較有意思的拓轻。
MySQL的主從復(fù)制
我們的一般在大規(guī)模的項(xiàng)目上斯撮，都是使用MySQL的復(fù)制功能來創(chuàng)建MySQL的主從集群的。主要是可以通過為服務(wù)器配置一個(gè)或多個(gè)備庫的方式來進(jìn)行數(shù)據(jù)同步扶叉。復(fù)制的功能不僅有利于構(gòu)建 高性能應(yīng)用勿锅，同時(shí)也是高可用帕膜、可擴(kuò)展性、災(zāi)難恢復(fù)溢十、備份以及數(shù)據(jù)倉庫等工作的基礎(chǔ) 垮刹。
說得通俗一點(diǎn)，通過MySQL的主從復(fù)制來實(shí)現(xiàn)讀寫分離张弛，相比單點(diǎn)數(shù)據(jù)庫又讀又寫來說荒典，提升了業(yè)務(wù)系統(tǒng)性能，優(yōu)化了用戶體驗(yàn)吞鸭。另外通過主從復(fù)制實(shí)現(xiàn)了數(shù)據(jù)庫的高可用寺董，當(dāng)主節(jié)點(diǎn)MySQL掛了的時(shí)候，可以用從庫來頂上刻剥。
MySQL支持的復(fù)制方式
MySQL支持三種復(fù)制方式：
- 基于語句的復(fù)制（也稱為邏輯復(fù)制）主要是指遮咖，在主數(shù)據(jù)庫上執(zhí)行的SQL語句，在從數(shù)據(jù)庫上會(huì)重復(fù)執(zhí)行一遍 透敌。MySQL默認(rèn)采用的就是這種復(fù)制盯滚，效率比較高。但是也是有一定的問題的酗电，如果SQL中使用uuid()魄藕、rand()等函數(shù)，那么復(fù)制到從庫的數(shù)據(jù)就會(huì)有偏差撵术。
- 基于行的復(fù)制背率，指將更新處理后的數(shù)據(jù)復(fù)制到從數(shù)據(jù)庫，而不是執(zhí)行一邊語句 嫩与。從MySQL5.1的版本才被支持寝姿。
- 混合復(fù)制，默認(rèn)采用語句復(fù)制划滋，當(dāng)發(fā)現(xiàn)語句不能進(jìn)行精準(zhǔn)復(fù)制數(shù)據(jù)時(shí)（例如語句中含有uuid()饵筑、rand()等函數(shù)），采用基于行的復(fù)制 处坪。
主從復(fù)制原理
MySQL的復(fù)制原理概述上來講大體可以分為這三步
- 在主庫上把數(shù)據(jù)更改根资，記錄到二進(jìn)制日志（Binary Log）中。
- 從庫將主庫上的日志復(fù)制到自己的中繼日志（Relay Log）中同窘。
- 備庫讀取中繼日志中的事件玄帕，將其重放到備庫數(shù)據(jù)之上。
主要過程如下圖：
下面來詳細(xì)說一下復(fù)制的這三步：
第一步：是在主庫上記錄二進(jìn)制日志想邦，首先主庫要開啟binlog日志記錄功能裤纹，并授權(quán)Slave從庫可以訪問的權(quán)限。這里需要注意的一點(diǎn)就是binlog的日志里的順序是按照事務(wù)提交的順序來記錄的而非每條語句的執(zhí)行順序丧没。
第二步：從庫將binLog復(fù)制到其本地的RelayLog中鹰椒。首先從庫會(huì)啟動(dòng)一個(gè)工作線程锡移，稱為I/O線程，I/O線程跟主庫建立一個(gè)普通的客戶端連接吹零，然后主庫上啟動(dòng)一個(gè)特殊的二進(jìn)制轉(zhuǎn)儲(chǔ)（binlog dump）線程罩抗，此轉(zhuǎn)儲(chǔ)線程會(huì)讀取binlog中的事件。當(dāng)追趕上主庫后灿椅，會(huì)進(jìn)行休眠套蒂，直到主庫通知有新的更新語句時(shí)才繼續(xù)被喚醒。
這樣通過從庫上的I/O線程和主庫上的binlog dump線程茫蛹，就將binlog數(shù)據(jù)傳輸?shù)綇膸焐系膔elaylog中了操刀。
第三步：從庫中啟動(dòng)一個(gè)SQL線程，從relaylog中讀取事件并在備庫中執(zhí)行婴洼，從而實(shí)現(xiàn)備庫數(shù)據(jù)的更新骨坑。
這種復(fù)制架構(gòu)實(shí)現(xiàn)了獲取事件和重放事件的解耦，運(yùn)行I/O線程能夠獨(dú)立于SQL線程之外工作柬采。但是這種架構(gòu)也限制復(fù)制的過程欢唾，最重要的一點(diǎn)是在主庫上并發(fā)運(yùn)行的查詢?cè)趥鋷熘兄荒艽谢瘓?zhí)行，因?yàn)橹挥幸粋€(gè)SQL線程來重放中繼日志中的事件粉捻。
說到這個(gè)主從復(fù)制的串行化執(zhí)行的問題礁遣，我就想到了一個(gè)之前在工作中遇到的一個(gè)問題，就是有這么一個(gè)業(yè)務(wù)場(chǎng)景肩刃，我們有一個(gè)操作是初始化一批數(shù)據(jù)祟霍，數(shù)據(jù)是從一個(gè)外部系統(tǒng)的接口中獲取的，然后我是通過線程池里的多個(gè)線程并行從外部系統(tǒng)的接口中獲取數(shù)據(jù)盈包，每個(gè)線程獲取到數(shù)據(jù)后沸呐，直接插入到數(shù)據(jù)庫中。然后在數(shù)據(jù)全部入庫完成后呢燥，然后去執(zhí)行批量查詢崭添，將剛插入到數(shù)據(jù)庫中的數(shù)據(jù)查詢出來，放到ElasticSearch中叛氨。結(jié)果每次放入到ES中的數(shù)據(jù)總是不完整滥朱，后來研究了半天都不行，最終是讓查詢也走的主庫才解決的問題力试。當(dāng)時(shí)不知道是MySQL主從復(fù)制的串行化從而導(dǎo)致的這個(gè)問題。
MySQL主從復(fù)制模式
MySQL的主從復(fù)制其實(shí)是支持排嫌， 異步復(fù)制 畸裳、 半同步復(fù)制 、 GTID復(fù)制 等多種復(fù)制模式的淳地。
異步模式
MySQL的默認(rèn)復(fù)制模式就是異步模式怖糊，主要是 指MySQL的主服務(wù)器上的I/O線程帅容，將數(shù)據(jù)寫到binlong中就直接返回給客戶端數(shù)據(jù)更新成功，不考慮數(shù)據(jù)是否傳輸?shù)綇姆?wù)器伍伤，以及是否寫入到relaylog中 并徘。在這種模式下，復(fù)制數(shù)據(jù)其實(shí)是有風(fēng)險(xiǎn)的扰魂，一旦數(shù)據(jù)只寫到了主庫的binlog中還沒來得及同步到從庫時(shí)麦乞，就會(huì)造成數(shù)據(jù)的丟失。
但是這種模式確也是效率最高的劝评，因?yàn)樽兏鼣?shù)據(jù)的功能都只是在主庫中完成就可以了姐直，從庫復(fù)制數(shù)據(jù)不會(huì)影響到主庫的寫數(shù)據(jù)操作。
上面我也說了蒋畜，這種異步復(fù)制模式雖然效率高声畏，但是數(shù)據(jù)丟失的風(fēng)險(xiǎn)很大，所以就有了后面要介紹的半同步復(fù)制模式姻成。
半同步模式
MySQL從 5.5 版本開始通過以插件的形式開始支持半同步的主從復(fù)制模式插龄。什么是半同步主從復(fù)制模式呢？
這里通過對(duì)比的方式來說明一下：
- 異步復(fù)制模式 ：上面我們已經(jīng)介紹了科展，異步復(fù)制模式均牢，主庫在執(zhí)行完客戶端提交的事務(wù)后，只要將執(zhí)行邏輯寫入到binlog后辛润，就立即返回給客戶端膨处，并不關(guān)心從庫是否執(zhí)行成功，這樣就會(huì)有一個(gè)隱患砂竖，就是在主庫執(zhí)行的binlog還沒同步到從庫時(shí)真椿，主庫掛了，這個(gè)時(shí)候從庫就就會(huì)被強(qiáng)行提升為主庫乎澄，這個(gè)時(shí)候就有可能造成數(shù)據(jù)丟失突硝。
- 同步復(fù)制模式 ：當(dāng)主庫執(zhí)行完客戶端提交的事務(wù)后，需要等到所有從庫也都執(zhí)行完這一事務(wù)后置济，才返回給客戶端執(zhí)行成功解恰。因?yàn)橐鹊剿袕膸於紙?zhí)行完，執(zhí)行過程中會(huì)被阻塞浙于，等待返回結(jié)果护盈，所以性能上會(huì)有很嚴(yán)重的影響。
- 半同步復(fù)制模式 ：半同步復(fù)制模式羞酗，可以說是介于異步和同步之間的一種復(fù)制模式腐宋，主庫在執(zhí)行完客戶端提交的事務(wù)后，要等待至少一個(gè)從庫接收到binlog并將數(shù)據(jù)寫入到relay log中才返回給客戶端成功結(jié)果。半同步復(fù)制模式胸竞，比異步模式提高了數(shù)據(jù)的可用性欺嗤，但是也產(chǎn)生了一定的性能延遲，最少要一個(gè)TCP/IP連接的往返時(shí)間卫枝。
半同步復(fù)制模式煎饼，可以很明確的知道，在一個(gè)事務(wù)提交成功之后校赤，此事務(wù)至少會(huì)存在于兩個(gè)地方一個(gè)是主庫一個(gè)是從庫中的某一個(gè)吆玖。 主要原理是，在master的dump線程去通知從庫時(shí)痒谴，增加了一個(gè)ACK機(jī)制衰伯，也就是會(huì)確認(rèn)從庫是否收到事務(wù)的標(biāo)志碼，master的dump線程不但要發(fā)送binlog到從庫积蔚，還有負(fù)責(zé)接收slave的ACK意鲸。當(dāng)出現(xiàn)異常時(shí)，Slave沒有ACK事務(wù)尽爆，那么將自動(dòng)降級(jí)為異步復(fù)制怎顾，直到異常修復(fù)后再自動(dòng)變?yōu)榘胪綇?fù)制
MySQL半同步復(fù)制的流程如下：
半同步復(fù)制的隱患
半同步復(fù)制模式也存在一定的數(shù)據(jù)風(fēng)險(xiǎn)，當(dāng)事務(wù)在主庫提交完后等待從庫ACK的過程中漱贱，如果Master宕機(jī)了槐雾，這個(gè)時(shí)候就會(huì)有兩種情況的問題。
- 事務(wù)還沒發(fā)送到Slave上 ：若事務(wù)還沒發(fā)送Slave上幅狮，客戶端在收到失敗結(jié)果后募强，會(huì)重新提交事務(wù)，因?yàn)橹匦绿峤坏氖聞?wù)是在新的Master上執(zhí)行的崇摄，所以會(huì)執(zhí)行成功擎值，后面若是之前的Master恢復(fù)后，會(huì)以Slave的身份加入到集群中逐抑，這個(gè)時(shí)候鸠儿，之前的事務(wù)就會(huì)被執(zhí)行兩次，第一次是之前此臺(tái)機(jī)器作為Master的時(shí)候執(zhí)行的厕氨，第二次是做為Slave后從主庫中同步過來的进每。
- 事務(wù)已經(jīng)同步到Slave上 ：因?yàn)槭聞?wù)已經(jīng)同步到Slave了，所以當(dāng)客戶端收到失敗結(jié)果后命斧，再次提交事務(wù)田晚，你那么此事務(wù)就會(huì)在當(dāng)前Slave機(jī)器上執(zhí)行兩次。
為了解決上面的隱患国葬，MySQL從5.7版本開始肉瓦，增加了一種新的半同步方式遭京。新的半同步方式的執(zhí)行過程是將“ Storage Commit ”這一步移動(dòng)到了“ Write Slave dump ”后面。這樣保證了 只有Slave的事務(wù)ACK后泞莉，才提交主庫事務(wù) 。MySQL 5.7.2版本新增了一個(gè)參數(shù)來進(jìn)行配置： rpl_semi_sync_master_wait_point 船殉，此參數(shù)有兩個(gè)值可配置：
- AFTER_SYNC ：參數(shù)值為AFTER_SYNC時(shí)鲫趁，代表采用的是新的半同步復(fù)制方式。
- AFTER_COMMIT ：代表采用的是之前的舊方式的半同步復(fù)制模式利虫。
MySQL從5.7.2版本開始挨厚，默認(rèn)的半同步復(fù)制方式就是 AFTER_SYNC 方式了，但是方案不是萬能的糠惫，因?yàn)?AFTER_SYNC 方式是在事務(wù)同步到Slave后才提交主庫的事務(wù)的疫剃，若是當(dāng)主庫等待Slave同步成功的過程中Master掛了，這個(gè)Master事務(wù)提交就失敗了硼讽，客戶端也收到了事務(wù)執(zhí)行失敗的結(jié)果了巢价，但是Slave上已經(jīng)將binLog的內(nèi)容寫到Relay Log里了，這個(gè)時(shí)候固阁，Slave數(shù)據(jù)就會(huì)多了壤躲，但是多了數(shù)據(jù)一般問題不算嚴(yán)重，多了總比少了好备燃。MySQL碉克，在沒辦法解決分布式數(shù)據(jù)一致性問題的情況下，它能保證的是不丟數(shù)據(jù)并齐，多了數(shù)據(jù)總比丟數(shù)據(jù)要好漏麦。
這里說幾個(gè)的半同步復(fù)制模式的參數(shù)：
mysql> show variables like '%Rpl%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
| rpl_stop_slave_timeout | 31536000 |
+-------------------------------------------+------------+
-- 半同步復(fù)制模式開關(guān)
rpl_semi_sync_master_enabled
-- 半同步復(fù)制，超時(shí)時(shí)間况褪，單位毫秒撕贞，當(dāng)超過此時(shí)間后，自動(dòng)切換為異步復(fù)制模式
rpl_semi_sync_master_timeout
-- MySQL 5.7.3引入的窝剖，該變量設(shè)置主需要等待多少個(gè)slave應(yīng)答麻掸，才能返回給客戶端，默認(rèn)為1赐纱。
rpl_semi_sync_master_wait_for_slave_count
-- 此值代表當(dāng)前集群中的slave數(shù)量是否還能夠滿足當(dāng)前配置的半同步復(fù)制模式脊奋，默認(rèn)為ON，當(dāng)不滿足半同步復(fù)制模式后疙描，全部Slave切換到異步復(fù)制诚隙，此值也會(huì)變?yōu)镺FF
rpl_semi_sync_master_wait_no_slave
-- 代表半同步復(fù)制提交事務(wù)的方式，5.7.2之后起胰，默認(rèn)為AFTER_SYNC
rpl_semi_sync_master_wait_point
GTID模式
MySQL從5.6版本開始推出了GTID復(fù)制模式久又，GTID即全局事務(wù)ID (global transaction identifier)的簡(jiǎn)稱巫延，GTID是由UUID+TransactionId組成的，UUID是單個(gè)MySQL實(shí)例的唯一標(biāo)識(shí)地消，在第一次啟動(dòng)MySQL實(shí)例時(shí)會(huì)自動(dòng)生成一個(gè)server_uuid, 并且默認(rèn)寫入到數(shù)據(jù)目錄下的auto.cnf(mysql/data/auto.cnf)文件里炉峰。TransactionId是該MySQL上執(zhí)行事務(wù)的數(shù)量，隨著事務(wù)數(shù)量增加而遞增脉执。這樣保證了 GTID在一組復(fù)制中疼阔，全局唯一 。
這樣通過GTID可以清晰地看到半夷，當(dāng)前事務(wù)是從哪個(gè)實(shí)例上提交的婆廊，提交的第多少個(gè)事務(wù)。
來看一個(gè)GTID的具體形式：
mysql> show master status;
+-----------+----------+--------------+------------------+-------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-----------+----------+--------------+------------------+-------------------------------------------+
| on.000003 | 187 | | | 76147e28-8086-4f8c-9f98-1cf33d92978d:1-322|
+-----------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)
GTID：76147e28-8086-4f8c-9f98-1cf33d92978d:1-322
UUID：76147e28-8086-4f8c-9f98-1cf33d92978d
TransactionId:1-322
GTID的工作原理
由于GTID在一組主從復(fù)制集群中的唯一性巫橄，從而保證了每個(gè)GTID的事務(wù)只在一個(gè)MySQL上執(zhí)行一次淘邻。
那么是怎么實(shí)現(xiàn)這種機(jī)制的呢？GTID的原理又是什么樣的呢湘换？
當(dāng)從服務(wù)器連接主服務(wù)器時(shí)宾舅，把自己執(zhí)行過的GTID（ Executed_Gtid_Set: 即已經(jīng)執(zhí)行的事務(wù)編碼 ）以及獲取到GTID（ Retrieved_Gtid_Set: 即從庫已經(jīng)接收到主庫的事務(wù)編號(hào) ）都傳給主服務(wù)器。主服務(wù)器會(huì)從服務(wù)器缺少的GTID以及對(duì)應(yīng)的transactionID都發(fā)送給從服務(wù)器枚尼，讓從服務(wù)器補(bǔ)全數(shù)據(jù)贴浙。當(dāng)主服務(wù)器宕機(jī)時(shí)，會(huì)找出同步數(shù)據(jù)最成功的那臺(tái)conf服務(wù)器署恍，直接將它提升為主服務(wù)器崎溃。若是強(qiáng)制要求某一臺(tái)不是同步最成功的一臺(tái)從服務(wù)器為主，會(huì)先通過change命令到最成功的那臺(tái)服務(wù)器盯质，將GTID進(jìn)行補(bǔ)全袁串，然后再把強(qiáng)制要求的那臺(tái)機(jī)器提升為主。
主要數(shù)據(jù)同步機(jī)制可以分為這幾步：
- master更新數(shù)據(jù)時(shí)呼巷，在事務(wù)前生產(chǎn)GTID囱修，一同記錄到binlog中。
- slave端的i/o線程王悍，將變更的binlog寫入到relay log中破镰。
- sql線程從relay log中獲取GTID，然后對(duì)比Slave端的binlog是否有記錄压储。
- 如果有記錄鲜漩，說明該GTID的事務(wù)已經(jīng)執(zhí)行，slave會(huì)忽略該GTID集惋。
- 如果沒有記錄孕似，Slave會(huì)從relay log中執(zhí)行該GTID事務(wù)，并記錄到binlog刮刑。
- 在解析過程中喉祭，判斷是否有主鍵养渴，如果沒有主鍵就使用二級(jí)索引，再?zèng)]有二級(jí)索引就掃描全表泛烙。
初始結(jié)構(gòu)如下圖
當(dāng)Master出現(xiàn)宕機(jī)后理卑，就會(huì)演變成下圖。
通過上圖我們可以看出來胶惰，當(dāng)Master掛掉后傻工，Slave-1執(zhí)行完了Master的事務(wù)，Slave-2延時(shí)一些孵滞，所以沒有執(zhí)行完Master的事務(wù)，這個(gè)時(shí)候提升Slave-1為主鸯匹，Slave-2連接了新主（Slave-1）后坊饶，將最新的GTID傳給新主，然后Slave-1就從這個(gè)GTID的下一個(gè)GTID開始發(fā)送事務(wù)給Slave-2殴蓬。 這種自我尋找復(fù)制位置的模式減少事務(wù)丟失的可能性以及故障恢復(fù)的時(shí)間匿级。
GTID的優(yōu)劣勢(shì)
通過上面的分析我們可以得出GTID的優(yōu)勢(shì)是：
- 每一個(gè)事務(wù)對(duì)應(yīng)一個(gè)執(zhí)行ID，一個(gè)GTID在一個(gè)服務(wù)器上只會(huì)執(zhí)行一次;
- GTID是用來代替?zhèn)鹘y(tǒng)復(fù)制的方法染厅，GTID復(fù)制與普通復(fù)制模式的最大不同就是不需要指定二進(jìn)制文件名和位置;
- 減少手工干預(yù)和降低服務(wù)故障時(shí)間痘绎，當(dāng)主機(jī)掛了之后通過軟件從眾多的備機(jī)中提升一臺(tái)備機(jī)為主機(jī);
GTID的缺點(diǎn)也很明顯：
- 首先不支持非事務(wù)的存儲(chǔ)引擎；
- 不支持create table ... select 語句復(fù)制(主庫直接報(bào)錯(cuò));(原理: 會(huì)生成兩個(gè)sql, 一個(gè)是DDL創(chuàng)建表SQL, 一個(gè)是insert into 插入數(shù)據(jù)的sql; 由于DDL會(huì)導(dǎo)致自動(dòng)提交, 所以這個(gè)sql至少需要兩個(gè)GTID, 但是GTID模式下, 只能給這個(gè)sql生成一個(gè)GTID)
- 不允許一個(gè)SQL同時(shí)更新一個(gè)事務(wù)引擎表和非事務(wù)引擎表;
- 在一個(gè)MySQL復(fù)制群組中肖粮，要求全部開啟GTID或關(guān)閉GTID孤页。
- 開啟GTID需要重啟 (mysql5.7除外);
- 開啟GTID后，就不再使用原來的傳統(tǒng)復(fù)制方式（不像半同步復(fù)制涩馆，半同步復(fù)制失敗后行施，可以降級(jí)到異步復(fù)制）;
- 對(duì)于create temporary table 和 drop temporary table語句不支持;
- 不支持sql_slave_skip_counter;
其實(shí)GTID的這部分內(nèi)容挺多的，如果有想深入研究的可以去看看這篇文章魂那。
最后說幾個(gè)開啟GTID的必備條件：
- MySQL 5.6 版本蛾号，在my.cnf文件中添加:
gtid_mode=on (必選) #開啟gtid功能
log_bin=log-bin=mysql-bin (必選) #開啟binlog二進(jìn)制日志功能
log-slave-updates=1 (必選) #也可以將1寫為on
enforce-gtid-consistency=1 (必選) #也可以將1寫為on
- MySQL 5.7或更高版本，在my.cnf文件中添加:
gtid_mode=on (必選)
enforce-gtid-consistency=1 （必選）
log_bin=mysql-bin （可選） #高可用切換涯雅，最好開啟該功能
log-slave-updates=1 （可選） #高可用切換鲜结，最好打開該功能
如果覺得本文對(duì)你有幫助，可以轉(zhuǎn)發(fā)關(guān)注支持一下
