前言

年后在進(jìn)行騰訊二面的時候，寫完算法的后問的第一個問題就是，MySQL的半同步是什么？我當(dāng)時直接懵了，我以為是問的MySQL的兩階段提交的問題呢？結(jié)果確認(rèn)了一下后不是兩階段提交，然后面試官看我連問的是啥都不知道，就直接跳過這個問題，直接聊下一個問題了。所以這次總結(jié)一下這部分的知識內(nèi)容，文字內(nèi)容比較多，可能會有些枯燥，但對于這方面感興趣的人來說還是比較有意思的。

MySQL的主從復(fù)制

我們的一般在大規(guī)模的項目上，都是使用MySQL的復(fù)制功能來創(chuàng)建MySQL的主從集群的。主要是可以通過為服務(wù)器配置一個或多個備庫的方式來進(jìn)行數(shù)據(jù)同步。復(fù)制的功能不僅有利于構(gòu)建高性能應(yīng)用，同時也是高可用、可擴展性、災(zāi)難恢復(fù)、備份以及數(shù)據(jù)倉庫等工作的基礎(chǔ)。

說的通俗一點，通過MySQL的主從復(fù)制來實現(xiàn)讀寫分離，相比單點數(shù)據(jù)庫又讀又寫來說，提升了業(yè)務(wù)系統(tǒng)性能，優(yōu)化了用戶體驗。另外通過主從復(fù)制實現(xiàn)了數(shù)據(jù)庫的高可用，當(dāng)主節(jié)點MySQL掛了的時候，可以用從庫來頂上。

MySQL支持的復(fù)制方式

MySQL支持三種復(fù)制方式：

• 基于語句的復(fù)制（也稱為邏輯復(fù)制）主要是指，在主數(shù)據(jù)庫上執(zhí)行的SQL語句，在從數(shù)據(jù)庫上會重復(fù)執(zhí)行一遍。MySQL默認(rèn)采用的就是這種復(fù)制，效率比較高。但是也是有一定的問題的，如果SQL中使用uuid()、rand()等函數(shù)，那么復(fù)制到從庫的數(shù)據(jù)就會有偏差。
• 基于行的復(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ù)時（例如語句中含有uuid()、rand()等函數(shù)），采用基于行的復(fù)制。
  

主從復(fù)制原理

MySQL的復(fù)制原理概述上來講大體可以分為這三步

1. 在主庫上把數(shù)據(jù)更改，記錄到二進(jìn)制日志（Binary Log）中。
2. 從庫將主庫上的日志復(fù)制到自己的中繼日志（Relay Log）中。
3. 備庫讀取中繼日志中的事件，將其重放到備庫數(shù)據(jù)之上。
   

主要過程如下圖：

下面來詳細(xì)說一下復(fù)制的這三步：

第一步：是在主庫上記錄二進(jìn)制日志，首先主庫要開啟binlog日志記錄功能，并授權(quán)Slave從庫可以訪問的權(quán)限。這里需要注意的一點就是binlog的日志里的順序是按照事務(wù)提交的順序來記錄的而非每條語句的執(zhí)行順序。

第二步：從庫將binLog復(fù)制到其本地的RelayLog中。首先從庫會啟動一個工作線程，稱為I/O線程，I/O線程跟主庫建立一個普通的客戶端連接，然后主庫上啟動一個特殊的二進(jìn)制轉(zhuǎn)儲（binlog dump）線程，此轉(zhuǎn)儲線程會讀取binlog中的事件。當(dāng)追趕上主庫后，會進(jìn)行休眠，直到主庫通知有新的更新語句時才繼續(xù)被喚醒。 這樣通過從庫上的I/O線程和主庫上的binlog dump線程，就將binlog數(shù)據(jù)傳輸?shù)綇膸焐系膔elaylog中了。

第三步：從庫中啟動一個SQL線程，從relaylog中讀取事件并在備庫中執(zhí)行，從而實現(xiàn)備庫數(shù)據(jù)的更新。

