攜程MySQL遷移OceanBase最佳實(shí)踐

作者：CtripDBA 2023-02-08 16:34:05

OceanBase作為分布式數(shù)據(jù)庫(kù)，組件多、運(yùn)維環(huán)境復(fù)雜是痛點(diǎn)。我們后續(xù)將基于現(xiàn)有的日志收集工具和分析工具，完成鏈路式的問題診斷，更精準(zhǔn)地定位性能問題、集群內(nèi)部任務(wù)問題等。

一、前言

MySQL在業(yè)界流行多年，很好地支撐了攜程的業(yè)務(wù)發(fā)展。但隨著技術(shù)多元化及業(yè)務(wù)的不斷發(fā)展，MySQL也遇到了新的挑戰(zhàn)，主要體現(xiàn)在：業(yè)務(wù)數(shù)據(jù)模型呈現(xiàn)多元化，OLTP和OLAP出現(xiàn)融合的趨勢(shì)；在MySQL數(shù)據(jù)庫(kù)上慢查詢治理成本高；使用傳統(tǒng)的分庫(kù)分表方案對(duì)開發(fā)不友好，核心數(shù)據(jù)庫(kù)改造成分庫(kù)分表方案，時(shí)間一般以年為單位。

分布式數(shù)據(jù)庫(kù)能比較好地解決上述問題，同時(shí)也帶來了新的挑戰(zhàn)。2021年，OceanBase（簡(jiǎn)稱OB）開源，攜程開始逐步探索OceanBase的基本特性和應(yīng)用場(chǎng)景。OceanBase兼容大部分MySQL的功能和語(yǔ)法，同時(shí)提供水平擴(kuò)展性、強(qiáng)一致性和高可用性，能滿足業(yè)務(wù)需求并降低運(yùn)維成本。因此，我們開始推進(jìn)部分MySQL實(shí)例遷移到OB。為保證遷移順暢，我們?cè)O(shè)計(jì)了遷移評(píng)估工具、OB遷移流程、OB監(jiān)控大盤和OB故障診斷工具等。并將遷移過程中遇到的問題和大家進(jìn)行分享。

二、評(píng)估工具

平滑遷移異構(gòu)數(shù)據(jù)庫(kù)，我們需要進(jìn)行兼容性、性能和分區(qū)適應(yīng)性等各項(xiàng)檢查。提前把不兼容或有可能引起遷移異常的場(chǎng)景找出來并解決。官方提供了OceanBase Migration Assessment(OMA)工具，用于異構(gòu)數(shù)據(jù)庫(kù)遷移到OB的可行性評(píng)估。遷移評(píng)估工具OMA有語(yǔ)法兼容性檢查和性能評(píng)估，但還不能完全滿足我們的需求。主要體現(xiàn)在下面幾點(diǎn):

中間件版本檢查，一個(gè)DB有多個(gè)應(yīng)用在訪問，只有某個(gè)版本后的中間件才開始支持OceanBase，需要檢查訪問該DB的所有應(yīng)用的中間件版本，并督促開發(fā)進(jìn)行升級(jí)，以確保都在支持OB版本之上。
性能采集和回放提供的MySQL General Log采集模式有一定風(fēng)險(xiǎn)，尤其是對(duì)于業(yè)務(wù)繁重的數(shù)據(jù)庫(kù)，我們需要更平滑的性能采集和回放方案。另外對(duì)于單實(shí)例多DB場(chǎng)景，存在遷移和不遷移的DB共存的情況，需要進(jìn)行過濾。
線上存在非通過中間件訪問的數(shù)據(jù)庫(kù)賬號(hào)，如ETL取數(shù)賬號(hào)、數(shù)據(jù)查詢工具賬號(hào)、應(yīng)用直連賬號(hào)等，對(duì)其兼容性需要進(jìn)行檢查。因?yàn)檫w移到OB之后，數(shù)據(jù)庫(kù)登錄賬號(hào)需要進(jìn)行改變，包含租戶信息。
OceanBase是分布式數(shù)據(jù)庫(kù)，數(shù)據(jù)如何進(jìn)行分區(qū)就顯得非常重要，以避免形成熱點(diǎn)數(shù)據(jù)。一張表可能有多個(gè)字段都適合作為分區(qū)鍵，在遷移工具中，根據(jù)數(shù)據(jù)分布以及訪問情況，需要提供表分區(qū)推薦，以減少遷移成本。

