MySQL的半同步是什麼？

紀莫發表於2021-04-22
MySql

前言

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

MySQL的主從複製

我們的一般在大規模的專案上，都是使用MySQL的複製功能來建立MySQL的主從叢集的。主要是可以通過為伺服器配置一個或多個備庫的方式來進行資料同步。複製的功能不僅有利於構建高效能應用，同時也是高可用、可擴充套件性、災難恢復、備份以及資料倉儲等工作的基礎。

說的通俗一點，通過MySQL的主從複製來實現讀寫分離，相比單點資料庫又讀又寫來說，提升了業務系統效能，優化了使用者體驗。另外通過主從複製實現了資料庫的高可用，當主節點MySQL掛了的時候，可以用從庫來頂上。

MySQL支援的複製方式

MySQL支援三種複製方式：

  • 基於語句的複製（也稱為邏輯複製）主要是指，在主資料庫上執行的SQL語句，在從資料庫上會重複執行一遍。MySQL預設採用的就是這種複製，效率比較高。但是也是有一定的問題的，如果SQL中使用uuid()、rand()等函式，那麼複製到從庫的資料就會有偏差。
  • 基於行的複製，指將更新處理後的資料複製到從資料庫，而不是執行一邊語句。從MySQL5.1的版本才被支援。
  • 混合複製，預設採用語句複製，當發現語句不能進行精準複製資料時（例如語句中含有uuid()、rand()等函式），採用基於行的複製。

主從複製原理

MySQL的複製原理概述上來講大體可以分為這三步

  1. 在主庫上把資料更改，記錄到二進位制日誌（Binary Log）中。
  2. 從庫將主庫上的日誌複製到自己的中繼日誌（Relay Log）中。
  3. 備庫讀取中繼日誌中的事件，將其重放到備庫資料之上。

主要過程如下圖：
MySQL複製過程
下面來詳細說一下複製的這三步：

第一步：是在主庫上記錄二進位制日誌，首先主庫要開啟binlog日誌記錄功能，並授權Slave從庫可以訪問的許可權。這裡需要注意的一點就是binlog的日誌裡的順序是按照事務提交的順序來記錄的而非每條語句的執行順序。

第二步：從庫將binLog複製到其本地的RelayLog中。首先從庫會啟動一個工作執行緒，稱為I/O執行緒，I/O執行緒跟主庫建立一個普通的客戶端連線，然後主庫上啟動一個特殊的二進位制轉儲（binlog dump）執行緒，此轉儲執行緒會讀取binlog中的事件。當追趕上主庫後，會進行休眠，直到主庫通知有新的更新語句時才繼續被喚醒。
這樣通過從庫上的I/O執行緒和主庫上的binlog dump執行緒，就將binlog資料傳輸到從庫上的relaylog中了。

第三步：從庫中啟動一個SQL執行緒，從relaylog中讀取事件並在備庫中執行，從而實現備庫資料的更新。

這種複製架構實現了獲取事件和重放事件的解耦，執行I/O執行緒能夠獨立於SQL執行緒之外工作。但是這種架構也限制複製的過程，最重要的一點是在主庫上併發執行的查詢在備庫中只能序列化執行，因為只有一個SQL執行緒來重放中繼日誌中的事件。

說到這個主從複製的序列化執行的問題，我就想到了一個之前在工作中遇到的一個問題，就是有這麼一個業務場景，我們有一個操作是初始化一批資料，資料是從一個外部系統的介面中獲取的，然後我是通過執行緒池裡的多個執行緒並行從外部系統的介面中獲取資料，每個執行緒獲取到資料後，直接插入到資料庫中。然後在資料全部入庫完成後，然後去執行批量查詢，將剛插入到資料庫中的資料查詢出來，放到ElasticSearch中。結果每次放入到ES中的資料總是不完整，後來研究了半天都不行，最終是讓查詢也走的主庫才解決的問題。當時不知道是MySQL主從複製的序列化從而導致的這個問題。

MySQL主從複製模式

MySQL的主從複製其實是支援，非同步複製、半同步複製、GTID複製等多種複製模式的。

非同步模式

MySQL的預設複製模式就是非同步模式，主要是指MySQL的主伺服器上的I/O執行緒，將資料寫到binlong中就直接返回給客戶端資料更新成功，不考慮資料是否傳輸到從伺服器，以及是否寫入到relaylog中。在這種模式下，複製資料其實是有風險的，一旦資料只寫到了主庫的binlog中還沒來得急同步到從庫時，就會造成資料的丟失。