==這種復(fù)制架構(gòu)實現(xiàn)了獲取事件和重放事件的解耦，運行I/O線程能夠獨立于SQL線程之外工作。但是這種架構(gòu)也限制復(fù)制的過程，最重要的一點是在主庫上并發(fā)運行的查詢在備庫中只能串行化執(zhí)行，因為只有一個SQL線程來重放中繼日志中的事件。==

說到這個主從復(fù)制的串行化執(zhí)行的問題，我就想到了一個之前在工作中遇到的一個問題，就是有這么一個業(yè)務(wù)場景，我們有一個操作是初始化一批數(shù)據(jù)，數(shù)據(jù)是從一個外部系統(tǒng)的接口中獲取的，然后我是通過線程池里的多個線程并行從外部系統(tǒng)的接口中獲取數(shù)據(jù)，每個線程獲取到數(shù)據(jù)后，直接插入到數(shù)據(jù)庫中。然后在數(shù)據(jù)全部入庫完成后，然后去執(zhí)行批量查詢，將剛插入到數(shù)據(jù)庫中的數(shù)據(jù)查詢出來，放到ElasticSearch中。結(jié)果每次放入到ES中的數(shù)據(jù)總是不完整，后來研究了半天都不行，最終是讓查詢也走的主庫才解決的問題。當(dāng)時不知道是MySQL主從復(fù)制的串行化從而導(dǎo)致的這個問題。

MySQL主從復(fù)制模式

MySQL的主從復(fù)制其實是支持，異步復(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ù)其實是有風(fēng)險的，一旦數(shù)據(jù)只寫到了主庫的binlog中還沒來得急同步到從庫時，就會造成數(shù)據(jù)的丟失。

但是這種模式確也是效率最高的，因為變更數(shù)據(jù)的功能都只是在主庫中完成就可以了，從庫復(fù)制數(shù)據(jù)不會影響到主庫的寫數(shù)據(jù)操作。

上面我也說了，這種異步復(fù)制模式雖然效率高，但是數(shù)據(jù)丟失的風(fēng)險很大，所以就有了后面要介紹的半同步復(fù)制模式。

半同步模式

MySQL從5.5版本開始通過以插件的形式開始支持半同步的主從復(fù)制模式。什么是半同步主從復(fù)制模式呢？ 這里通過對比的方式來說明一下：

• 異步復(fù)制模式：上面我們已經(jīng)介紹了，異步復(fù)制模式，主庫在執(zhí)行完客戶端提交的事務(wù)后，只要將執(zhí)行邏輯寫入到binlog后，就立即返回給客戶端，并不關(guān)心從庫是否執(zhí)行成功，這樣就會有一個隱患，就是在主庫執(zhí)行的binlog還沒同步到從庫時，主庫掛了，這個時候從庫就就會被強行提升為主庫，這個時候就有可能造成數(shù)據(jù)丟失。
• 同步復(fù)制模式：當(dāng)主庫執(zhí)行完客戶端提交的事務(wù)后，需要等到所有從庫也都執(zhí)行完這一事務(wù)后，才返回給客戶端執(zhí)行成功。因為要等到所有從庫都執(zhí)行完，執(zhí)行過程中會被阻塞，等待返回結(jié)果，所以性能上會有很嚴(yán)重的影響。
• 半同步復(fù)制模式：半同步復(fù)制模式，可以說是介于異步和同步之間的一種復(fù)制模式，主庫在執(zhí)行完客戶端提交的事務(wù)后，要等待至少一個從庫接收到binlog并將數(shù)據(jù)寫入到relay log中才返回給客戶端成功結(jié)果。半同步復(fù)制模式，比異步模式提高了數(shù)據(jù)的可用性，但是也產(chǎn)生了一定的性能延遲，最少要一個TCP/IP連接的往返時間。
  

半同步復(fù)制模式，可以很明確的知道，在一個事務(wù)提交成功之后，此事務(wù)至少會存在于兩個地方一個是主庫一個是從庫中的某一個。主要原理是，在master的dump線程去通知從庫時，增加了一個ACK機制，也就是會確認(rèn)從庫是否收到事務(wù)的標(biāo)志碼，master的dump線程不但要發(fā)送binlog到從庫，還有負(fù)責(zé)接收slave的ACK。當(dāng)出現(xiàn)異常時，Slave沒有ACK事務(wù)，那么將自動降級為異步復(fù)制，直到異常修復(fù)后再自動變?yōu)榘胪綇?fù)制

