一、背景

vivo 作為一家以設(shè)計驅(qū)動創(chuàng)造偉大產(chǎn)品，以智能終端和智慧服務(wù)為核心的科技公司，服務(wù)全球5億+用戶，用戶持續(xù)增長，同時數(shù)據(jù)量也持續(xù)增長，在數(shù)據(jù)庫運維過程中遇到如下問題：

• 分庫分表：隨著業(yè)務(wù)數(shù)據(jù)量的不斷增長，MySQL 實例數(shù)據(jù)量超過了單機容量限制，業(yè)務(wù)分庫分表的需求越來越多，分庫分表的改造成本和風(fēng)險比較高，需要能夠兼容 MySQL 的分布式數(shù)據(jù)庫解決分庫分表的問題。
• 成本壓力：業(yè)務(wù)用戶基數(shù)比較大，每年的數(shù)據(jù)自然增長規(guī)模也很大，需要持續(xù)采購新的服務(wù)器來滿足數(shù)據(jù)增長需求，存在一定的成本管理壓力。

基于上述問題，我們調(diào)研了目前市面上兼容 MySQL 且較為成熟的分布式數(shù)據(jù)庫產(chǎn)品后，最終選擇了 OceanBase，期待其原生分布式和分區(qū)表特性解決 MySQL 的分庫分表問題；其極致的數(shù)據(jù)壓縮能力與組戶級資源隔離節(jié)省存儲成本、運維成本。

1.1 原生分布式和分區(qū)表特性

OceanBase 的原生分布式架構(gòu)分為 OBProxy 層， OBServer  層，前者負責(zé)數(shù)據(jù)路由轉(zhuǎn)發(fā)，后者負責(zé)數(shù)據(jù)存儲與計算。OceanBase 通過可用區(qū)（Zone）來劃分節(jié)點，以便集群內(nèi)的自動容災(zāi)處理和優(yōu)化策略能更好地工作，根據(jù)不同的場景部署不同高可用方案，如：同城三機房三副本部署，三地五中心五副本部署等，同時，通過增加節(jié)點實現(xiàn)透明水平擴展，支持業(yè)務(wù)快速的擴容和縮容，解除我們的單機容量限制。

OceanBase 分布式架構(gòu)

(圖片來源: OceanBase 官網(wǎng))

1.2 數(shù)據(jù)壓縮能力與組戶級資源隔離

OceanBase 的表可設(shè)計為分區(qū)表，每個分區(qū)均衡分布到不同的 OBServer 節(jié)點上，每個物理分區(qū)有一個用于存儲數(shù)據(jù)的存儲層對象，叫做 Tablet，Tablet 有多個副本分布在不同的 OBSever 節(jié)點，使用日志流（Log Stream）來做數(shù)據(jù)持久化和副本之間的數(shù)據(jù)同步，正常情況下主副本提供服務(wù)，當(dāng)主副本故障時會自動切換從副本，從而保證數(shù)據(jù)的安全性與可用性，一個集群可創(chuàng)建多個互相之間隔離的數(shù)據(jù)庫"實例"，叫做租戶（Tenant）,可為多個獨立業(yè)務(wù)提供服務(wù)，租戶間數(shù)據(jù)隔離，降低部署和運維成本。此外，得益于 LSM-Tree 的存儲引擎，OceanBase 具備極致的數(shù)據(jù)壓縮能力，據(jù)官方文檔及企業(yè)案例介紹，可以使存儲成本降低60%以上。

總的來說，OceanBase 的原生分區(qū)表能很好地解決業(yè)務(wù)架構(gòu)中分庫分表帶來的問題，分區(qū)表對上層業(yè)務(wù)無感知，可以節(jié)省大量的改造成本與時間，并降低風(fēng)險，提高業(yè)務(wù)可用性，數(shù)據(jù)壓縮能力可以極大地節(jié)省我們的存儲空間，此外，OceanBase 的性能、可用性、安全性、社區(qū)支持等方面也都符合運維預(yù)期，滿足業(yè)務(wù)需求。

二、OceanBase 落地實踐