但是這種模式確也是效率最高的，因為變更資料的功能都只是在主庫中完成就可以了，從庫複製資料不會影響到主庫的寫資料操作。
非同步複製
上面我也說了，這種非同步複製模式雖然效率高，但是資料丟失的風險很大，所以就有了後面要介紹的半同步複製模式。

半同步模式

MySQL從5.5版本開始通過以外掛的形式開始支援半同步的主從複製模式。什麼是半同步主從複製模式呢？
這裡通過對比的方式來說明一下：

  • 非同步複製模式：上面我們已經介紹了，非同步複製模式，主庫在執行完客戶端提交的事務後，只要將執行邏輯寫入到binlog後，就立即返回給客戶端，並不關心從庫是否執行成功，這樣就會有一個隱患，就是在主庫執行的binlog還沒同步到從庫時，主庫掛了，這個時候從庫就就會被強行提升為主庫，這個時候就有可能造成資料丟失。
  • 同步複製模式：當主庫執行完客戶端提交的事務後，需要等到所有從庫也都執行完這一事務後，才返回給客戶端執行成功。因為要等到所有從庫都執行完，執行過程中會被阻塞，等待返回結果，所以效能上會有很嚴重的影響。
  • 半同步複製模式：半同步複製模式，可以說是介於非同步和同步之間的一種複製模式，主庫在執行完客戶端提交的事務後，要等待至少一個從庫接收到binlog並將資料寫入到relay log中才返回給客戶端成功結果。半同步複製模式，比非同步模式提高了資料的可用性，但是也產生了一定的效能延遲，最少要一個TCP/IP連線的往返時間。

半同步複製模式，可以很明確的知道，在一個事務提交成功之後，此事務至少會存在於兩個地方一個是主庫一個是從庫中的某一個。主要原理是，在master的dump執行緒去通知從庫時，增加了一個ACK機制，也就是會確認從庫是否收到事務的標誌碼，master的dump執行緒不但要傳送binlog到從庫，還有負責接收slave的ACK。當出現異常時，Slave沒有ACK事務，那麼將自動降級為非同步複製，直到異常修復後再自動變為半同步複製

MySQL半同步複製的流程如下：

MySQL 半同步複製模式

半同步複製的隱患

半同步複製模式也存在一定的資料風險，當事務在主庫提交完後等待從庫ACK的過程中，如果Master當機了，這個時候就會有兩種情況的問題。

  • 事務還沒傳送到Slave上：若事務還沒傳送Slave上，客戶端在收到失敗結果後，會重新提交事務，因為重新提交的事務是在新的Master上執行的，所以會執行成功，後面若是之前的Master恢復後，會以Slave的身份加入到叢集中，這個時候，之前的事務就會被執行兩次，第一次是之前此臺機器作為Master的時候執行的，第二次是做為Slave後從主庫中同步過來的。
  • 事務已經同步到Slave上：因為事務已經同步到Slave了，所以當客戶端收到失敗結果後，再次提交事務，你那麼此事務就會再當前Slave機器上執行兩次。

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

  • AFTER_SYNC：引數值為AFTER_SYNC時，代表採用的是新的半同步複製方式。
  • AFTER_COMMIT：代表採用的是之前的舊方式的半同步複製模式。

新的半同步複製
MySQL從5.7.2版本開始，預設的半同步複製方式就是AFTER_SYNC方式了，但是方案不是萬能的，因為AFTER_SYNC方式是在事務同步到Slave後才提交主庫的事務的，若是當主庫等待Slave同步成功的過程中Master掛了，這個Master事務提交就失敗了，客戶端也收到了事務執行失敗的結果了，但是Slave上已經將binLog的內容寫到Relay Log裡了，這個時候，Slave資料就會多了，但是多了資料一般問題不算嚴重，多了總比少了好。MySQL，在沒辦法解決分散式資料一致性問題的情況下，它能保證的是不丟資料，多了資料總比丟資料要好。

這裡說幾個的半同步複製模式的引數：

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   |
+-------------------------------------------+------------+

-- 半同步複製模式開關
rpl_semi_sync_master_enabled
-- 半同步複製，超時時間，單位毫秒，當超過此時間後，自動切換為非同步複製模式 
rpl_semi_sync_master_timeout
-- MySQL 5.7.3引入的，該變數設定主需要等待多少個slave應答，才能返回給客戶端，預設為1。
rpl_semi_sync_master_wait_for_slave_count
-- 此值代表當前叢集中的slave數量是否還能夠滿足當前配置的半同步複製模式，預設為ON，當不滿足半同步複製模式後，全部Slave切換到非同步複製，此值也會變為OFF
rpl_semi_sync_master_wait_no_slave
-- 代表半同步複製提交事務的方式，5.7.2之後，預設為AFTER_SYNC
rpl_semi_sync_master_wait_point
GTID模式

