本文內容主要分享攜程在 OceanBase 社群版的探索，將從以下三個方面展開分析：OceanBase 自動化部署、MySQL 例項遷移 OceanBase 以及 OceanBase 方案收益。

作者：陳堯    攜程資料庫負責人，2006年加入攜程，10餘年資料庫運維經驗，主要負責SQLServer、MySQL資料庫運維和自動化運維開發相關工作。

攜程於1999年創立，2016-2018年全面推進應用 MySQL 資料庫，前期線上業務、前端技術等以 SQL Server 為主，後期資料庫逐步從 SQL Server 轉到開源 MySQL 資料庫。

隨著技術多元化以及業務的不斷髮展，MySQL 逐漸無法滿足攜程需求，主要體現在：業務資料模型呈現多元化，在異地多活部署、運維成本、資源彈性管理以及應用穩定性等方面對資料庫技術提出了新的要求，MySQL 方案在單機效能瓶頸表現明顯，同時分庫分表方案帶來運維複雜度和維護成本也隨之增加。於是從2018年開始，攜程開始引入 Mongo、HBase 等技術棧，同時探索透過 OceanBase 社群版方案來替換原有 MySQL 方案。

經前期測試與後期實踐，事實證明 OceanBase 技術特性及架構相對符合攜程專案需求。OceanBase 的異地多機房多寫、大促彈性擴容、高可用切換對業務影響小都非常符合攜程需求。同時在效能和成本方面取得了不錯的收益： 在效能方面，OceanBase 方案讀效能平均提升 2 倍，寫效能平均提升 3 倍；在成本方面，OceanBase 方案節省 2/3 儲存資源，很大程度上降低了硬體成本。

一、基於OBD工具自動化部署環境

OBD （OceanBase Deployer）是 OceanBase 開源軟體的安裝部署工具，同時也是包管理器，可以用來管理 OceanBase 所有的開源軟體。一開始，攜程利用 OceanBase 開發的 OBD 元件快速進行了部署，由於業務需要非常靈活的運維操作，比如需要擴容 OBServer 時，該操作需要透過命令列執行 ALTER 語句實現，暫不支援透過 OBD 來完成叢集擴容，同時綜合業務自身需求：

1、攜程有自己的運維監控平臺，需要將 OceanBase 的後設資料、監控資料、以及任務流很好地融入到攜程監控平臺、自動運維平臺中；

2、攜程有著完整的企業 dal 層、資料庫多環境（開發、測試、生產）上傳發布流程和部署平臺，OceanBase 需要相容甚至還需要和 MySQL 互相巧妙的相容，而 OBD 當前版本無法支援。

為此， 攜程選擇了基於 OBD 自動化工具進行二次開發，形成符合業務需求的部署方案，基於兩個方面的考慮：開發語言易上手，二次開發成本低。OBD 工具是Python 寫的程式，原始碼簡單易懂，可以直接除錯原始碼並進行二次開發自動化部署程式，大大降低了 OceanBase 運維嵌入攜程平臺的難度；融入個性化設定。

OBD 工具雖然方便，但是一些配置不夠靈活，攜程的安全策略以及伺服器環境限制可能和 OBD 有所衝突。叢集的後設資料合併到攜程的運維平臺至關重要，而二次開發的自動化程式，可以直接定義安裝的使用者、目錄，將伺服器、IP、Zone 等基礎資訊直接落到運維平臺，為後續自動化運維打下了堅實的基礎，和攜程運維平臺契合的更緊密。

以下是攜程基於 OBD 部署工具二次開發的部署運維平臺示意圖：

在環境部署這裡特別提一點， OceanBase 的命令可以將整個引數放在啟動命令中，包括 OBServer 和 OBProxy。 叢集部署好後會在OBServer/etc目錄下生成一個配置檔案 OBServer.config.bin，將所有叢集資訊記錄在檔案中，這樣後續啟動或者重啟 OBServer 時，就不需要再帶引數啟動。OBProxy 也是一樣，在 OBProxy/etc 下也會生成 OBProxy_config.bin 檔案，再次啟動可以不帶引數啟動，這點對使用者非常友好，避免不帶引數再次啟動時，出現引數回滾問題。

二、MySQL遷移OceanBase實踐

在部署工具改造工作完成之後，正式進入業務和資料的遷移環節。該部分主要從以下幾個方面來介紹攜程的遷移工作：叢集架構設計、遷移準備工作（包括相容性測試、業務模式評估、回退方案等）、應用遷移以及效能最佳化。

1、OceanBase 架構如何設計？

在實際環境中，需要根據自身 IDC 機房的部署，匹配適用 OceanBase 的架構設計。OceanBase 在攜程的部署架構如下，當前是一地三中心部署方案：

2、遷移準備工作

1）SQL 事務相容性測試

在攜程開始使用時， OceanBase 社群版完全相容 MySQL 5.6版本，而實際攜程應用的是5.7版本。為此，將 Memtable Trace 抓取出來的語句在 OceanBase 上進行相容性測試， 發現大部分都相互相容。這裡需要注意的是：OceanBase 不支援主鍵的刪除，主鍵的修改、跨資料型別的欄位的型別修改，但新增欄位，擴容欄位，沒有任何影響。

