机票搜索量猛增7倍！携程是怎么借助OceanBase完成数据库迁移的？

近日来，各大旅游平台迎来复苏，机票、火车票和酒店关注度大涨，仅携程上机票的瞬时搜索量就增长了7倍，火车票搜索量增长5倍，春节期间搜索量达到近三年的峰值。

除了业务上带来的流量压力，携程也承担着数据库改造的压力。自2014年左右开始全面使用MySQL数据库，随着业务增长、数据量激增，单机实例逐渐出现瓶颈，如单表行数过大导致历史数据查询耗时升高，单库容量过大导致磁盘空间不足等。

为应对这些问题，携程开始将目光转移到分布式数据库以解决这些痛点。2021年，OceanBase 开源，携程开始逐步探索 OceanBase 的基本特性和应用场景，并推进部分 MySQL 实例迁移到 OceanBase，如今也已取得良好成效。

携程MySQL 实例迁移过程，是什么样的？

迁移前，携程会集中对所有的切换注意事项和相关配置再进行一次全面的检查，提前排除配置问题可能导致的切换风险。

第二步，将创建MySQL 账号兼容 OceanBase 带租户账号。由于 OceanBase 是多租户管理模式，应用的连接串必须指定租户名，因此相应账号需要在目标 OceanBase 集群预先创建，中间件或工具切换账号时，只需重置连接并切换到新账号即可。

第三步，数据一致性校验。数据通过 Canal 从 MySQL 同步到 OceanBase 后，需要对一致性做校验。

第四步，DDL 表结构修改暂停。由于 MySQL 和 OceanBase 表结构变更方式差异较大，当 DB 迁移从 MySQL 到 OceanBase 触发流程后，我们会在源 MySQL 禁止 DDL 操作。

第五步，反向同步链路搭建。无论前面的迁移评估或者流程多么完善，反向同步链路对于异构数据库的迁移是必备的，一旦迁移出现异常，可以快速回退。当数据同步完成，并且没有增量延迟后，迁移流程将生成具体的切换任务，切换流程如下：

借助OceanBase，携程数据库迁移获得新突破

借助OceanBase的原生分布式能力，携程能更好地解决MySQL的隐患并带来了不少额外的好处。诸如OceanBase的存储引擎使用了类LSM Tree设计，表的scheme也支持多个版本。对于困扰着没有运维过 MySQL 的技术人员的在线 DDL来说，在OceanBase的加持下，可以秒级即可完成并且不会锁表。

此外，分布式数据库和单机数据库一个比较大的区别在于分布式监控比单机版数据库更为复杂。一是因为组件众多，需要有一个全局视点；二是因为需要对告警点进行聚合。业务新迁移到 OceanBase 时，观察集群监控、关注告警信息是判断迁移成功与否的关键，而OceanBase的监控和告警体系接入到携程现有的监控体系中，可以通过管控使用API的方式接入，使得携程可以统一管理所有的数据库产品。

同时OceanBase自动故障诊断系统还可以全方位、及时、精准地定位线上问题，通过构建实时性能数仓、自动化分析、实时检测性能指标、异常数据匹配数仓，OceanBase可以帮助携程全方位、及时、精准地定位线上问题，为运维和排障提供依据。

具体来看，报告的故障指标板块显示 4:30 后服务器的 CPU 上升，同时报告的 OceanBase 相关表板块显示 CPU 上升趋势和下面这张表的访问趋势一致，这表明相比MySQL，OceanBase对故障定位的实时性和准确性都得到了大大提升。

据携程方表示，OceanBase 对 MySQL 的高兼容性一直是其考量的重点，高度兼容为开发同事节省了大量学习成本和代码成本。在 4.0 版本中，在字符集、约束、函数、存储过程等多方面与 MySQL 的匹配度更高，在使用上与 MySQL 更加接近。

相信在近几年OceanBase的合作范围不断扩大、优势进一步凸显的过程中，一定还会给行业带来更加惊喜的功能，