MySQL從5.6版本開始推出了GTID複製模式，GTID即全域性事務ID (global transaction identifier)的簡稱，GTID是由UUID+TransactionId組成的，UUID是單個MySQL例項的唯一標識，在第一次啟動MySQL例項時會自動生成一個server_uuid, 並且預設寫入到資料目錄下的auto.cnf(mysql/data/auto.cnf)檔案裡。TransactionId是該MySQL上執行事務的數量，隨著事務數量增加而遞增。這樣保證了GTID在一組複製中，全域性唯一。

這樣通過GTID可以清晰的看到，當前事務是從哪個例項上提交的，提交的第多少個事務。

來看一個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在一組主從複製叢集中的唯一性，從而保證了每個GTID的事務只在一個MySQL上執行一次。
那麼是怎麼實現這種機制的呢？GTID的原理又是什麼樣的呢？

當從伺服器連線主伺服器時，把自己執行過的GTID（Executed_Gtid_Set: 即已經執行的事務編碼）以及獲取到GTID（Retrieved_Gtid_Set: 即從庫已經接收到主庫的事務編號）都傳給主伺服器。主伺服器會從伺服器缺少的GTID以及對應的transactionID都傳送給從伺服器，讓從伺服器補全資料。當主伺服器當機時，會找出同步資料最成功的那臺conf伺服器，直接將它提升為主伺服器。若是強制要求某一臺不是同步最成功的一臺從伺服器為主，會先通過change命令到最成功的那臺伺服器，將GTID進行補全，然後再把強制要求的那臺機器提升為主。

主要資料同步機制可以分為這幾步：

  • master更新資料時，在事務前生產GTID，一同記錄到binlog中。
  • slave端的i/o執行緒，將變更的binlog寫入到relay log中。
  • sql執行緒從relay log中獲取GTID，然後對比Slave端的binlog是否有記錄。
  • 如果有記錄，說明該GTID的事務已經執行，slave會忽略該GTID。
  • 如果沒有記錄，Slave會從relay log中執行該GTID事務，並記錄到binlog。
  • 在解析過程中，判斷是否有主鍵，如果沒有主鍵就使用二級索引，再沒有二級索引就掃描全表。

初始結構如下圖
GTID
當Master出現當機後，就會演變成下圖。
GTID複製
通過上圖我們可以看出來，當Master掛掉後，Slave-1執行完了Master的事務，Slave-2延時一些，所以沒有執行完Master的事務，這個時候提升Slave-1為主，Slave-2連線了新主（Slave-1）後，將最新的GTID傳給新主，然後Slave-1就從這個GTID的下一個GTID開始傳送事務給Slave-2。這種自我尋找複製位置的模式減少事務丟失的可能性以及故障恢復的時間。

GTID的優劣勢

通過上面的分析我們可以得出GTID的優勢是：

  • 每一個事務對應一個執行ID，一個GTID在一個伺服器上只會執行一次;
  • GTID是用來代替傳統複製的方法，GTID複製與普通複製模式的最大不同就是不需要指定二進位制檔名和位置;
  • 減少手工干預和降低服務故障時間，當主機掛了之後通過軟體從眾多的備機中提升一臺備機為主機;

GTID的缺點也很明顯：

  • 首先不支援非事務的儲存引擎；
  • 不支援create table ... select 語句複製(主庫直接報錯);(原理: 會生成兩個sql, 一個是DDL建立表SQL, 一個是insert into 插入資料的sql; 由於DDL會導致自動提交, 所以這個sql至少需要兩個GTID, 但是GTID模式下, 只能給這個sql生成一個GTID)
  • 不允許一個SQL同時更新一個事務引擎表和非事務引擎表;
  • 在一個MySQL複製群組中，要求全部開啟GTID或關閉GTID。
  • 開啟GTID需要重啟 (mysql5.7除外);
  • 開啟GTID後，就不再使用原來的傳統複製方式（不像半同步複製，半同步複製失敗後，可以降級到非同步複製）;
  • 對於create temporary table 和 drop temporary table語句不支援;
  • 不支援sql_slave_skip_counter;

其實GTID的這部分內容挺多的，如果有想深入研究的可以去看看這篇文章。
最後說幾個開啟GTID的必備條件：

  • MySQL 5.6 版本，在my.cnf檔案中新增:
gtid_mode=on (必選)                    #開啟gtid功能
log_bin=log-bin=mysql-bin (必選)       #開啟binlog二進位制日誌功能
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》
MySQL 基於GTID複製模式

相關文章