2）對 MySQL 例項特點和業務模式進行分析

最值得關注的是， 可以直接用 MySQL 建立表結構的語句在 OceanBase 建表，後期簡單做下最佳化和微調就可以，對使用者非常友好。

3）分割槽表結構改造

在OceanBase裡，一張表即使沒做分割槽也預設為分割槽表，即一個大的分割槽。使用分割槽表一方面可以基於資料分割槽來做叢集層面的資料擴充套件, 另外一方面可以更充分的支援 SQL 並行執行, 充分利用資源，提升叢集的效能。

同時，好的分割槽設計機制跟業務息息相關。在實際環境中，MySQL例項的分割槽機制相對特殊，大量分割槽表的分割槽維護需要依賴自動化指令碼，因此遷移到 OceanBase 環境前，表結構需要進行改造。換言之， 更好地分析與設計 OceanBase 分割槽表，可以充分地發揮  OceanBase 的優勢。基於以上考慮，對業務表結構進行如下改造：

• 去掉 Max 分割槽：由於OceanBase 不支援 Max 分割槽的 Reorganize，所以MySQL 的 range 分割槽錶轉到 OceanBase 後需要去掉 Max 分割槽，直接預留和保留一些分割槽來保證所有資料落在分割槽中，風險點是當資料超出分割槽範圍則會導致寫入失敗。

• 本地索引改造：分割槽表的分割槽增加和刪除機制，是由指令碼自動維護的。在分割槽維護的時候，刪除分割槽耗時比 MySQL 要長很多，經過分析研究，原因是表結構在 OceanBase 建立後二級索引預設是Global索引，在維護分割槽的時候會重建全域性索引，所以耗時比較久。解決方法：建立表結構的時候，二級索引指定為 Local，這樣在維護分割槽時可以瞬間完成。

• TableGroup 解決跨 zone 訪問：小表到底要不要做分割槽？根據 OceanBase 開源社群技術專家的意見：小表不建議做分割槽。為了解決 join 時候跨 zone 跨機器查詢，rpc count 過大導致效能下降問題，比較小的表、做 key 分割槽的表 join 查詢比較頻繁的表等可以做 TableGroup，這樣小表或者相同key的資料會在一起，不會跨 zone 跨機器查詢。

4）回退方案

在OceanBase社群版3.1.0版本中，回退的方案並沒有很多，針對社群版不支援OMS元件的情況，攜程有兩種解決辦法：

?  方法1：應用雙寫

這是最常用的一種方法，即在業務資料遷移完成之後，業務在寫入 MySQL 環境的同時也會寫入 OceanBase 環境。經過一段時間的線上驗證，確認 OceanBase 方案在效能和穩定上滿足業務要求之後，會斷開業務寫 MySQL 環境的鏈路，業務讀寫流量全部接入 OceanBase 環境。雙寫的缺點是增加開發成本，開發要介入。在社群版 3.1.2 版本中，將會開源的資料同步工具 OMS（OceanBase Migration Service）是 OceanBase 提供的一站式資料傳輸產品， 提供 MySQL 到 OceanBase 以及 OceanBase 到 MySQL 資料同步能力，資料遷移將會變的更加簡單和快捷。

?  方法2：備份恢復

備份恢復是 OceanBase 資料庫高可用特性的核心元件，主要用於保障資料的安全，包括預防儲存介質損壞和使用者的錯誤操作等。如果儲存介質損壞或者使用者誤操作而導致了資料丟失，可以透過恢復的方式恢復使用者的資料。從社群版3.1.1 開始, 社群版支援物理備份與恢復, 備份和恢復的效能得到大幅提升，可以快速的完成線上資料的全量和增量備份以及在異常情況下的資料恢復，非常好用。

三、上線遷移&效能最佳化

1、從 MySQL 平滑遷移至 OceanBase

攜程自研設計架構是三個 IDC，對應著三個 IDC 機房，也就是物理的機房，其中一個是開源的叢集。由於後續資源緊張，對叢集進行彈性擴容，每個 Zone 從最初的一臺機器擴容到了兩臺機器。在 OBProxy 這一層，為了防止訪問過於集中以及考慮到高可用問題，多個 OBProxy 做了負載均衡，應用透過負載均衡裝置可以將流量平均打在多個 OBProxy。還有另外一個方法，即應用透過 DNS 直接訪問，但這種方法用得很少。

如何實現應用安全並且平滑的從 MySQL 轉到 OceanBase？攜程也做了很多工作和預案。比如，OceanBase 的連線串有租戶的配置，那麼用 MySQL 的賬號直接訪問 OceanBase 是不行的，需要提前在 MySQL 建立一個帶租戶的賬號， uapp@tt01 許可權和之前的賬號一樣，只要修改應用的連線串配置，開發無需重新發布，後續將連線資料庫的配置直接切換到 OceanBase，幾乎可以實現完全相容。只要在遷移前驗證確保所有的應用全部使用臨時賬號，就可以萬無一失。

