5月11日，國(guó)內(nèi)數(shù)據(jù)庫(kù)技術(shù)盛會(huì)——2017第八屆中國(guó)數(shù)據(jù)庫(kù)技術(shù)大會(huì)(DTCC2017)拉開帷幕。本屆大會(huì)以“數(shù)據(jù)驅(qū)動(dòng) 價(jià)值發(fā)現(xiàn)”為主題，吸引5000多名IT數(shù)據(jù)庫(kù)人群、大數(shù)據(jù)從業(yè)人員、廣大互聯(lián)網(wǎng)人士。騰訊高級(jí)工程師、騰訊云布道師張青林進(jìn)行了題為《騰訊云CDB的核彈頭——TXSQL》主題演講。
在本次主題演講中，張青林主要從概覽、內(nèi)核研發(fā)、云上實(shí)踐、未來(lái)發(fā)展方向四個(gè)方面介紹了Tencent MySQL(TXSQL)在騰訊云發(fā)展過(guò)程中遇到的各種問(wèn)題，以及在解決這些問(wèn)題的過(guò)程中TXSQL內(nèi)核所做的一系列優(yōu)化，包括read_view優(yōu)化、Lock_log拆分、分布式token鎖、Redo log鎖拆分、Binlog限速等功能，從功能、性能和穩(wěn)定性上對(duì)TXSQL進(jìn)行深入的解析。
TXSQL內(nèi)核版本擁有更高的性能、更強(qiáng)的穩(wěn)定性，同時(shí)提供Oracle MySQL企業(yè)級(jí)版本才擁有的特性，對(duì)內(nèi)支持集團(tuán)內(nèi)部業(yè)務(wù)的發(fā)展，對(duì)外提供強(qiáng)有力的竟?fàn)幜?，大大提升了騰訊云在業(yè)界的影響力，贏得了客戶的信任與口碑，積極的推動(dòng)了騰訊云的快速發(fā)展。
TXSQL概覽
什么是TXSQL?為什么有TXSQL?
TXSQL是Tencent MySQL的簡(jiǎn)稱，是TEG基礎(chǔ)架構(gòu)部CDB(Cloud DataBase)團(tuán)隊(duì)在近十年發(fā)展過(guò)程中衍生出來(lái)的一個(gè)對(duì)MySQL內(nèi)核源碼深度定制、對(duì)官方MySQL版本進(jìn)行二次開發(fā)的項(xiàng)目。其主要目的是在保證線上穩(wěn)定性的同時(shí)，滿足業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)的各種需求。
TXSQL的服務(wù)對(duì)象是公司內(nèi)部用戶和騰訊云上小至數(shù)G大至數(shù)百T的外部客戶。TXSQL是支撐這些業(yè)務(wù)平穩(wěn)運(yùn)行的關(guān)鍵基石，促進(jìn)開源數(shù)據(jù)庫(kù)技術(shù)發(fā)展。
圖1
TXSQL內(nèi)核研發(fā)
TXSQL read view優(yōu)化
read view又稱讀視圖，用于存儲(chǔ)事務(wù)創(chuàng)建時(shí)的活躍事務(wù)集合。當(dāng)事務(wù)創(chuàng)建時(shí)，線程會(huì)對(duì)trx_sys上全局鎖，然后遍歷當(dāng)前活躍事務(wù)列表，將當(dāng)前活躍事務(wù)的ID存儲(chǔ)在數(shù)組中的同時(shí)，記錄最大事務(wù)low_limit_id&最小事務(wù) high_limit_id&最小序列化事務(wù)low_limit_no。
當(dāng)事務(wù)執(zhí)行時(shí)，凡是大于low_limit_id的數(shù)據(jù)對(duì)于事務(wù)是不可見的，凡是事務(wù)小于high_limit_id的數(shù)據(jù)都是可見的，事務(wù)ID是read_view數(shù)組中的某一個(gè)時(shí)也是不可見的;Purge thread在執(zhí)行Purge操作時(shí)，凡是小于low_limit_no的數(shù)據(jù)，都是可以被Purge的，read view是MySQL MVCC實(shí)現(xiàn)的基礎(chǔ)。
Redo log優(yōu)化背景
據(jù)介紹，MySQL有兩種很重要的Log，分別為redo log&binlog，前者是保證事務(wù)原子性操作所產(chǎn)生的日志，后者是主備數(shù)據(jù)同步所產(chǎn)生的同步日志。其中binlog在ordered_commit時(shí)進(jìn)行g(shù)roup commit,而redo log則是在事務(wù)提交的時(shí)候分別調(diào)用trx_prepare使redo log落地，導(dǎo)致log_sys->mutex竟?fàn)庉^為嚴(yán)重。
從crash recovery的邏輯來(lái)看，只要redo log早于binlog落地，就不會(huì)有數(shù)據(jù)問(wèn)題，因此在ordered_commit的第一階段時(shí)，TXSQL會(huì)收集各種引擎的最大redo log LSN，然后將小于該LSN的redo log落盤，從而提升寫性能。更詳細(xì)的分析與測(cè)試，可以參考bug#73202。
圖2
TXSQL redo log雙緩沖區(qū)
MySQL redo log是一個(gè)順序?qū)懙膯尉彌_區(qū)，log_sys->mutex鎖資源竟?fàn)幖ち?，在事?wù)落盤的過(guò)程中對(duì)LSN相關(guān)的讀、寫都被阻塞，為了解決 log_sys->mutex的鎖竟?fàn)巻?wèn)題，引入雙緩沖區(qū)機(jī)制&w_mutex鎖，在flush redo log 的過(guò)程中釋放log_sys->mutex，繼續(xù)持有l(wèi)og_sys->w_mutex，從而阻塞寫，不阻塞LSN相關(guān)的讀操作，flush完成后釋放w_mutex;從而提升并發(fā)性，提升性能。
圖3
TXSQL性能數(shù)據(jù)對(duì)比
讀性能數(shù)據(jù)對(duì)比
寫性能數(shù)據(jù)對(duì)比
讀寫混合數(shù)據(jù)對(duì)比
TXSQL功能開發(fā)
在TXSQL并行復(fù)制方面，MySQL并行復(fù)制存在的問(wèn)題：在實(shí)際的應(yīng)用環(huán)境中，實(shí)例中往往只有一個(gè) Database，導(dǎo)致 relay log 中的事務(wù)大部分會(huì)分到同一個(gè) worker 線程中，造成備庫(kù)的性能低下，當(dāng)主庫(kù)的性能超過(guò)備庫(kù)的單線程執(zhí)行的性能時(shí)，就會(huì)出現(xiàn)延遲，對(duì)只讀實(shí)例產(chǎn)生影響。
TXSQL并行復(fù)制存在的優(yōu)化
為了解決上述問(wèn)題，TXSQL 添加了另外一種分發(fā)方式，即基于表粒度的分發(fā)，為了實(shí)現(xiàn)基于表粒度的分發(fā)，TXSQL 對(duì)于不同的實(shí)現(xiàn)，進(jìn)行了不同的處理:
當(dāng)binlog_row_format= ROW 時(shí), 調(diào)用 get_slave_worker 直接進(jìn)行分發(fā);
當(dāng) binlog_row_format= statement 時(shí)，則需要對(duì)語(yǔ)句先進(jìn)行調(diào)用 mysql_parse 對(duì)語(yǔ)句進(jìn)行解析，然后再做分發(fā)。
TXSQL強(qiáng)同步支持
原生 semi-sync 存在著以下問(wèn)題：
semi-sync 在時(shí)間超過(guò) rpl_semi_sync_master_timeout 會(huì)退化為異步;
采用 select 進(jìn)行監(jiān)聽，當(dāng)句柄值大于 1024 時(shí)則會(huì)出現(xiàn)異常，詳情可參考 bug#79865;
在 after commit 后等待 ACK 容易出現(xiàn)幻讀的問(wèn)題;
TXSQL 強(qiáng)同步支持：
優(yōu)化半同步，增加ack線程，收發(fā)并行化;
修正select時(shí)fd超過(guò)1024導(dǎo)致異常的bug，改為poll;
在半同步基礎(chǔ)上實(shí)現(xiàn)強(qiáng)同步，一直hold住直到收到ack;
修改同步方式時(shí)，喚醒正在等待的用戶線程，繼續(xù)等待或者退出;
增加一些狀態(tài)，用于展示當(dāng)前等待的情況(正在等待的binlog位點(diǎn)，已等待時(shí)間);
對(duì)于主多 binlog 備少 binlog 的情況進(jìn)行特殊的處理，以保證雙寫的情況不會(huì)發(fā)生;
TXSQL云上實(shí)踐
XX游戲數(shù)據(jù)庫(kù)優(yōu)化案例
問(wèn)題現(xiàn)象：性能不能滿足業(yè)務(wù)要求，游戲業(yè)務(wù)邏輯 TPS 不達(dá)標(biāo);在壓力達(dá)到一定程度時(shí)，CPU 不能充分利用，idle 較高;性能抖動(dòng)較為明顯; thread running 過(guò)高，系統(tǒng)負(fù)載較高;系統(tǒng) IO 壓力較小，IO 沒有問(wèn)題;
問(wèn)題排查：
pt-pmp & pstack & mysql 命令進(jìn)行問(wèn)題排查，發(fā)現(xiàn)以下問(wèn)題：
1.應(yīng)用在執(zhí)行SQL語(yǔ)句的過(guò)程中，table_cache_manager 中的鎖沖突比較嚴(yán)重; 2.MySQL Server 層中的 MDL_lock 沖突比較重; 3.實(shí)例開啟了 Performance_schema 功能; 4.事務(wù)鎖 trx_sys->mutx 沖突較高;
調(diào)優(yōu)過(guò)程：
根據(jù)已經(jīng)查找出來(lái)的問(wèn)題，調(diào)整相應(yīng)參數(shù)與版本并重啟，效果如下圖所示：
1.table_open_cache_instances= 32 2.metadata_locks_hash_instances= 32 3.performance_schema= OFF 4.其它
最后，張青林針對(duì)今天的演講做了精簡(jiǎn)的總結(jié)，列出的數(shù)據(jù)庫(kù)問(wèn)題如下：在壓力達(dá)到一定程度時(shí)，CPU 不能充分利用，idle 較高; 性能抖動(dòng)明顯; 并發(fā)過(guò)大引起的 thread running 過(guò)高，系統(tǒng)負(fù)載較高; IO 問(wèn)題引起的性能抖動(dòng); 鎖問(wèn)題導(dǎo)致的性能抖動(dòng); 壓力不夠大或者壓力不均勻; 優(yōu)化器問(wèn)題引起的執(zhí)行計(jì)劃出錯(cuò); SQL 語(yǔ)句引起的異常; 參數(shù)配置的不合理; 內(nèi)核 Bug; 網(wǎng)絡(luò)問(wèn)題。
在未來(lái)的發(fā)展過(guò)程中TXSQL仍然會(huì)以用戶為導(dǎo)向從以下方面不斷的進(jìn)行改進(jìn)：批量計(jì)算;執(zhí)行計(jì)劃緩存;XA 三階段支持;基于binlog的深度優(yōu)化;Innodb的持續(xù)優(yōu)化;引入oracle企業(yè)級(jí)特性。