為了更順暢的實現(xiàn)遷移和運維 OceanBase 數(shù)據(jù)庫，在正式遷移前，我們部署了 OceanBase 運維 OCP 平臺、日志代理工具 oblogproxy、遷移工具 OMS，具備了集群部署管理、監(jiān)控報警、備份恢復(fù)、日志采集、遷移等運維能力，結(jié)合內(nèi)部數(shù)據(jù)庫運維管理平臺，實現(xiàn)了元數(shù)據(jù)管理、數(shù)據(jù)查詢、數(shù)據(jù)變更等能力，能夠滿足 DBA 運維和業(yè)務(wù)查詢變更需要，具備生產(chǎn)上線的條件。

2.1 OCP 平臺部署

OceanBase 云平臺（OceanBase Cloud Platform，OCP）是一款以 OceanBase 為核心的企業(yè)級數(shù)據(jù)庫管理平臺，提供對 OceanBase 集群和租戶等組件的全生命周期管理服務(wù)，也對 OceanBase 相關(guān)的資源（主機、網(wǎng)絡(luò)和軟件包等）提供管理服務(wù)，能夠更加高效地管理 OceanBase 集群，降低企業(yè)的 IT 運維成本。

OCP 架構(gòu)

(圖片來源: OceanBase 官網(wǎng))

OceanBase 云平臺包括管理 Agent（Management Agent）、管理服務(wù)（Management Service）、元信息數(shù)據(jù)庫（Metadata Repository）、監(jiān)控數(shù)據(jù)庫（Monitor Repository）、管理控制臺（Management Console）和 OBProxy（OceanBase 專用反向代理） 這六個模塊，每個模板之前協(xié)同工作。OCP 還提供高可用方案，一主多備，解決單點故障問題。

在部署時，我們將 OCP 元數(shù)據(jù)，管理服務(wù)等均使用三節(jié)點跨機房部署，避免單一節(jié)點故障，實現(xiàn)高可用性。由于公司已有一套告警平臺，所以在部署時，我們通過 OCP 的告警通道自定義腳本功能實現(xiàn) OCP 與公司告警服務(wù)的對接，讓 OCP 的告警能更好地兼容到公司的告警平臺。

OCP 工具的另一項重要功能是備份與恢復(fù)。在 OCP 中，物理備份由基線數(shù)據(jù)、日志歸檔數(shù)據(jù)兩種數(shù)據(jù)組成，數(shù)據(jù)備份優(yōu)先選擇 Follower 副本進行備份，當(dāng)用戶發(fā)起數(shù)據(jù)備份請求時，該請求會首先被轉(zhuǎn)發(fā)到 RS 所在的節(jié)點上，RS 會根據(jù)當(dāng)前的租戶和租戶包含的 PG 生成備份數(shù)據(jù)的任務(wù)，然后把備份任務(wù)分發(fā)到 OBServer 節(jié)點上并行地執(zhí)行備份任務(wù)，把備份文件數(shù)據(jù)存放在指定的網(wǎng)絡(luò)存儲，如NFS、S3等。

OCP 備份架構(gòu)

(圖片來源: OceanBase 官網(wǎng))

OceanBase 數(shù)據(jù)庫支持的備份介質(zhì)豐富，包括 NFS、阿里云 OSS、騰訊云 COS、AWS S3 ，以及兼容 S3 協(xié)議的對象存儲。此處值得一提的是，在 OCP上創(chuàng)建備份策略，存儲介質(zhì)為S3，集群發(fā)起備份時要把備份文件存放在指定S3目錄，如下圖所示。

2.2 oblogproxy 工具部署

oblogproxy（OceanBase LogProxy，即 OceanBase 日志代理）是 OceanBase 的增量日志代理，它可以與 OceanBase 數(shù)據(jù)庫建立連接并進行增量日志讀取，為下游服務(wù)提供變更數(shù)據(jù)捕獲（CDC）的能力。其 Binlog 模式為兼容 MySQL binlog 而誕生，支持現(xiàn)有的 MySQL binlog 生態(tài)工具來同步 OceanBase，現(xiàn)有的 MySQL binlog 生態(tài)工具可以平滑切換至 OceanBase 數(shù)據(jù)庫。

