【干貨】騰訊云CDB屬性升級，TXSQL 5.7實(shí)現真正復

近日，騰訊云CDB迎來(lái)MySQL 5.7版本的更新。MySQL 5.7GA版本從5.7.9到如今的5.7.18，版本已經(jīng)越來(lái)越穩定。從oracle官方版本發(fā)布的Release Notes中，看到最近的兩個(gè)版本5.7.17和5.7.18主要是以bug修改為主。

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

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

目前騰訊云TXSQL 5.7的第一版，在復制強制一致、自動(dòng)轉換MyISAM表為InnoDB表、增加不同的工作模式等方面有著(zhù)非常重大的突破。

1. 復制強制一致

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

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

11. 方案設計

(1) 設置rpl_semi_sync_master_timeout到一個(gè)無(wú)限大的值

這樣可以實(shí)現master一直等待，但是當想回到正常的timeout模式時(shí)，我們需要記住之前的rpl_semi_sync_master_timeout的設置值。這樣可能需要加一個(gè)系統的狀態(tài)變量來(lái)保存這個(gè)值。另外，這樣會(huì )導致在處理rpl_semi_sync_master_timeout值變化時(shí)的邏輯變復雜。

(2) 增加新變量rpl_semi_sync_wait_forever

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

(3)基于paxos的semisync

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

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

1.2 實(shí)現原理

(1) 設置rpl_semi_sync_wait_forever為ON之后

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

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

因為如果用戶(hù)設置為ON之后，預期是不會(huì )發(fā)生超時(shí)。

(2)設置rpl_semi_sync_wait_forever為OFF

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

signal_waiting_sessions_all()來(lái)喚醒這些事務(wù)，然后如果事務(wù)等待的時(shí)間超過(guò)了rpl_semi_sync_master_timeout，降級為異步模式。如果等待的時(shí)間wait_time < rpl_semi_sync_master_timeout，那么繼續等待rpl_semi_sync_master_timeout - wait_time。但是通過(guò)sysbench壓測發(fā)現這樣的方案會(huì )導致死鎖，。

所以最終的簡(jiǎn)化方案是：

1.3 新增狀態(tài)

2. 自動(dòng)轉換MyISAM表為InnoDB表

MyISAM表因為不支持事務(wù)，所以存在故障恢復丟數據的可能。在復制環(huán)境下，如果使用MyISAM表，master和slave就可能出現不一致情況。即使騰訊云強烈建議用戶(hù)只使用InnoDB表，但是還是無(wú)法避免用戶(hù)在某些情況仍然去使用MyISAM表。為了解決這個(gè)問(wèn)題，騰訊云提供了新的選項，在建表的時(shí)候默認將MyISAM表轉為InnoDB表。

新增變量

可選值

由于InnoDB內部的一些限制，會(huì )導致有些情況下轉換失敗。

(1) auto-increment

在InnoDB中只允許定義一個(gè)自增列，并且這個(gè)列必須被定義為主鍵。在MyISAM中則無(wú)此限制。

(2) max key length

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

(3) row format

在InnoDB中，innodb_strict_mode開(kāi)啟的情況下，row format FIXED是不支持的。

3. 增加不同的工作模式

除了復制強制一致、自動(dòng)轉換MyISAM表為InnoDB表，這兩項功能的實(shí)現以外，在TXSQL 5.7中，騰訊云還為其增加了READ_ONLY模式。

眾所周知，MySQL 5.7中增加了一個(gè)新的參數offline_mode(WL#3836)，設置此參數為OFF，server拒絕對外服務(wù)，root用戶(hù)可以對系統進(jìn)行診斷操作或升級操作等。在TXSQL 5.7中增加了READ_ONLY模式，不同的工作模式，將會(huì )實(shí)現更多的功能。

目前，這只是騰訊云TXSQL 5.7的第一個(gè)版本，從總體功能來(lái)看，這些已經(jīng)實(shí)現的功能，都相對來(lái)說(shuō)非常的人性化和實(shí)用。這也將進(jìn)一步促進(jìn)騰訊云CDB的功能實(shí)現全面突破和領(lǐng)先。