因此我們對(duì)OMA評(píng)估工具進(jìn)行了拓展和改造。在不影響現(xiàn)有的數(shù)據(jù)庫(kù)運(yùn)行下，省去中間環(huán)節(jié)，做到一鍵評(píng)估。其中MySQL數(shù)據(jù)采集與分析大致流程示意圖如下，全量數(shù)據(jù)導(dǎo)入OceanBase后，目標(biāo)端我們用開源Locust工具，進(jìn)行SQL回放和壓測(cè)，并最終形成評(píng)估報(bào)告。

三、遷移流程

在評(píng)估流程完成并且評(píng)估結(jié)果符合遷移要求的前提下，可以發(fā)起MySQL到OceanBase自動(dòng)遷移流程。為減少遷移成本，我們把遷移流程進(jìn)行了封裝，做到一鍵自動(dòng)遷移，自動(dòng)切換包含以下流程：

1）遷移前配置校驗(yàn)。遷移前，會(huì)集中對(duì)所有的切換注意事項(xiàng)和相關(guān)配置再進(jìn)行一次全面的檢查，提前排除配置問題可能導(dǎo)致的切換風(fēng)險(xiǎn)。

2）MySQL賬號(hào)兼容OceanBase帶租戶賬號(hào)創(chuàng)建。由于OceanBase是多租戶管理模式，應(yīng)用的連接串必須指定租戶名，因此相應(yīng)賬號(hào)需要在目標(biāo)OB集群預(yù)先創(chuàng)建，中間件或工具切換賬號(hào)時(shí)，只需重置連接并切換到新賬號(hào)即可。

3）數(shù)據(jù)一致性校驗(yàn)。數(shù)據(jù)通過Canal從MySQL同步到OB后，我們需要對(duì)一致性做校驗(yàn)。校驗(yàn)的方法是根據(jù)表主鍵進(jìn)行切分，進(jìn)行結(jié)果集比較是否一致。當(dāng)遇到熱點(diǎn)表時(shí)，數(shù)據(jù)校驗(yàn)過程會(huì)發(fā)起多次嘗試來反復(fù)驗(yàn)證。

4）DDL表結(jié)構(gòu)修改暫停。由于MySQL和OceanBase表結(jié)構(gòu)變更方式差異較大，當(dāng)DB遷移從MySQL到OceanBase觸發(fā)流程后，我們會(huì)在源MySQL禁止DDL操作。當(dāng)然，如果開發(fā)有緊急發(fā)布需求，我們可以廢棄流程，等DDL發(fā)布完成后，再重啟遷移流程。

5）反向同步鏈路搭建。無論前面的遷移評(píng)估或者流程多么完善，反向同步鏈路對(duì)于異構(gòu)數(shù)據(jù)庫(kù)的遷移是必備的。一旦遷移出現(xiàn)異常，可以快速回退。反向同步鏈路是基于OceanBase的CDC服務(wù)，訂閱增量日志在MySQL端回放，保證遷移后OceanBase側(cè)和MySQL側(cè)數(shù)據(jù)始終一致。

當(dāng)數(shù)據(jù)同步完成，并且沒有增量延遲后，遷移流程將生成具體的切換任務(wù)，切換流程如下：

我們只需要在預(yù)定的時(shí)間窗口內(nèi)，點(diǎn)擊觸發(fā)切換流程，就可以完成從MySQL到OceanBase的切換。整個(gè)切換流程可在一分鐘之內(nèi)完成，而且業(yè)務(wù)端無需進(jìn)行改造。我們擁有反向鏈路，如碰到有異常情況，可以隨時(shí)安排回退。反向鏈路在正常情況下將保留兩周以上。

四、OceanBase監(jiān)控