oblogproxy 架構(gòu)

(圖片來源: OceanBase 官網(wǎng))

oblogproxy 啟動 bc 模塊用于拉取 OceanBase clog 并將其轉(zhuǎn)換為 binlog 格式，轉(zhuǎn)換后將其寫入到文件，即 binlog 文件，MySQL binlog 生態(tài)工具（圖中為 Canal 或 Flink-CDC）發(fā)起 binlog 訂閱請求到 OBProxy，OBProxy 收到 binlog 訂閱請求后將其轉(zhuǎn)發(fā)至 oblogproxy，接收到 OBProxy 轉(zhuǎn)發(fā)的 binlog 訂閱請求后啟動 bd 模塊，bd 模塊啟動后讀取 binlog 文件并對外提供訂閱服務(wù)，即 binlog dump 。我們通過網(wǎng)絡(luò)共享存儲存放元數(shù)據(jù)的方式實現(xiàn)oblogproxy 多節(jié)點部署，避免單一節(jié)點故障，實現(xiàn)高可用。

2.3 OMS 工具部署

OceanBase 遷移服務(wù)（OceanBase Migration Service，OMS）是 OceanBase 數(shù)據(jù)庫提供的一種支持同構(gòu)或異構(gòu)數(shù)據(jù)源與 OceanBase 數(shù)據(jù)庫之間進行數(shù)據(jù)交互的服務(wù)，具備在線遷移存量數(shù)據(jù)和實時同步增量數(shù)據(jù)的能力。

OMS架構(gòu)

(圖片來源: OceanBase 官網(wǎng))

OMS 主要服務(wù)包含：

• DBCat，數(shù)據(jù)對象采集和轉(zhuǎn)換組件。
• 增量拉取組件 Store、增量同步組件 Incr-Sync、全量導(dǎo)入組件 Full-Import 和全量校驗組件 Full-Verification。
• 基礎(chǔ)服務(wù)組件，包括集群管理、資源池管理、高可用組件和元數(shù)據(jù)管理等多個組件，以保證遷移模塊的高效調(diào)度和穩(wěn)定運行。
• 管理控制臺，進行一站式遷移調(diào)度。

在部署 OMS 時，我們對于 OMS 元數(shù)據(jù)、遷移服務(wù)均使用三節(jié)點跨機房部署，避免單一節(jié)點故障，實現(xiàn)高可用。在使用 OMS 進行數(shù)據(jù)遷移、同步等監(jiān)控與告警方面， OMS 沒有重復(fù)實現(xiàn)相關(guān)組件，而是通過調(diào)用 OCP 的告警通道來發(fā)送告警。

三、數(shù)據(jù)庫遷移方案與實踐

3.1 MySQL 遷移 OceanBase 實踐

為了防止遷移過程出現(xiàn)難以解決的問題，我們對遷移可行性進行了評估。經(jīng)過性能壓測、兼容性測試（表結(jié)構(gòu)，查詢 SQL，賬號等）均符合要求。在進行分區(qū)適應(yīng)性測試時，發(fā)現(xiàn)業(yè)務(wù)使用分區(qū)表時，表結(jié)構(gòu)需要做兼容性修改，查詢 SQL 也要適配分區(qū)表，但結(jié)合業(yè)務(wù)改造成本評估，結(jié)果也符合預(yù)期。

我們使用 OMS 將 MySQL 數(shù)據(jù)遷移到 OceanBase，遷移鏈路支持全量和增量，保證數(shù)據(jù)的實時同步和全量校驗并提供反向增量同步，遷移異常時業(yè)務(wù)能快速回滾，保證業(yè)務(wù)可用性。

OMS 數(shù)據(jù)遷移項目

遷移流程分為8個步驟：