MySQL半同步復(fù)制的流程如下：

半同步復(fù)制的隱患
半同步復(fù)制模式也存在一定的數(shù)據(jù)風(fēng)險，當(dāng)事務(wù)在主庫提交完后等待從庫ACK的過程中，如果Master宕機了，這個時候就會有兩種情況的問題。

• 事務(wù)還沒發(fā)送到Slave上：若事務(wù)還沒發(fā)送Slave上，客戶端在收到失敗結(jié)果后，會重新提交事務(wù)，因為重新提交的事務(wù)是在新的Master上執(zhí)行的，所以會執(zhí)行成功，后面若是之前的Master恢復(fù)后，會以Slave的身份加入到集群中，這個時候，之前的事務(wù)就會被執(zhí)行兩次，第一次是之前此臺機器作為Master的時候執(zhí)行的，第二次是做為Slave后從主庫中同步過來的。
• 事務(wù)已經(jīng)同步到Slave上：因為事務(wù)已經(jīng)同步到Slave了，所以當(dāng)客戶端收到失敗結(jié)果后，再次提交事務(wù)，你那么此事務(wù)就會再當(dāng)前Slave機器上執(zhí)行兩次。
  

為了解決上面的隱患，MySQL從5.7版本開始，增加了一種新的半同步方式。新的半同步方式的執(zhí)行過程是將“Storage Commit”這一步移動到了“Write Slave dump”后面。這樣保證了只有Slave的事務(wù)ACK后，才提交主庫事務(wù)。MySQL 5.7.2版本新增了一個參數(shù)來進(jìn)行配置：rpl_semi_sync_master_wait_point，此參數(shù)有兩個值可配置：

• AFTER_SYNC：參數(shù)值為AFTER_SYNC時，代表采用的是新的半同步復(fù)制方式。
• AFTER_COMMIT：代表采用的是之前的舊方式的半同步復(fù)制模式。

MySQL從5.7.2版本開始，默認(rèn)的半同步復(fù)制方式就是AFTER_SYNC方式了，但是方案不是萬能的，因為AFTER_SYNC方式是在事務(wù)同步到Slave后才提交主庫的事務(wù)的，若是當(dāng)主庫等待Slave同步成功的過程中Master掛了，這個Master事務(wù)提交就失敗了，客戶端也收到了事務(wù)執(zhí)行失敗的結(jié)果了，但是Slave上已經(jīng)將binLog的內(nèi)容寫到Relay Log里了，這個時候，Slave數(shù)據(jù)就會多了，但是多了數(shù)據(jù)一般問題不算嚴(yán)重，多了總比少了好。MySQL，在沒辦法解決分布式數(shù)據(jù)一致性問題的情況下，它能保證的是不丟數(shù)據(jù)，多了數(shù)據(jù)總比丟數(shù)據(jù)要好。

這里說幾個的半同步復(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ù)制，超時時間，單位毫秒，當(dāng)超過此時間后，自動切換為異步復(fù)制模式 
rpl_semi_sync_master_timeout
-- MySQL 5.7.3引入的，該變量設(shè)置主需要等待多少個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ù)制，此值也會變?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)的簡稱，GTID是由UUID+TransactionId組成的，UUID是單個MySQL實例的唯一標(biāo)識，在第一次啟動MySQL實例時會自動生成一個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ù)是從哪個實例上提交的，提交的第多少個事務(wù)。

來看一個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的工作原理

由于GTID在一組主從復(fù)制集群中的唯一性，從而保證了每個GTID的事務(wù)只在一個MySQL上執(zhí)行一次。 那么是怎么實現(xiàn)這種機制的呢？GTID的原理又是什么樣的呢？