分布式數(shù)據(jù)庫(kù)和單機(jī)數(shù)據(jù)庫(kù)一個(gè)比較大的區(qū)別在于分布式監(jiān)控比單機(jī)版數(shù)據(jù)庫(kù)更為復(fù)雜。一是因?yàn)榻M件眾多，需要有一個(gè)全局視點(diǎn)；二是因?yàn)樾枰獙?duì)告警點(diǎn)進(jìn)行聚合。業(yè)務(wù)新遷移到OceanBase時(shí)，觀察集群監(jiān)控、關(guān)注告警信息是判斷遷移成功與否的關(guān)鍵。日常的冒煙現(xiàn)象或者不規(guī)范現(xiàn)象，需要及時(shí)發(fā)現(xiàn)、及時(shí)處理，避免問題惡化。準(zhǔn)確監(jiān)控和及時(shí)告警可以幫助運(yùn)維人員快速定位問題，快速解決故障。

4.1 監(jiān)控大盤

OceanBase的監(jiān)控?cái)?shù)據(jù)主要通過在每臺(tái)Server上部署的Agent程序從本地直接采集。Agent中包含眾多組件，內(nèi)容如下：

Agent程序會(huì)向hickwall上報(bào)采集到的數(shù)據(jù)，以模板化的形式展示出來，以此形成監(jiān)控大盤。如下圖所示：

4.2 告警郵件

OceanBase的告警，主要通過訂閱hickwall上的監(jiān)控?cái)?shù)據(jù)以及定時(shí)的服務(wù)巡檢來完成。基于采集的監(jiān)控?cái)?shù)據(jù)設(shè)立告警閾值，一旦指標(biāo)超過閾值便會(huì)進(jìn)行告警通知。另外，我們還會(huì)對(duì)配置進(jìn)行定期檢查，來解決規(guī)范性問題等。

4.3 OceanBase SQL審計(jì)

OceanBase接入了攜程的SQL審計(jì)流程。與以往傳統(tǒng)的審計(jì)插件模式不同，現(xiàn)在以抓取網(wǎng)絡(luò)包的方式，通過對(duì)MySQL協(xié)議解析得到全量的SQL審計(jì)信息。接入審計(jì)流程后，可以快速定位到SQL信息，包括應(yīng)用編號(hào)、訪問IP、執(zhí)行參數(shù)、有無報(bào)錯(cuò)信息等。

4.4 OceanBase審計(jì)運(yùn)用案例

在使用MySQL command-line tool連接OceanBase過程中出現(xiàn)連接不上的錯(cuò)誤時(shí)，我們使用SQL審計(jì)日志進(jìn)行定位，發(fā)現(xiàn)客戶端在連接OB的過程中會(huì)執(zhí)行一些元數(shù)據(jù)查詢工作，在進(jìn)行show tables這一步驟后會(huì)報(bào)錯(cuò)斷連，后續(xù)定位到一個(gè)特殊的表，該表表名的最后一個(gè)字符是分號(hào)（t_sample;）導(dǎo)致了這次報(bào)錯(cuò)，隨即我們?cè)陂_源社區(qū)反饋了這例問題。

五、OceanBase自動(dòng)故障診斷

隨著越來越多的MySQL遷移到OceanBase，數(shù)據(jù)庫(kù)性能、故障定位的實(shí)時(shí)性和準(zhǔn)確性的要求變得越來越高。自動(dòng)故障診斷系統(tǒng)可以全方位、及時(shí)、精準(zhǔn)地定位線上問題，為運(yùn)維和排障提供依據(jù)。

5.1 構(gòu)建實(shí)時(shí)性能數(shù)倉(cāng)

OceanBase性能數(shù)倉(cāng)構(gòu)建的流程圖如下：

收集性能指標(biāo)相關(guān)數(shù)據(jù)，以下是常用的性能指標(biāo)對(duì)應(yīng)的數(shù)據(jù)源：

