分布式数据库迁移OceanBase——基于网易云音乐自研CDC服务的平滑迁移方案

编者按：作为一款专注于发现和分享的音乐产品，#网易云音乐 引领音乐产品从“播放器时代”进入“在线社区时代”，为用户打造全新的音乐生活。在大体量的业务数据背后，是何种技术方案在支撑？本文分享网易云音乐PB级分库分表架构向原生分布式数据库架构迁移的技术优化经验。

作者：吕娅婷，网易云音乐资深平台开发工程师

迁移背景与核心挑战

分布式数据库 DDB 现状

网易云音乐使用最多的数据库是其内部自研的分布式 DDB 。DDB 非原生分布式数据库，而是基于 MySQL 存储节点搭建的中间件，其具有以下特点：

• 分库分表中间件：两级映射，自定义哈希。使用 MySQL 服务器作为底层数据存储节点，实现了自动路由。
• 标准化：SQL 兼容、全局自增 ID、兼容 MySQL 通信协议。
• 分布式事务：基于 2PC 协议保障数据一致性。
• 弹性扩缩容：通过 NDC 工具实现在线数据迁移（全量/增量），支持断点续传。
• 高可用：使用常见的 MySQL 主从复制实现高可用以及读写分离，同时也支持单元化。
• SQL 统计：支持 SQL 模式、SQL 频度慢 SQL及多维度 QPS 统计等。

作为网易云音乐主要的 OLTP 方案，DDB 拥有较大的数据体量，其数据流架构如图1所示。从图中可以看出，通过DBI JAR 包这个访问接口向上层应用程序提供服务。整个数据处理流程为：当上层应用程序下发 SQL 后，由DBI 进行解析生成语法树，而通过语法树生成的执行计划由执行器直接下发到底层#MySQL。多个 MySQL 节点的结果汇聚到 DBI 进行处理，最后返回上层应用程序。

图1 DDB架构

除了 DBI JAR 包（类似 SDK 方式），我们还提供了 QS（Query Server）方式，可将其理解为一个 Proxy。QS 兼容 MySQL 协议，可作为 Proxy 单独部署，相当于一个 MySQL 实体库，支持命令行和应用接口这两种访问方式，进而使应用程序可以像访问 MySQL 一样访问 QS。

在图1中，用户通过控制流可以实现 DDL 处理和元数据分发同步，Master 节点会将元数据同步到 MetaStore 即元数据库中，然后将元数据变更通知到每一个 DBI 的应用层。 DBI 和应用集成的方式虽然缩短了整个数据链路，但也带来了一些运维问题，比如当DBI数量较多、底层节点发生大批量切换或更改时，整体操作较为耗时，且若部分DBI未及时感知，可能影响该应用的读取或写入。

DDB 作为一个久经考验的数据库， 在使用过程中也存在一些痛点问题。

• PB 级数据存储，缺少高效压缩。目前底层 - MySQL 节点是5.7版本，不支持高效压缩，通常情况下计算资源还有剩余，存储资源就已经遇到瓶颈，资源利用率极低。
• 扩缩容流程复杂、耗时。DBA 每年大概要花费 20% 以上的精力进行扩缩容，人力成本很高。
• 分钟级故障切换。尽管当前我们已经多次优化故障切换，但也只能达到分钟级。
• 更新操作引发从库延迟，数据复制性能存在瓶颈。在 MySQL 主从复制模式下，如果有大批量更新，MySQL Binlog 性能存在一定瓶颈，复制延迟，对于数据敏感业务不友好。
• 缺失延续性维护。由于版本迭代成本很高，后续很难进行版本变更。

基于上述痛点，我们决定将 DDB 切换到原生分布式数据库 OceanBase。

为什么选择从DDB迁移到 OceanBase？

OceanBase 是一款原生分布式数据库（见图2 ），采用单机分布式一体化架构设计，在弹性扩展、高可用、多活容灾、存储引擎、分布式事务、HTAP、多种主流数据库兼容性、多租户等多个方面都有关键性的技术突破，并在复杂而严苛的金融核心业务场景中久经考验。

