近日，騰訊云CDB迎來MySQL 5. 7 版本的更新。MySQL 5.7GA版本從5.7. 9 到如今的5.7.18，版本已經(jīng)越來越不變。從oracle官方版本發(fā)布的Release Notes中，看到比來的兩個版本5.7. 17 和5.7. 18 主要是以bug修改為主。

眾所周知，騰訊云CDB for MySQL5. 7 版本除了性能的極大提升之外，也增加了很多新功能特性，好比GIS數(shù)據(jù)類型和空間索引，Json數(shù)據(jù)類型，Generated colum以及函數(shù)索引, 數(shù)據(jù)加密，還有Group Relication等等重磅功能。

而騰訊云上已經(jīng)有用戶需要用到上述的一些功能，，所以也是從本年四月份就開始做TXSQL 5.7(TXSQL是騰訊云數(shù)據(jù)庫團(tuán)隊(duì)維護(hù)的MySQL內(nèi)核分支)的版本，并在四月底提交了版本進(jìn)行測試。本次，騰訊云的TXSQL 5. 7 是基于MySQL 5.7. 18 版本。

目前騰訊云TXSQL 5. 7 的第一版，在復(fù)制強(qiáng)制一致、自動轉(zhuǎn)換MyISAM表為InnoDB表、增加差別的工作模式等方面有著非常重大的突破。

1. 復(fù)制強(qiáng)制一致

了解的人都知道，在MySQL的semisync設(shè)有超時機(jī)制，配置參數(shù)為rpl_semi_sync_master_timeout。一旦master在設(shè)定的時間內(nèi)沒有比及slave的確認(rèn)(好比網(wǎng)絡(luò)故障)，semisync就會關(guān)閉，主動降級為默認(rèn)的異步復(fù)制模式。異步復(fù)制模式最大的問題就是master不消等待slave的確認(rèn)。那么當(dāng)master掛掉的時候，切換到slave，就存在丟數(shù)據(jù)的可能。

針對數(shù)據(jù)可能丟失這一點(diǎn)，騰訊云在TXSQL 5. 7 增加了一個新的選項(xiàng)rpl_semi_sync_wait_forever。在其為ON的時候，master會一直等待slave的確認(rèn)。如果長時間等不到確認(rèn)，系統(tǒng)告警，這時候可以設(shè)置rpl_semi_sync_wait_forever為OFF，來喚醒master中的等待線程，同時將semisync降級為異步模式。在這種情況下，如果master在最終收到slave確認(rèn)，并且slave追趕到最新的binglog后會自動開啟semisync。

11. 方案設(shè)計

(1) 設(shè)置rpl_semi_sync_master_timeout到一個無限大的值

這樣可以實(shí)現(xiàn)master一直等待，但是當(dāng)想回到正常的timeout模式時，我們需要記住之前的rpl_semi_sync_master_timeout的設(shè)置值。這樣可能需要加一個系統(tǒng)的狀態(tài)變量來生存這個值。別的，這樣會導(dǎo)致在處理rpl_semi_sync_master_timeout值變革時的邏輯變復(fù)雜。

(2) 增加新變量rpl_semi_sync_wait_forever

既然在上一種方案需要一個新的狀態(tài)變量，騰訊云就直接增加一個變量來作為一直等待的開關(guān)。在rpl_semi_sync_wait_forever為ON的時候，master會一直等待slave的確認(rèn)。如果長時間等不到確認(rèn)，系統(tǒng)告警，則可以設(shè)置rpl_semi_sync_wait_forever為OFF，來喚醒master中的等待線程，同時將semisync降級為異步模式。在這種情況下，如果master在最終收到slave確認(rèn)，并且slave追趕到最新的binglog后會自動開啟semisync。

(3)基于paxos的semisync

MySQL5. 7 中支持rpl_semi_sync_master_wait_for_slave_count，但在某一個slave沒有在rpl_semi_sync_master_timeout時間內(nèi)返回確認(rèn)，即即是master比及了rpl_semi_sync_master_wait_for_slave_count個slave的確認(rèn)，master還是會從semisync降級到異步模式。在semisync中支持paxos協(xié)議會從根本上解決這個問題，實(shí)現(xiàn)真正意義上的強(qiáng)一致。

目前，騰訊云選擇的為(2)方案，這主要是因?yàn)?，現(xiàn)網(wǎng)實(shí)例中基本都是一主一備，(3)的方案比較重，(2)的實(shí)現(xiàn)明顯優(yōu)于(1)。方案(3)適合對強(qiáng)一致要求更高的應(yīng)用場景，目前，騰訊云已經(jīng)列入開發(fā)計劃，預(yù)計下半年推出。

1.2 實(shí)現(xiàn)原理

(1) 設(shè)置rpl_semi_sync_wait_forever為ON之后

a. 新進(jìn)來的事務(wù)需要一直等待。

b. 之前老的事務(wù)如果發(fā)生超時，需要繼續(xù)等待。

因?yàn)槿绻脩粼O(shè)置為ON之后，預(yù)期是不會發(fā)生超時。

(2)設(shè)置rpl_semi_sync_wait_forever為OFF

如果此時有一直在等待的事務(wù)，要喚醒。最初的方案是

signal_waiting_sessions_all()來喚醒這些事務(wù)，然后如果事務(wù)等待的時間超過了rpl_semi_sync_master_timeout，降級為異步模式。如果等待的時間wait_time < rpl_semi_sync_master_timeout，那么繼續(xù)等待rpl_semi_sync_master_timeout - wait_time。但是通過sysbench壓測發(fā)現(xiàn)這樣的方案會導(dǎo)致死鎖，。

所以最終的簡化方案是：

1.3 新增狀態(tài)

2. 自動轉(zhuǎn)換MyISAM表為InnoDB表

MyISAM表因?yàn)椴恢С质聞?wù)，所以存在故障恢復(fù)丟數(shù)據(jù)的可能。在復(fù)制環(huán)境下，如果使用MyISAM表，master和slave就可能出現(xiàn)紛歧致情況。即使騰訊云強(qiáng)烈建議用戶只使用InnoDB表，但是還是無法制止用戶在某些情況仍然去使用MyISAM表。為了解決這個問題，騰訊云提供了新的選項(xiàng)，在建表的時候默認(rèn)將MyISAM表轉(zhuǎn)為InnoDB表。

新增變量

可選值

由于InnoDB內(nèi)部的一些限制，會導(dǎo)致有些情況下轉(zhuǎn)換失敗。

(1) auto-increment

在InnoDB中只允許定義一個自增列，而且這個列必需被定義為主鍵。在MyISAM中則無此限制。

(2) max key length

在InnoDB中，innodb_large_prefix關(guān)閉的情況下，max key length不能大于767，而在MyISAM中，則不能大于1000。

(3) row format

在InnoDB中，innodb_strict_mode開啟的情況下，row format FIXED是不支持的。

3. 增加差別的工作模式

除了復(fù)制強(qiáng)制一致、自動轉(zhuǎn)換MyISAM表為InnoDB表，這兩項(xiàng)功能的實(shí)現(xiàn)以外，在TXSQL 5. 7 中，騰訊云還為其增加了READ_ONLY模式。