将MySQL实例迁移到OceanBase，携程是如何做到的？

随着携程业务模式的发展，业务数据模型呈现多元化，日益庞大的数据库实例、多IDC、异地多活部署、减少运维成本和宕机时间等是携程数据库技术面临的重大挑战。因此，数据库技术也要随之发展以适应携程与之对应的需求。

然而这个时候，携程MySQL遇到了新的挑战：数据库上慢查询治理成本高、使用传统的分库分表方案对开发不友好等等。对此，携程开始推进部分 MySQL 实例迁移到 OceanBase上，那么携程MySQL迁移流程是怎样的？实践结果如何呢？今天就来和大家分享分享。

将MySQL实例迁移，携程是如何做到的？

在携程MySQL实例迁移过程中，携程做了四点准备：设计了迁移评估工具、OceanBase 迁移流程、OceanBase 监控大盘和 OceanBase 故障诊断工具等。

首先，携程平滑迁移异构数据库，需要进行兼容性、性能和分区适应性等各项检查，提前把不兼容或有可能引起迁移异常的场景找出来并解决。对此，官方提供了OceanBase Migration Assessment(OMA)工具，用于异构数据库迁移到 OceanBase 的可行性评估。

进行了迁移评估还只是第一步，但想要将OceanBase来替换原有的MySQL，难度可不小。为了减少迁移成本，携程把迁移流程进行了封装，做到一键自动迁移，自动切换迁移流程包含五步：迁移前配置校验、MySQL 账号兼容 OceanBase 带租户账号创建、数据一致性校验、DDL 表结构修改暂停、反向同步链路搭建。

此外，如何实现应用安全并且平滑的从 MySQL 转到 OceanBase？携程也做了很多工作和预案。比如，业务新迁移到 OceanBase 时，观察集群监控、关注告警信息是判断迁移成功与否的关键。而OceanBase 的监控数据主要通过在每台 Server 上部署的 Agent 程序从本地直接采集，可以帮助运维人员快速定位问题，快速解决故障。

最后数据库迁移的自动故障诊断也非常重要，随着越来越多的 MySQL 迁移到 OceanBase，数据库性能、故障定位的实时性和准确性的要求变得越来越高。这时候OceanBase通过构建实时性能数仓、自动化分析、实时检测性能指标、异常数据匹配数仓，全方位、及时、精准地定位线上问题，为运维和排障提供依据。

携程的MySQL迁移实践，结果如何？

在携程的MySQL迁移实践中，并非一帆风顺，比如在使用和测试 OceanBase 的过程中，携程发现Net 应用的官方 MySQL 连接器连接 OceanBase 执行 SQL 失败。对此，携程对OceanBase的源码进行了修复来满足这类应用对 OceanBase 的适配性。

此外，在开发 OceanBase 表结构设计工具的时候，携程还发现 OceanBase 的 SQL 通过 Druid 解析时存在报错，这个错误会导致在表结构设计的时候导入 SQL DDL 语句报错。这个时候携程及时进行代码分析，并快速定位问题，最后反馈社区，问题得以解决。

最后，携程MySQL迁移还遇到了query range过大导致内存溢出、修正执行计划等难题，好在经过技术人员干预，迁移遇到的问题都及时得到了解决。并且在使用 OceanBase 方案之后，携程在性能和成本方面最终取得了不错的收益。

首先是性能方面，相比 MySQL，OceanBase 方案读性能平均提升 2 倍，写性能平均提升 3 倍，性能提升明显。其次是成本方面，基于数据编码以及存储引擎自带多级压缩技术，使得 OceanBase 方案相比 MySQL 节省 2/3 存储资源，很大程度上降低了硬件成本。

当然，如果从未来的角度看，OceanBase还需要做更多的工作来提高稳定性、兼容性，让高可用和易用性可见，生态工具更丰富。不过总的来说，OceanBase 兼容大部分 MySQL 的功能和语法，同时提供水平扩展性、强一致性和高可用性，已经大大满足了携程的业务需求并降低了运维成本。

随着OceanBase与携程的深层次合作，在不断地学习、实践、共创的过程中，相信也有越来越多企业了解到了OceanBase数据库迁移的经验，可以说为各个行业带来了更多可能性。