• 第一步，遷移前配置校驗。
• 第二步，驗證 OceanBase租 戶與賬號。
• 第三步，數(shù)據(jù)一致性校驗。
• 第四步，DDL 表結(jié)構(gòu)修改暫停。
• 第五步，數(shù)據(jù)同步延遲校驗。
• 第六步，應(yīng)用切換數(shù)據(jù)庫連接配置，或者修改域名解析。
• 第七步，KILL 源庫殘余連接，確保應(yīng)用連接到OceanBase。
• 第八步，停止 OMS 數(shù)據(jù)正向同步，開啟反向同步，用于回滾。

以上流程是為確保切換成功，減少遷移風(fēng)險，并提供了回退預(yù)案，最大程度保證業(yè)務(wù)的可用性與安全性。

遷移了5套 MySQL 集群近20T的數(shù)據(jù)到 OceanBase 集群，帶來如下收益：

• 云服務(wù)存儲了海量數(shù)據(jù)并且數(shù)據(jù)還在持續(xù)快速增長，原本 MySQL 分庫分表方案的維護與管理需要巨大成本，而且存在較大的可用性風(fēng)險。OceanBase 分區(qū)表替代了分庫分表方案，不僅解除了維護管理成本，高壓縮特性也節(jié)省了存儲成本。
• 風(fēng)控集群數(shù)據(jù)寫入量較大，導(dǎo)致主從延遲一直居高不下，存在數(shù)據(jù)丟失風(fēng)險，OceanBase 數(shù)據(jù)強一致性很好的解決這個問題并且存儲空間節(jié)省70%。
• 金服歸檔庫使用 tukodb 存儲，存在唯一索引失效的問題，tukodb 官方也不再維護，可用性得不到保證，遷移 OceanBase 后，該問題迎刃而解，查詢與 DDL 性能有大幅度的提升，分布式水平擴展解決單機容量問題。

3.2 某分布式數(shù)據(jù)庫遷移 OceanBase 實踐

由于此前在一些邊緣業(yè)務(wù)應(yīng)用某分布式數(shù)據(jù)庫，自 OceanBase 上線后，我們也決定將這部分業(yè)務(wù)統(tǒng)一遷移到 OceanBase。我們考慮了兩種遷移方案，第一種方案是基于某分布式數(shù)據(jù)庫的增量同步工具和 KAFKA+OMS，第二種方案是基于 CloudCanal，并進行了方案對比，如下：

CloudCanal 雖然架構(gòu)簡單，但不支持反向同步，增量同步性能較差，不滿足業(yè)務(wù)遷移需求；CDC+KAFKA+OMS 架構(gòu)雖較復(fù)雜，但其與 OceanBase 兼容性更好，支持反向同步便于業(yè)務(wù)回退，整體性能也更好。因此，最終選擇基于 CDC+KAFKA+OMS 的架構(gòu)方案進行全量遷移和增量同步，同時進行全量校驗，并提供反向增量同步。

CDC 把集群的增量數(shù)據(jù)解析為有序的行級變更數(shù)據(jù)輸出到下游的 Kafka，OMS 通過消費 Kafka 的增量數(shù)據(jù)寫入 OceanBase 完成增量同步。Kafka的數(shù)據(jù)默認保留7天，如果考慮到數(shù)據(jù)延遲較大的情況，可以適當(dāng)調(diào)整 Kafka 數(shù)據(jù)保留時間，同時，OMS 也可以通過增加并發(fā)等配置來提高同步速度。

在進行近500億全量數(shù)據(jù)同步時，RPS(行/秒)非常低，只有 6000-8000，需要幾周才能遷移完成，這顯然是不符合預(yù)期的。經(jīng)過分析，發(fā)現(xiàn)數(shù)據(jù)源與目標(biāo)端均無壓力和異常，OMS 服務(wù)主機負載也正常，顯然問題不在這里。繼續(xù)分析發(fā)現(xiàn)源表的自增主鍵ID不是連續(xù)的，且跨度很大， OMS 默認使用主鍵來做數(shù)據(jù)分片，導(dǎo)致全量同步時每次只同步到少量的有效數(shù)據(jù)，致使 RPS 比較低。

我們修改 source.sliceBatchSize（每個分片記錄數(shù)）為12000，并把內(nèi)存調(diào)大，調(diào)整之后RPS有明顯的提高：39,257 /39,254，但仍未達到預(yù)期。