2、效能最佳化

在 SQL 最佳化方面，遷移之前應用大批次寫入 MySQL 環境，單個批次資料量範圍在1000條至10000條不等，寫入效能不佳。 同等資料量時，在 OceanBase 環境中資料寫入更快。此外，可以對 SQL 語句進行最佳化，比如減少多張表的 join 查詢，SQL 語句帶上分割槽條件縮小範圍查詢，避免跨分割槽查詢。

業務資料大量寫入的時候，可以透過調整一些記憶體相關引數、日誌清理引數來保證叢集執行的穩定。在這裡介紹3個非常有用的引數以及實際操作說明供參考學習：

• enable_merge_by_turn 控制是否開啟輪轉合併。在凌晨做大合併的時候，開啟輪轉合併是逐個 zone 進行合併操作，先把 Leader 切走再做合併，做完再做下一個，切 Leader 會影響到業務。關閉該引數即所有的 zone 一起操作，可能會出現大事務衝突問題，攜程一般會選擇業務低峰期，或者業務影響很小的時候進行合併，保證合併順利完成的同時儘量縮短用時。

• minor_freeze_times 用於設定多少次小合併觸發一次全域性合併。在實際業務中，頻繁的全域性合併可能會影響叢集整體效能，透過該引數設定轉儲條件，儘量減少觸發大合併的次數，保證叢集效能穩定。

• writing_throttling_trigger_percentage引數用來控制記憶體限流閥值，在MEMStore 佔用記憶體達到該引數預設閥值時，會開啟寫入限速。針對寫入頻繁的高寫入業務場景可能出現的記憶體耗盡導致 OOM 問題，透過該引數配合writing_throttling_maximum_duration 引數（透過控制記憶體分配進度來控制寫入速度，即指定在觸發寫入限速後，剩餘 memstore 記憶體分配完所需的時間，預設一小時）使用。如果記憶體使用在預設值一小時之內達到限流閾值大小，剩下的記憶體會按照預設一小時平均分配。預設一小時之後記憶體沒有釋放，OceanBase 會拒絕應用建立新連線。這是一個保護措施，保證攜程的叢集在寫入量很大時，叢集執行依舊穩定。

3、慢 SQL 最佳化

在實際業務測試中，出現執行時間很長的 SQL 語句，仔細排查原因發現是因為查詢所需的資料分佈在不同節點或者機器上，所以 SQL 請求的資料需要跨機器或者跨 zone 訪問，網路互動次數增加，影響 SQL整體執行時間，在這裡介紹一個典型慢 SQL 最佳化案例。

慢 SQL 資訊：

select a.c1,a.c2 from table1 a left join table2 b on a.c0 = b.c0 where b.c1 is null and a.c1 = “XXXXX”;

檢視系統表得到該 SQL 執行資訊：select * from gv$sql_audit;

  針對這個場景嘗試兩種最佳化方法：

?  第一種：使用 TableGroup 方式，將查詢所需的資料放在一起，查詢速度提升明顯

Step1：建立 tablegroup

mysql> CREATE TABLEGROUP IF NOT EXISTS tg_1;

Step2：新增對應的表

mysql> ALTER TABLE TABLE1 SET TABLEGROUP tg_1;

mysql> ALTER TABLE TABLE2 SET TABLEGROUP tg_1;

 

?  第二種：手工把兩個表遷移到同一個節點，效果一樣但是相對麻煩

Step1：switch replica

mysql> ALTER SYSTEM SWITCH REPLICA PARTITION_ID=‘0%0@100000’ source=‘ x.x.x.x:2882 ’；

Step2：move replica

mysql> ALTER SYSTEM MOVE REPLICA PARTITION_ID=‘0%0@100000’ source=‘x.x.x.x::2882‘；

Step3：避免分割槽自動在Unit之間重新均衡

mysql> ALTER SYSTEM SET ENABLE_REBALANCE = 'false' [TENANT=‘tenantname’];

透過以上兩種最佳化方式，RPC_count 從 23331降低至 1 次，最佳化效果顯著。

四、效能和成本方面收益明顯

在使用 OceanBase 方案之後，攜程在效能和成本方面取得了不錯的收益：

1、 效能方面：

相比 MySQL，OceanBase 方案讀效能平均提升 2 倍，寫效能平均提升 3 倍，效能提升明顯；

2、 成本方面：

基於資料編碼以及儲存引擎自帶多級壓縮技術，使得 OceanBase 方案相比 MySQL 節省 2/3 儲存資源，很大程度上降低了硬體成本。

寫在最後

在攜程與 OceanBase 短暫的磨合期內，攜程各項測試表明，OceanBase 原生分散式資料庫的各方面效能均可滿足攜程的業務需求。當前攜程的風控業務系統、會員使用者畫像等多個業務在測試 OceanBase 社群版。攜程非常感謝OceanBase 的所有技術支援人員，期待在後續合作中，OceanBase 能發揮出更優越的表現。

參與更多技術交流，請至 OceanBase 社群版 。