• 资源成本：实测发现存储空间可降低至少 1/4。
• 高可用：实现自动故障恢复，RTO<8秒。
• 高效复制：底层基于 Paxos 协议实现高效复制。
• 兼容性与稳定性：兼容 MySQL 协议，迁移成本低。
• 运维成本：同样由于兼容 MySQL 协议，运维成本低。
• 社区红利：社区生态健全、活跃度高。

图2 OceanBase产品形态

从产品特性和应用案例来初步判断，我们认为OceanBase能够解决我们使用DDB时面临的问题。

迁移 OceanBase 面临的核心挑战

然而，DDB和OceanBase 作为两个由不同企业研发、架构差异较大的数据库产品，使我们在迁移过程中遇到了四个挑战。

异构数据同步挑战。 数据库内部的数据传输工具互相不支持，无法直接实现数据同步，因此需要将 DDB 的分片逻辑改造成 OceanBase 的分区，同时实现分布式事务跨节点一致性保障。

业务无感迁移挑战。 迁移过程需要实现业务无感，源端发生 DDL 变更或者 MySQL 节点主从切换时，必须保证在线切换不阻塞迁移。迁移过程对迁移组件本身的高可用也有高要求，需要做到不停服升级，而OceanBase提供的迁移工具——OMS 暂不支持（后续计划支持）。

反向迁移效率挑战。 从 DDB 到 OceanBase 的正向迁移数据最快能达到 GB /s的速度，但反向迁移在大表场景和大流量场景下同步效率较低。同时也需要支持 TB 级数据快速比对。

运维效率挑战。 整个迁移过程中可能会创建上千个同步任务，如果依靠人工运维，效率低下。

迁移架构与适配工作

由于数据迁移涉及正向同步和反向同步这两个长期的同步任务，对链路稳定性及低延时性要求很高，因此我们开始了严谨的迁移架构与适配工作。

自研 CDC 服务——NDC 架构

首先，我们自研的CDC 服务——NDC 架构，类似 DTS，可以实现端到端的全量迁移、增量迁移和数据订阅的服务系统。

• NDC 大致可以分为源端系统、NDC 集群、目标端系统三部分。源端系统目前主要支持网易内部 OLTP 类型数据库和 OceanBase，目标端支持 OLTP 和 OLAP 类型数据库、以及消息队列 Kafka 等。
• NDC 拉取源端系统的全量或增量数据，经过转化和过滤写入目标系统中。
• NDC 支持全量、增量同步/迁移；提供结构、全量数据、快速不一致复检等多模式校验，确保源和目标一的致性。 如图3所示，在 NDC 内部：Dashboard 是应用入口；Center 用于元数据管理；Engine 节点是无状态的，负责拉取源端 Binlog 等信息，然后将数据进行解析，同步到目标库。

图3 NDC架构

NDC 迁移方案

使用NDC 进行数据迁移同样涉及正向同步、反向同步，正向同步指从 DDB 到 OceanBase，反向同步指从 OceanBase 到 DDB。由于涉及部分回滚场景，因此需要保证反向同步也是稳定、安全的。

1.正向同步

正向同步主要支持如下能力：

• 并行解析 Binlog。以 MySQL 为单位并行拉取、解析可以加快解析速度，同时每个 MySQL 的并行拉取解析进程是随意无状态的，可以被分布到多个机器中，极大提高资源利用率。
• 一拉多推模式，即一次解析多次使用，减少对源端的侵入。因为在上游建立 MySQL Dump 链路对源端有感，如果 MySQL 库或 DDB 表有很多订阅需求，需要在源库建立几十个链接，不管是主库还是从库，都会产生影响和侵入，因此一拉多推模式实现只拉一次解析却能多次使用，减少了对源端的侵入。
• 支持表内并发写，不同索引数据并发写。单个MySQL内部，可以通过表、索引维度进行并发，因此最终的表并发数是该表分布的MySQL 数量乘以每个MySQL子任务内部设置的并发数，实际并发非常高，同时可以利用不同机器资源去运行同一张表的不同的MySQL级任务。
• 自动响应上游切换，自动感知主从切换、节点变更等。可以自动感知上游 MySQL的主从切换以及节点变更，不需要人力运维。

图4 正向同步方案

2.反向同步：Binlog or CDC?

