一、背景

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

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

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

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

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

OceanBase 分布式架構(gòu)

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

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

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

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

二、OceanBase 落地實(shí)踐

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

2.1 OCP 平臺(tái)部署

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

OCP 架構(gòu)

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

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

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

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

OCP 備份架構(gòu)

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

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

2.2 oblogproxy 工具部署

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

oblogproxy 架構(gòu)

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

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

2.3 OMS 工具部署

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

OMS架構(gòu)

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

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

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

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

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

3.1 MySQL 遷移 OceanBase 實(shí)踐

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

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

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

遷移流程分為8個(gè)步驟：

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

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

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

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

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

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

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

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

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

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

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

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

問(wèn)題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)存嚴(yán)重不足，F(xiàn)GC 次數(shù)非常高，導(dǎo)致服務(wù)異常，調(diào)整CM內(nèi)存：進(jìn)入 OMS 容器，修改：

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

問(wèn)題2

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

解決方案：

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

問(wèn)題3

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

解決方案：

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

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

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

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

四、總結(jié)

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