開發(fā)數(shù)據(jù)收集程序，在服務(wù)器本地每10秒采集一次上述性能指標(biāo)的數(shù)據(jù)。并在采集之后對(duì)數(shù)據(jù)進(jìn)行結(jié)構(gòu)化處理，包括對(duì)數(shù)值型數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)化處理，對(duì)文本型數(shù)據(jù)進(jìn)行時(shí)序化處理。
將結(jié)構(gòu)化處理之后的數(shù)據(jù)落地存儲(chǔ)到ClickHouse中。

5.2 自動(dòng)化分析

自動(dòng)化分析的流程圖如下：

5.3 實(shí)時(shí)檢測(cè)性能指標(biāo)

通常判斷性能異常的指標(biāo)包括CPU占用率、磁盤IO占用率、Threads Running、QPS、網(wǎng)卡流量等。基于運(yùn)維經(jīng)驗(yàn)，可以針對(duì)每個(gè)指標(biāo)設(shè)定相應(yīng)的閾值，當(dāng)突破閾值時(shí)，則認(rèn)為當(dāng)前實(shí)例存在性能問題。比如CPU占用率高于65%或磁盤IO占用率高于80%則代表服務(wù)器出現(xiàn)異常。

5.4 異常數(shù)據(jù)匹配數(shù)倉(cāng)

首先，對(duì)于數(shù)值型數(shù)據(jù)，分析工具會(huì)自動(dòng)選取故障指標(biāo)和故障時(shí)間段，通過相似性匹配數(shù)倉(cāng)中數(shù)據(jù)所有數(shù)值型數(shù)據(jù)包含SQL、Table、Perf三種類型，它們相關(guān)的性能指標(biāo)說明如下：

SQL對(duì)應(yīng)的性能指標(biāo)：

執(zhí)行次數(shù)、總耗時(shí)、CPU耗時(shí)、邏輯讀次數(shù)、物理讀次數(shù)等。

Table對(duì)應(yīng)的性能指標(biāo)：

增刪改行數(shù)、增刪改的SQL數(shù)、相關(guān)事務(wù)數(shù)等。

Perf對(duì)應(yīng)的性能指標(biāo)：

CPU、I/O、RPC時(shí)長(zhǎng)、索引緩存大小、緩存命中率等。

其次，對(duì)于文本型數(shù)據(jù)，分析工具會(huì)通過故障時(shí)間區(qū)間獲取所有時(shí)序化的文本數(shù)據(jù)，通常包含：

數(shù)據(jù)庫(kù)服務(wù)日志、系統(tǒng)內(nèi)部任務(wù)記錄、數(shù)據(jù)庫(kù)進(jìn)程信息等。

最后，基于前面兩種類型的數(shù)據(jù)進(jìn)行綜合性分析，分析要點(diǎn)主要有：

SQL層面：

SQL性能消耗占比、有無正在執(zhí)行的慢SQL、是否缺失索引、是否存在遠(yuǎn)程執(zhí)行或分布式執(zhí)行等。

OceanBase內(nèi)部：

OceanBase是否在做合并、是否正在均衡副本、是否存在其他異常日志等。

應(yīng)用層面：

客戶端是否進(jìn)行發(fā)布。

最終基于以上自動(dòng)化分析，實(shí)現(xiàn)服務(wù)器性能波動(dòng)真實(shí)原因的精準(zhǔn)定位，自動(dòng)生成故障定位分析報(bào)告, 并通過郵件及時(shí)推送給DBA和相關(guān)開發(fā)人員。

5.5 運(yùn)用案例

下面基于該工具自動(dòng)生成的一例分析報(bào)告來介紹該工具的實(shí)際運(yùn)用：

報(bào)告的故障指標(biāo)板塊顯示4:30后服務(wù)器的CPU上升；

報(bào)告的OceanBase相關(guān)表板塊顯示CPU上升趨勢(shì)和下面這張表的訪問趨勢(shì)一致；

報(bào)告的OceanBase相關(guān)SQL板塊顯示這張表的訪問趨勢(shì)和下面的SQL語(yǔ)句訪問趨勢(shì)一致；