通過分析 OMS 的全量同步的 msg/metrics.log 日志，發(fā)現(xiàn)wait_dispatch_record_size": 157690，這個指標(biāo)很高，顯示異常：wait_dispatch_record_size 大于 0，表示 OMS 內(nèi)部計算數(shù)據(jù)歸屬分區(qū)存在瓶頸，分區(qū)表情況下一般都會有積壓，分區(qū)計算比較耗時，關(guān)閉分區(qū)計算  sink.enablePartitinotallow=false，并調(diào)大 srink.workerNum，RPS 平均能達到50-60W左右，至此遷移性能基本符合預(yù)期。

此外，在數(shù)據(jù)遷移時，我們也遇到三個問題，以下列出問題及解決方案，供大家參考。

問題1

OMS 遷移任務(wù)提示  The response from the CM service is not success 。

解決方案：

分析任務(wù) connector.log 日志，提示  CM service is not success，但查看CM服務(wù)狀態(tài)是正常的，分析同步任務(wù)的內(nèi)存使用情況，發(fā)現(xiàn)內(nèi)存嚴重不足，F(xiàn)GC 次數(shù)非常高，導(dǎo)致服務(wù)異常，調(diào)整CM內(nèi)存：進入 OMS 容器，修改：

/home/admin/conf/command/start_oms_cm.sh，jvm修改為 -server -Xmx16g -Xms16g -Xmn8g

問題2

增量同步 RPS 過低，加大并發(fā)后基本也就是 8000 左右，而且數(shù)據(jù)庫與 OMS 并沒有明顯的壓力。

解決方案：

分析增量任務(wù) connector.log 日志，發(fā)現(xiàn)增量追平全量同步位點時還一直提示有大量的 PRIMARY 沖突，但發(fā)現(xiàn)源和目標(biāo)端的數(shù)據(jù)并沒有異常，不存在數(shù)據(jù)沖突問題，最后發(fā)現(xiàn)是 CDC 寫入重復(fù)數(shù)據(jù)的原因，進而使 OMS 無法批量寫入，導(dǎo)致 RPS 過低。目前 OMS 版本還沒有針對這個場景優(yōu)化，只能加大寫入并發(fā)數(shù)讓 RPS 有一定的提升。

問題3

索引空間放大問題，在集群空間使用率只有50%左右，空間充裕時創(chuàng)建索引時報空間不足：ERROR 4184 (53100): Server out of disk space。

解決方案：

分析集群節(jié)點空間使用率，集群的節(jié)點剩余空間還有一半，空間還是比較充裕的，正常來說不應(yīng)該會空間不足。從 OBServer 日志可見，索引創(chuàng)建時空間放大了5.5 倍，需要5.41TB，而目前集群只剩余1.4TB，明顯空間不足。

OceanBase 4.2.3之前的版本存在索引放大的原因是：

• 排序時落盤的中間結(jié)果，同時有元數(shù)據(jù)記錄；
• 外部排序有兩輪數(shù)據(jù)記錄；
• 排序的時候，數(shù)據(jù)是解壓縮解碼的。

OceanBase 4.2.3及更高版本進行了優(yōu)化，使用緊湊格式存放中間結(jié)果并做壓縮，同時，讓數(shù)據(jù)一邊寫一邊釋放空間。目前，索引空間放大優(yōu)化到1.5倍，因此，對于數(shù)據(jù)較大且增量數(shù)據(jù)較大的場景可以使用4.2.3之后的版本。

四、總結(jié)

總結(jié)而言，vivo 互聯(lián)網(wǎng)業(yè)務(wù)使用 OceanBase 解決了使用 MySQL 遇到的痛點問題。OceanBase 的性能與數(shù)據(jù)壓縮能力比較優(yōu)秀，其豐富的生態(tài)工具也提供了較為完善的運維能力。后續(xù)我們將持續(xù)深入 OceanBase 的能力探索，同時期待 OceanBase 對于運維工具的功能細節(jié)更加完善，開放更多功能，解決我們遇到的問題。