作者：來自 vivo 網際網路資料庫團隊- Xu Shaohui
本文總結了目前我們遇到的痛點問題並透過 OceanBase 的技術方案解決了這些痛點問題，完整的描述了 OceanBase 的實施落地，透過遷移到 OceanBase 實踐案例中遇到的問題與解決方案讓大家能更好的瞭解 OceanBase 功能與特性，最後總結了 OceanBase 優缺點與展望。
一、背景
vivo 作為一家以設計驅動創造偉大產品，以智慧終端和智慧服務為核心的科技公司，服務全球5億+使用者，使用者持續增長，同時資料量也持續增長，在資料庫運維過程中遇到如下問題：
- 分庫分表：隨著業務資料量的不斷增長，MySQL 例項資料量超過了單機容量限制，業務分庫分表的需求越來越多，分庫分表的改造成本和風險比較高，需要能夠相容 MySQL 的分散式資料庫解決分庫分表的問題。
- 成本壓力：業務使用者基數比較大，每年的資料自然增長規模也很大，需要持續採購新的伺服器來滿足資料增長需求，存在一定的成本管理壓力。
基於上述問題，我們調研了目前市面上相容 MySQL 且較為成熟的分散式資料庫產品後，最終選擇了 OceanBase，期待其原生分散式和分割槽表特性解決 MySQL 的分庫分表問題；其極致的資料壓縮能力與組戶級資源隔離節省儲存成本、運維成本。
1.1 原生分散式和分割槽表特性
OceanBase 的原生分散式架構分為 OBProxy 層， OBServer 層，前者負責資料路由轉發，後者負責資料儲存與計算。OceanBase 透過可用區（Zone）來劃分節點，以便叢集內的自動容災處理和最佳化策略能更好地工作，根據不同的場景部署不同高可用方案，如：同城三機房三副本部署，三地五中心五副本部署等，同時，透過增加節點實現透明水平擴充套件，支援業務快速的擴容和縮容，解除我們的單機容量限制。
OceanBase 分散式架構
(圖片來源: OceanBase 官網)
1.2 資料壓縮能力與組戶級資源隔離
OceanBase 的表可設計為分割槽表，每個分割槽均衡分佈到不同的 OBServer 節點上，每個物理分割槽有一個用於儲存資料的儲存層物件，叫做 Tablet，Tablet 有多個副本分佈在不同的 OBSever 節點，使用日誌流（Log Stream）來做資料持久化和副本之間的資料同步，正常情況下主副本提供服務，當主副本故障時會自動切換從副本，從而保證資料的安全性與可用性，一個叢集可建立多個互相之間隔離的資料庫"例項"，叫做租戶（Tenant）,可為多個獨立業務提供服務，租戶間資料隔離，降低部署和運維成本。此外，得益於 LSM-Tree 的儲存引擎，OceanBase 具備極致的資料壓縮能力，據官方文件及企業案例介紹，可以使儲存成本降低60%以上。
總的來說，OceanBase 的原生分割槽表能很好地解決業務架構中分庫分錶帶來的問題，分割槽表對上層業務無感知，可以節省大量的改造成本與時間，並降低風險，提高業務可用性，資料壓縮能力可以極大地節省我們的儲存空間，此外，OceanBase 的效能、可用性、安全性、社群支援等方面也都符合運維預期，滿足業務需求。
二、OceanBase 落地實踐
為了更順暢的實現遷移和運維 OceanBase 資料庫，在正式遷移前，我們部署了 OceanBase 運維 OCP 平臺、日誌代理工具 oblogproxy、遷移工具 OMS，具備了叢集部署管理、監控報警、備份恢復、日誌採集、遷移等運維能力，結合內部資料庫運維管理平臺，實現了後設資料管理、資料查詢、資料變更等能力，能夠滿足 DBA 運維和業務查詢變更需要，具備生產上線的條件。
2.1 OCP 平臺部署
OceanBase 雲平臺（OceanBase Cloud Platform，OCP）是一款以 OceanBase 為核心的企業級資料庫管理平臺，提供對 OceanBase 叢集和租戶等元件的全生命週期管理服務，也對 OceanBase 相關的資源（主機、網路和軟體包等）提供管理服務，能夠更加高效地管理 OceanBase 叢集，降低企業的 IT 運維成本。
OCP 架構
(圖片來源: OceanBase 官網)
OceanBase 雲平臺包括管理 Agent（Management Agent）、管理服務（Management Service）、元資訊資料庫（Metadata Repository）、監控資料庫（Monitor Repository）、管理控制檯（Management Console）和 OBProxy（OceanBase 專用反向代理） 這六個模組，每個模板之前協同工作。OCP 還提供高可用方案，一主多備，解決單點故障問題。
在部署時，我們將 OCP 後設資料，管理服務等均使用三節點跨機房部署，避免單一節點故障，實現高可用性。由於公司已有一套告警平臺，所以在部署時，我們透過 OCP 的告警通道自定義指令碼功能實現 OCP 與公司告警服務的對接，讓 OCP 的告警能更好地相容到公司的告警平臺。
OCP 工具的另一項重要功能是備份與恢復。在 OCP 中，物理備份由基線資料、日誌歸檔資料兩種資料組成，資料備份優先選擇 Follower 副本進行備份，當使用者發起資料備份請求時，該請求會首先被轉發到 RS 所在的節點上，RS 會根據當前的租戶和租戶包含的 PG 生成備份資料的任務，然後把備份任務分發到 OBServer 節點上並行地執行備份任務，把備份檔案資料存放在指定的網路儲存，如NFS、S3等。
OCP 備份架構
(圖片來源: OceanBase 官網)
OceanBase 資料庫支援的備份介質豐富，包括 NFS、阿里雲 OSS、騰訊雲 COS、AWS S3 ，以及相容 S3 協議的物件儲存。此處值得一提的是，在 OCP上建立備份策略，儲存介質為S3，叢集發起備份時要把備份檔案存放在指定S3目錄，如下圖所示。
2.2 oblogproxy 工具部署
oblogproxy（OceanBase LogProxy，即 OceanBase 日誌代理）是 OceanBase 的增量日誌代理，它可以與 OceanBase 資料庫建立連線並進行增量日誌讀取，為下游服務提供變更資料捕獲（CDC）的能力。其 Binlog 模式為相容 MySQL binlog 而誕生，支援現有的 MySQL binlog 生態工具來同步 OceanBase，現有的 MySQL binlog 生態工具可以平滑切換至 OceanBase 資料庫。
oblogproxy 架構
(圖片來源: OceanBase 官網)
oblogproxy 啟動 bc 模組用於拉取 OceanBase clog 並將其轉換為 binlog 格式，轉換後將其寫入到檔案，即 binlog 檔案，MySQL binlog 生態工具（圖中為 Canal 或 Flink-CDC）發起 binlog 訂閱請求到 OBProxy，OBProxy 收到 binlog 訂閱請求後將其轉發至 oblogproxy，接收到 OBProxy 轉發的 binlog 訂閱請求後啟動 bd 模組，bd 模組啟動後讀取 binlog 檔案並對外提供訂閱服務，即 binlog dump 。我們透過網路共享儲存存放後設資料的方式實現oblogproxy 多節點部署，避免單一節點故障，實現高可用。
2.3 OMS 工具部署
OceanBase 遷移服務（OceanBase Migration Service，OMS）是 OceanBase 資料庫提供的一種支援同構或異構資料來源與 OceanBase 資料庫之間進行資料互動的服務，具備線上遷移存量資料和實時同步增量資料的能力。
OMS架構
(圖片來源: OceanBase 官網)
OMS 主要服務包含：
- DBCat，資料物件採集和轉換元件。
- 增量拉取元件 Store、增量同步元件 Incr-Sync、全量匯入元件 Full-Import 和全量校驗元件 Full-Verification。
- 基礎服務元件，包括叢集管理、資源池管理、高可用元件和後設資料管理等多個元件，以保證遷移模組的高效排程和穩定執行。
- 管理控制檯，進行一站式遷移排程。
在部署 OMS 時，我們對於 OMS 後設資料、遷移服務均使用三節點跨機房部署，避免單一節點故障，實現高可用。在使用 OMS 進行資料遷移、同步等監控與告警方面， OMS 沒有重複實現相關元件，而是透過呼叫 OCP 的告警通道來傳送告警。
三、資料庫遷移方案與實踐
3.1 MySQL 遷移 OceanBase 實踐
為了防止遷移過程出現難以解決的問題，我們對遷移可行性進行了評估。經過效能壓測、相容性測試（表結構，查詢 SQL，賬號等）均符合要求。在進行分割槽適應性測試時，發現業務使用分割槽表時，表結構需要做相容性修改，查詢 SQL 也要適配分割槽表，但結合業務改造成本評估，結果也符合預期。
我們使用 OMS 將 MySQL 資料遷移到 OceanBase，遷移鏈路支援全量和增量，保證資料的實時同步和全量校驗並提供反向增量同步，遷移異常時業務能快速回滾，保證業務可用性。
OMS 資料遷移專案
遷移流程分為8個步驟：
- 第一步，遷移前配置校驗。
- 第二步，驗證 OceanBase租 戶與賬號。
- 第三步，資料一致性校驗。
- 第四步，DDL 表結構修改暫停。
- 第五步，資料同步延遲校驗。
- 第六步，應用切換資料庫連線配置，或者修改域名解析。
- 第七步，KILL 源庫殘餘連線，確保應用連線到OceanBase。
- 第八步，停止 OMS 資料正向同步，開啟反向同步，用於回滾。
以上流程是為確保切換成功，減少遷移風險，並提供了回退預案，最大程度保證業務的可用性與安全性。
遷移了5套 MySQL 叢集近20T的資料到 OceanBase 叢集，帶來如下收益：
- 雲服務儲存了海量資料並且資料還在持續快速增長，原本 MySQL 分庫分表方案的維護與管理需要巨大成本，而且存在較大的可用性風險。OceanBase 分割槽表替代了分庫分表方案，不僅解除了維護管理成本，高壓縮特性也節省了儲存成本。
- 風控叢集資料寫入量較大，導致主從延遲一直居高不下，存在資料丟失風險，OceanBase 資料強一致性很好的解決這個問題並且儲存空間節省70%。
- 金服歸檔庫使用 tukodb 儲存，存在唯一索引失效的問題，tukodb 官方也不再維護，可用性得不到保證，遷移 OceanBase 後，該問題迎刃而解，查詢與 DDL 效能有大幅度的提升，分散式水平擴充套件解決單機容量問題。
3.2 某分散式資料庫遷移 OceanBase 實踐
由於此前在一些邊緣業務應用某分散式資料庫，自 OceanBase 上線後，我們也決定將這部分業務統一遷移到 OceanBase。我們考慮了兩種遷移方案，第一種方案是基於某分散式資料庫的增量同步工具和 KAFKA+OMS，第二種方案是基於 CloudCanal，並進行了方案對比，如下：
CloudCanal 雖然架構簡單，但不支援反向同步，增量同步效能較差，不滿足業務遷移需求；CDC+KAFKA+OMS 架構雖較複雜，但其與 OceanBase 相容性更好，支援反向同步便於業務回退，整體效能也更好。因此，最終選擇基於 CDC+KAFKA+OMS 的架構方案進行全量遷移和增量同步，同時進行全量校驗，並提供反向增量同步。
CDC 把叢集的增量資料解析為有序的行級變更資料輸出到下游的 Kafka，OMS 透過消費 Kafka 的增量資料寫入 OceanBase 完成增量同步。Kafka的資料預設保留7天，如果考慮到資料延遲較大的情況，可以適當調整 Kafka 資料保留時間，同時，OMS 也可以透過增加併發等配置來提高同步速度。
在進行近500億全量資料同步時，RPS(行/秒)非常低，只有 6000-8000，需要幾周才能遷移完成，這顯然是不符合預期的。經過分析，發現資料來源與目標端均無壓力和異常，OMS 服務主機負載也正常，顯然問題不在這裡。繼續分析發現源表的自增主鍵ID不是連續的，且跨度很大， OMS 預設使用主鍵來做資料分片，導致全量同步時每次只同步到少量的有效資料，致使 RPS 比較低。
我們修改 source.sliceBatchSize（每個分片記錄數）為12000，並把記憶體調大，調整之後RPS有明顯的提高：39,257 /39,254，但仍未達到預期。
透過分析 OMS 的全量同步的 msg/metrics.log 日誌，發現wait_dispatch_record_size": 157690，這個指標很高，顯示異常：wait_dispatch_record_size 大於 0，表示 OMS 內部計算資料歸屬分割槽存在瓶頸，分割槽表情況下一般都會有積壓，分割槽計算比較耗時，關閉分割槽計算 sink.enablePartitionBucket=false，並調大 srink.workerNum，RPS 平均能達到50-60W左右，至此遷移效能基本符合預期。
此外，在資料遷移時，我們也遇到三個問題，以下列出問題及解決方案，供大家參考。
- 問題1
OMS 遷移任務提示 The response from the CM service is not success 。
解決方案：
分析任務 connector.log 日誌，提示 CM service is not success，但檢視CM服務狀態是正常的，分析同步任務的記憶體使用情況，發現記憶體嚴重不足，FGC 次數非常高，導致服務異常，調整CM記憶體：進入 OMS 容器，修改：/home/admin/conf/command/start_oms_cm.sh，jvm修改為 -server -Xmx16g -Xms16g -Xmn8g
- 問題2
增量同步 RPS 過低，加大併發後基本也就是 8000 左右，而且資料庫與 OMS 並沒有明顯的壓力。
解決方案：
分析增量任務 connector.log 日誌，發現增量追平全量同步位點時還一直提示有大量的 PRIMARY 衝突，但發現源和目標端的資料並沒有異常，不存在資料衝突問題，最後發現是 CDC 寫入重複資料的原因，進而使 OMS 無法批次寫入，導致 RPS 過低。目前 OMS 版本還沒有針對這個場景最佳化，只能加大寫入併發數讓 RPS 有一定的提升。
- 問題3
索引空間放大問題，在叢集空間使用率只有50%左右，空間充裕時建立索引時報空間不足：ERROR 4184 (53100): Server out of disk space。
解決方案：
分析叢集節點空間使用率，叢集的節點剩餘空間還有一半，空間還是比較充裕的，正常來說不應該會空間不足。從 OBServer 日誌可見，索引建立時空間放大了5.5 倍，需要5.41TB，而目前叢集只剩餘1.4TB，明顯空間不足。
OceanBase 4.2.3之前的版本存在索引放大的原因是：
- 排序時落盤的中間結果，同時有後設資料記錄；
- 外部排序有兩輪資料記錄；
- 排序的時候，資料是解壓縮解碼的。
OceanBase 4.2.3及更高版本進行了最佳化，使用緊湊格式存放中間結果並做壓縮，同時，讓資料一邊寫一邊釋放空間。目前，索引空間放大最佳化到1.5倍，因此，對於資料較大且增量資料較大的場景可以使用4.2.3之後的版本。
四、總結
總體而言，vivo 網際網路業務使用 OceanBase 解決了使用 MySQL 遇到的痛點問題。OceanBase 的效能與資料壓縮能力比較優秀，其豐富的生態工具也提供了較為完善的運維能力。後續我們將持續深入 OceanBase 的能力探索，同時期待 OceanBase 對於運維工具的功能細節更加完善，開放更多功能，解決我們遇到的問題。