報(bào)告的分析結(jié)果板塊定位到CPU上升和tablex表的訪問上升有關(guān)，而這張表的訪問上升又和這1條SQL語(yǔ)句訪問耗時(shí)增長(zhǎng)有關(guān)，最終定位由于該SQL導(dǎo)致CPU上升。后續(xù)我們聯(lián)系開發(fā)確認(rèn)是正常業(yè)務(wù)上升，并添加服務(wù)器節(jié)點(diǎn)緩解CPU負(fù)載。

六、遷移遇到的問題和實(shí)踐

6.1 .Net應(yīng)用訪問OceanBase失敗

在使用和測(cè)試OceanBase的過程中，我們發(fā)現(xiàn).Net應(yīng)用的官方MySQL連接器連接OceanBase執(zhí)行SQL失敗。

經(jīng)排查，我們發(fā)現(xiàn).Net應(yīng)用依賴連接中的ConnectionCharSetIndex，而OceanBase不存在Cnotallow=83即utf8_bin，只有utf8mb4_bin。因此我們對(duì)OceanBase的源碼進(jìn)行了修復(fù)來滿足這類應(yīng)用對(duì)OceaBase的適配性。

總結(jié)：OceanBase不夠完美，但是隨著時(shí)間推移，通過反復(fù)的測(cè)試和迭代，正在逐步完善它的各方各面。我們也參與其中，以運(yùn)維和產(chǎn)品使用者的視角對(duì)它進(jìn)行優(yōu)化和完善。

6.2 Druid應(yīng)用不兼容部分OB語(yǔ)法解析

我們?cè)陂_發(fā)Oceanbase表結(jié)構(gòu)設(shè)計(jì)工具的時(shí)候，發(fā)現(xiàn)OceanBase的SQL通過Druid解析時(shí)存在報(bào)錯(cuò)。這個(gè)錯(cuò)誤會(huì)導(dǎo)致在表結(jié)構(gòu)設(shè)計(jì)的時(shí)候?qū)隨QL DDL語(yǔ)句報(bào)錯(cuò)。遇到問題后，我們先調(diào)整到Druid最新版本，發(fā)現(xiàn)問題仍然存在。

我們將問題先從復(fù)雜的表結(jié)構(gòu)設(shè)計(jì)中抽離出最簡(jiǎn)單的SQL DDL, 并結(jié)合分析Druid的源代碼，發(fā)現(xiàn)原來Druid代碼對(duì)OceanBase的兼容在SQLIndexDefinition中實(shí)現(xiàn)，但沒有在SQLIndexOptions實(shí)現(xiàn)。根據(jù)OceanBase的語(yǔ)法樹，實(shí)際應(yīng)該在SQLIndexOptions實(shí)現(xiàn)才合理，找到問題所在后，我們提交了Pull Request, 然后被合并到Druild主線。問題得以解決。

總結(jié)：開源工具的一個(gè)好處在于碰到問題后我們可以進(jìn)行代碼分析。并快速定位問題，最后反饋社區(qū)。

6.3 OceanBase讀寫分離支持

讀寫分離是數(shù)據(jù)庫(kù)非常重要的能力，在業(yè)務(wù)層面上，它覆蓋到了ETL取數(shù)，BI報(bào)表生成，緩存刷新等多個(gè)場(chǎng)景。Oceanbase雖然支持讀寫分離功能，但需要在代碼層顯性設(shè)置弱一致性讀參數(shù)，存在對(duì)業(yè)務(wù)高度侵入的缺陷。我們對(duì)OceanBase訪問代理OBProxy做了代碼改造，新增enable_weak_read以及weak_read_user_list兩個(gè)參數(shù)，通過代理層控制開啟讀寫分離策略，對(duì)應(yīng)用透明度高。

讀寫分離場(chǎng)景下，應(yīng)用與OBProxy建聯(lián)的流程示意圖如下：

基于以上的代碼修改，我們?cè)O(shè)計(jì)了一套優(yōu)化版本的讀寫分離方案，即通過以賬號(hào)維度來控制是否使用讀寫分離。流量調(diào)度示意圖如下：

