从MySQL到OceanBase，vivo突破单机性能瓶颈，构建全新数据底座

👉 分库分表：随着业务数据量的不断增长，MySQL 实例数据量超过了单机容量限制，业务分库分表的需求越来越多，分库分表的改造成本和风险比较高，需要能够兼容 MySQL 的分布式数据库解决分库分表的问题。

👉 成本压力：业务用户基数比较大，每年的数据自然增长规模也很大，需要持续采购新的服务器来满足数据增长需求，存在一定的成本管理压力。

👉 DBCat，数据对象采集和转换组件。

👉 增量拉取组件 Store、增量同步组件 Incr-Sync、全量导入组件 Full-Import 和全量校验组件 Full-Verification。

👉 基础服务组件，包括集群管理、资源池管理、高可用组件和元数据管理等多个组件，以保证迁移模块的高效调度和稳定运行。

👉 管理控制台，进行一站式迁移调度。

👉 第一步，迁移前配置校验。

👉 第二步，验证 OceanBase 租 户与账号。

👉 第三步，数据一致性校验。

👉 第四步，DDL 表结构修改暂停。

👉 第五步，数据同步延迟校验。

👉 第六步，应用切换数据库连接配置，或者修改域名解析。

👉 第七步，KILL 源库残余连接，确保应用连接到 OceanBase。

👉 第八步，停止 OMS 数据正向同步，开启反向同步，用于回滚。

🚩 云服务存储海量数据且数据还在持续快速增长，原本 MySQL 分库分表方案的维护与管理需要巨大成本，而且存在较大的可用性风险。OceanBase 分区表替代了分库分表方案，不仅节省了维护管理成本，高压缩特性也节省了存储成本。

🚩 风控集群数据写入量较大，导致主从延迟一直居高不下，存在数据丢失风险，OceanBase 数据强一致性很好的解决这个问题，并且存储空间节省 70%。

🚩 金服归档库使用 tukodb 存储，存在唯一索引失效的问题，tukodb 官方也不再维护，可用性得不到保证，迁移 OceanBase 后，该问题迎刃而解，查询与 DDL 性能有大幅度的提升，分布式水平扩展解决单机容量问题。

🧐 问题：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

🧐 问题：增量同步 RPS 过低，加大并发后基本也就是 8000 左右，而且数据库与 OMS 并没有明显的压力。

🙋‍♂️ 解决方案：分析增量任务 connector.log 日志，发现增量追平全量同步位点时还一直提示有大量的 PRIMARY 冲突，但发现源和目标端的数据并没有异常，不存在数据冲突问题，最后发现是 CDC 写入重复数据的原因，进而使 OMS 无法批量写入，导致 RPS 过低。目前 OMS 版本还没有针对这个场景优化，只能加大写入并发数让 RPS 有一定的提升。

🧐 问题：索引空间放大问题，在集群空间使用率只有 50% 左右，空间充裕时创建索引时报空间不足：ERROR 4184 (53100): Server out of disk space。

🙋‍♂️ 解决方案：分析集群节点空间使用率，集群的节点剩余空间还有一半，空间还是比较充裕的，正常来说不应该会空间不足。从 OBServer 日志可见，索引创建时空间放大了 5.5 倍，需要 5.41TB，而目前集群只剩余 1.4TB，明显空间不足。