Binlog 模式是我们最早支持的同步模式，简单易用、稳定性高、兼容性强。大致流程如下：

• BC 模块拉取 Clog 并将其转换为 Binlog 格式，转换后将其写入 Binlog 文件。
• MySQL Binlog 生态工具发起 Binlog 订阅请求到 OBProxy，OBProxy 将其转发至 OBLogproxy。
• OBLogproxy 接收 Binlog 订阅请求后启动 BD 模块，读取 Binlog 文件并对外提供订阅服务，即 Binlog Dump 服务。

相当于为了使下游使用方便，兼容了 MySQL 的 Binlog，将 OceanBase 产生的 Clog 多转了一层转为 Binlog，但由于链路增加，效率会比较低。去年 Binlog 解析模式的效率是每秒25MB/每秒，对我们来说是无法接受的，后来 OceanBase 团队将这个值优化到了140MB/每秒，暂时满足了业务需求。

图5 Binlog同步模式

相比 Bonlog 模式，CDC 模式更简单，因为不需要将 Clog 转换为 Binlog，直接拉取 Clog，使用OBLogClient 启动，具体流程如下：

• OBLogClient 启动后需要发送消息到 OBLogProxy，需指定要订阅的用户、库表、增量链路位点等信息。
• OBLogProxy 鉴权通过后，启动 OBLogreader 子进程，并将连接等相关信息传递至 OBLogreader 子进程。
• OBLogreader 启动后会提取并解析 Clog，按照一定的数据格式发送至下游来完成数据订阅。

图6 CDC同步模式

OBCDC or OBLogProxy？

我们对 OBCDC 和 OBLogProxy 也做了调研，两个方案都属于 CDC 模式，OBCDC 是持续迭代版本的 OBLogProxy。

• OBCDC：以动态库的形式对外提供 OceanBase 数据库实时增量（事务）数据。通过 RPC 向 OceanBase 数据库请求各分区的 Clog（Redo）日志。
• OBLogProxy：OBCDC 的代理，OBLogProxy 调用 OBCDC，作为 OBCDC 的消费者获取 OceanBase 数据库的增量事务数据。

图7 OBCDC 和 OBLogProxy 方案对比

虽然CDC模式省去了binlog生成及解析的额外成本，但由于技术栈、兼容性及可维护性的考量（OceanBase 在 4.2.0版本后将不继续维护 CDC 模式），两种形式都非理想解决方案，因此我们最终并未采用CDC模式。

目前我们基本上实现了业务无感迁移、零数据丢失、正向同步效率GB/s，反向百+MB/s。

图8 正向迁移、反向迁移流程

支持迁移 OceanBase 的适配优化

在迁移过程中，我们共完成了如下方面的适配和优化工作。

• 驱动适配：JDBC 驱动版本降至8.0.25版本。
• 语法适配：移除 OceanBase 暂未支持的 DML 或语法（如 insert、ignore 语法）。
• Binlog 解析适配：移除 RotateLogEvent 的 Checksum 校验。
• 反向双模式：CDC 及 Binlog 双增量模式、内存队列及消息队列双缓存模式应对不同流量场景，提升反向同步速度.。
• 元数据变更感知：提升 DDB 为源端时底层 MySQL 发生主从切换的 NDC 感知及响应速度。

后续我们也计划实现通过 AI 迁移，即基于 MCP 的多 Agent 实现 NDC 工具的智能化运维，降低迁移过程中长期同步任务的运维成本。目前还处于早期迁移阶段，相关工作正在进行中。

当前进展与未来规划

当前网易云音乐各业务已经逐步开始使用 NDC 进行验证、线上同步、双跑等相关落地，部分业务已完成迁移，周边基础设施也开始陆续跟进，验证了系统是成熟可用的。但为了业务的稳定切换，我们的切换周期相对比较长，还有很多工作要做。

后续我们会进入核心试点和大规模迁移阶段，进一步完善 OceanBase 及周边生态的体系化建设，包括工单、部署、测试、调优、运维等。虽然我们在起步阶段，却已经接受了 OceanBase 社区很多的帮助，在此也非常感谢 OceanBase 的支持帮助。

最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！

「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。