總結(jié)：OceanBase源生雖然提供了強(qiáng)大的功能，但是它并不一定100%滿足業(yè)務(wù)的場(chǎng)景和需求，因此對(duì)其組件進(jìn)行二次開發(fā)是有必要的。我們不單單對(duì)于OBProxy進(jìn)行了相關(guān)的功能適配，對(duì)于其他組件如cdc、Deploy組件等我們也根據(jù)實(shí)際場(chǎng)景需求，進(jìn)行相應(yīng)調(diào)整。

6.4 query range過大導(dǎo)致內(nèi)存溢出

在初期使用OceanBase時(shí)，我們有碰到過Server Crash的經(jīng)歷。當(dāng)一個(gè)查詢的條件中IN運(yùn)算符中包含過多元素（一萬(wàn)級(jí)別以上）時(shí)，會(huì)爆出stack overflow的異常。

經(jīng)過分析和社區(qū)交流，我們定位到優(yōu)化器在抽取query range會(huì)耗費(fèi)大量的內(nèi)存。而OceanBase在算法迭代過程中沒有檢查查詢超時(shí)，導(dǎo)致該查詢一直消耗內(nèi)存，直到用盡了 SQL ARENA的內(nèi)存。這種模式?jīng)]有做好防御機(jī)制，從而導(dǎo)致內(nèi)存溢出造成系統(tǒng)崩潰。這個(gè)問題在新版本中已經(jīng)得到修復(fù)。當(dāng)確認(rèn)到問題后，我們第一時(shí)間通知開發(fā)減少IN內(nèi)的元素?cái)?shù)量，并安排了版本升級(jí)。

總結(jié)：OceanBase作為新鮮產(chǎn)品，社區(qū)論壇和Git issue是獲取日常運(yùn)維和快速排障方案的利器，根據(jù)各種技術(shù)探索和交流分享，可以汲取優(yōu)質(zhì)內(nèi)容，收獲前沿知識(shí)，快速定位和解決問題。

6.5 修正執(zhí)行計(jì)劃

在遷移前后，數(shù)據(jù)庫(kù)的SQL性能是最值得關(guān)注的地方。作為分布式數(shù)據(jù)庫(kù)，OceanBase的優(yōu)化器相較于MySQL來說更復(fù)雜并且由于其特殊的存儲(chǔ)結(jié)構(gòu)導(dǎo)致表的統(tǒng)計(jì)直方圖刷新頻率很低，因此當(dāng)可用索引和查詢條件的適配度不高時(shí)，優(yōu)化器在選擇執(zhí)行計(jì)劃時(shí)可能存在偏差。OceanBase自帶修正執(zhí)行計(jì)劃的能力，即通過在數(shù)據(jù)庫(kù)層面直接指定同類型SQL以outline注釋的方法強(qiáng)制綁定執(zhí)行計(jì)劃。

總結(jié)：OceanBase相較于傳統(tǒng)數(shù)據(jù)庫(kù)，其分布式的架構(gòu)和特殊的存儲(chǔ)結(jié)構(gòu)也會(huì)帶來運(yùn)維門檻的提高，不過它同時(shí)也給予運(yùn)維人員更高的自由度。運(yùn)維人員需要熟悉并掌握這些強(qiáng)大的功能和運(yùn)維技巧，使線上業(yè)務(wù)具備更好的穩(wěn)定性。

七、未來展望

OceanBase開源已經(jīng)一年有余，我們的運(yùn)維工具也逐漸趨于成熟，運(yùn)維能力也在逐步提高。越來越多的MySQL正在逐步往OceanBase上遷移。隨著OceanBase 4.0版本的推出，許多新特性也已經(jīng)在逐步測(cè)試中。我們對(duì)4.0版本的新功能也非常期待。

7.1 單機(jī)分布式一體化架構(gòu)

OceanBase 4.0版本推出單機(jī)分布式一體化架構(gòu)，支持類似MySQL的輕量化單機(jī)模式部署，同時(shí)也可以在必要時(shí)迅速地?cái)U(kuò)容成分布式模式來提高性能上限。單機(jī)與分布式的靈活切換可以大大降低成本，并且基于源生主備庫(kù)的能力可以快速的完成主備的DR切換，有更強(qiáng)的高可用性保證。