一、背景

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.enablePartitinotallow=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 對于運維工具的功能細節更加完善，開放更多功能，解決我們遇到的問題。