當(dāng)從服務(wù)器連接主服務(wù)器時，把自己執(zhí)行過的GTID（Executed_Gtid_Set: 即已經(jīng)執(zhí)行的事務(wù)編碼）以及獲取到GTID（Retrieved_Gtid_Set: 即從庫已經(jīng)接收到主庫的事務(wù)編號）都傳給主服務(wù)器。主服務(wù)器會從服務(wù)器缺少的GTID以及對應(yīng)的transactionID都發(fā)送給從服務(wù)器，讓從服務(wù)器補全數(shù)據(jù)。當(dāng)主服務(wù)器宕機時，會找出同步數(shù)據(jù)最成功的那臺conf服務(wù)器，直接將它提升為主服務(wù)器。若是強制要求某一臺不是同步最成功的一臺從服務(wù)器為主，會先通過change命令到最成功的那臺服務(wù)器，將GTID進(jìn)行補全，然后再把強制要求的那臺機器提升為主。

主要數(shù)據(jù)同步機制可以分為這幾步：

• ==master更新數(shù)據(jù)時，在事務(wù)前生產(chǎn)GTID，一同記錄到binlog中。==
• ==slave端的i/o線程，將變更的binlog寫入到relay log中。==
• ==sql線程從relay log中獲取GTID，然后對比Slave端的binlog是否有記錄。==
• ==如果有記錄，說明該GTID的事務(wù)已經(jīng)執(zhí)行，slave會忽略該GTID。==
• ==如果沒有記錄，Slave會從relay log中執(zhí)行該GTID事務(wù)，并記錄到binlog。==
• ==在解析過程中，判斷是否有主鍵，如果沒有主鍵就使用二級索引，再沒有二級索引就掃描全表。==

初始結(jié)構(gòu)如下圖

通過上圖我們可以看出來，當(dāng)Master掛掉后，Slave-1執(zhí)行完了Master的事務(wù)，Slave-2延時一些，所以沒有執(zhí)行完Master的事務(wù)，這個時候提升Slave-1為主，Slave-2連接了新主（Slave-1）后，將最新的GTID傳給新主，然后Slave-1就從這個GTID的下一個GTID開始發(fā)送事務(wù)給Slave-2。這種自我尋找復(fù)制位置的模式減少事務(wù)丟失的可能性以及故障恢復(fù)的時間。

GTID的優(yōu)劣勢

通過上面的分析我們可以得出GTID的優(yōu)勢是：

• ==每一個事務(wù)對應(yīng)一個執(zhí)行ID，一個GTID在一個服務(wù)器上只會執(zhí)行一次;==
• ==GTID是用來代替?zhèn)鹘y(tǒng)復(fù)制的方法，GTID復(fù)制與普通復(fù)制模式的最大不同就是不需要指定二進(jìn)制文件名和位置;==
• ==減少手工干預(yù)和降低服務(wù)故障時間，當(dāng)主機掛了之后通過軟件從眾多的備機中提升一臺備機為主機;==

GTID的缺點也很明顯：

• ==首先不支持非事務(wù)的存儲引擎；==
• ==不支持create table ... select 語句復(fù)制(主庫直接報錯);(原理: 會生成兩個sql, 一個是DDL創(chuàng)建表SQL, 一個是insert into 插入數(shù)據(jù)的sql; 由于DDL會導(dǎo)致自動提交, 所以這個sql至少需要兩個GTID, 但是GTID模式下, 只能給這個sql生成一個GTID)==
• ==不允許一個SQL同時更新一個事務(wù)引擎表和非事務(wù)引擎表;==
• ==在一個MySQL復(fù)制群組中，要求全部開啟GTID或關(guān)閉GTID。==
• ==開啟GTID需要重啟 (mysql5.7除外);==
• ==開啟GTID后，就不再使用原來的傳統(tǒng)復(fù)制方式（不像半同步復(fù)制，半同步復(fù)制失敗后，可以降級到異步復(fù)制）;==
• ==對于create temporary table 和 drop temporary table語句不支持;==
• ==不支持sql_slave_skip_counter;==
  

其實GTID的這部分內(nèi)容挺多的，如果有想深入研究的可以去看看這篇文章。 最后說幾個開啟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     （可選）       #高可用切換，最好打開該功能

以上就是詳解MySQL的半同步的詳細(xì)內(nèi)容，更多關(guān)于MySQL的半同步的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論