(资料图片)
作者简介
提挈，携程资深数据库工程师，专注于数据库自动化运维和分布式数据库的研究。 Cong，携程数据库专家，主要负责MySQL和分布式数据库运维及研究。 Typhoon，携程高级数据库工程师，负责分布式数据库的运维和工具设计。 一、前言MySQL在业界流行多年，很好地支撑了携程的业务发展。但随着技术多元化及业务的不断发展，MySQL也遇到了新的挑战，主要体现在：业务数据模型呈现多元化，OLTP和OLAP出现融合的趋势；在MySQL数据库上慢查询治理成本高；使用传统的分库分表方案对开发不友好，核心数据库改造成分库分表方案，时间一般以年为单位。 分布式数据库能比较好地解决上述问题，同时也带来了新的挑战。2021年，OceanBase（简称OB）开源，携程开始逐步探索OceanBase的基本特性和应用场景。OceanBase兼容大部分MySQL的功能和语法，同时提供水平扩展性、强一致性和高可用性，能满足业务需求并降低运维成本。因此，我们开始推进部分MySQL实例迁移到OB。为保证迁移顺畅，我们设计了迁移评估工具、OB迁移流程、OB监控大盘和OB故障诊断工具等。并将迁移过程中遇到的问题和大家进行分享。 二、评估工具平滑迁移异构数据库，我们需要进行兼容性、性能和分区适应性等各项检查。提前把不兼容或有可能引起迁移异常的场景找出来并解决。官方提供了OceanBase Migration Assessment(OMA)工具，用于异构数据库迁移到OB的可行性评估。迁移评估工具OMA有语法兼容性检查和性能评估，但还不能完全满足我们的需求。主要体现在下面几点: 中间件版本检查，一个DB有多个应用在访问，只有某个版本后的中间件才开始支持OceanBase，需要检查访问该DB的所有应用的中间件版本，并督促开发进行升级，以确保都在支持OB版本之上。 性能采集和回放提供的MySQL General Log采集模式有一定风险，尤其是对于业务繁重的数据库，我们需要更平滑的性能采集和回放方案。另外对于单实例多DB场景，存在迁移和不迁移的DB共存的情况，需要进行过滤。 线上存在非通过中间件访问的数据库账号，如ETL取数账号、数据查询工具账号、应用直连账号等，对其兼容性需要进行检查。因为迁移到OB之后，数据库登录账号需要进行改变，包含租户信息。 OceanBase是分布式数据库，数据如何进行分区就显得非常重要，以避免形成热点数据。一张表可能有多个字段都适合作为分区键，在迁移工具中，根据数据分布以及访问情况，需要提供表分区推荐，以减少迁移成本。 因此我们对OMA评估工具进行了拓展和改造。在不影响现有的数据库运行下，省去中间环节，做到一键评估。其中MySQL数据采集与分析大致流程示意图如下，全量数据导入OceanBase后，目标端我们用开源Locust工具，进行SQL回放和压测，并最终形成评估报告。 三、迁移流程在评估流程完成并且评估结果符合迁移要求的前提下，可以发起MySQL到OceanBase自动迁移流程。为减少迁移成本，我们把迁移流程进行了封装，做到一键自动迁移，自动切换包含以下流程： 1）迁移前配置校验。迁移前，会集中对所有的切换注意事项和相关配置再进行一次全面的检查，提前排除配置问题可能导致的切换风险。 2）MySQL账号兼容OceanBase带租户账号创建。由于OceanBase是多租户管理模式，应用的连接串必须指定租户名，因此相应账号需要在目标OB集群预先创建，中间件或工具切换账号时，只需重置连接并切换到新账号即可。 3）数据一致性校验。数据通过Canal从MySQL同步到OB后，我们需要对一致性做校验。校验的方法是根据表主键进行切分，进行结果集比较是否一致。当遇到热点表时，数据校验过程会发起多次尝试来反复验证。 4）DDL表结构修改暂停。由于MySQL和OceanBase表结构变更方式差异较大，当DB迁移从MySQL到OceanBase触发流程后，我们会在源MySQL禁止DDL操作。当然，如果开发有紧急发布需求，我们可以废弃流程，等DDL发布完成后，再重启迁移流程。 5）反向同步链路搭建。无论前面的迁移评估或者流程多么完善，反向同步链路对于异构数据库的迁移是必备的。一旦迁移出现异常，可以快速回退。反向同步链路是基于OceanBase的CDC服务，订阅增量日志在MySQL端回放，保证迁移后OceanBase侧和MySQL侧数据始终一致。 当数据同步完成，并且没有增量延迟后，迁移流程将生成具体的切换任务，切换流程如下： 我们只需要在预定的时间窗口内，点击触发切换流程，就可以完成从MySQL到OceanBase的切换。整个切换流程可在一分钟之内完成，而且业务端无需进行改造。我们拥有反向链路，如碰到有异常情况，可以随时安排回退。反向链路在正常情况下将保留两周以上。 四、OceanBase监控分布式数据库和单机数据库一个比较大的区别在于分布式监控比单机版数据库更为复杂。一是因为组件众多，需要有一个全局视点；二是因为需要对告警点进行聚合。业务新迁移到OceanBase时，观察集群监控、关注告警信息是判断迁移成功与否的关键。日常的冒烟现象或者不规范现象，需要及时发现、及时处理，避免问题恶化。准确监控和及时告警可以帮助运维人员快速定位问题，快速解决故障。 4.1 监控大盘OceanBase的监控数据主要通过在每台Server上部署的Agent程序从本地直接采集。Agent中包含众多组件，内容如下： Agent程序会向hickwall上报采集到的数据，以模板化的形式展示出来，以此形成监控大盘。如下图所示： 4.2 告警邮件OceanBase的告警，主要通过订阅hickwall上的监控数据以及定时的服务巡检来完成。基于采集的监控数据设立告警阈值，一旦指标超过阈值便会进行告警通知。另外，我们还会对配置进行定期检查，来解决规范性问题等。 4.3 OceanBase SQL审计OceanBase接入了携程的SQL审计流程。与以往传统的审计插件模式不同，现在以抓取网络包的方式，通过对MySQL协议解析得到全量的SQL审计信息。接入审计流程后，可以快速定位到SQL信息，包括应用编号、访问IP、执行参数、有无报错信息等。 4.4 OceanBase审计运用案例在使用MySQL command-line tool连接OceanBase过程中出现连接不上的错误时，我们使用SQL审计日志进行定位，发现客户端在连接OB的过程中会执行一些元数据查询工作，在进行show tables这一步骤后会报错断连，后续定位到一个特殊的表，该表表名的最后一个字符是分号（t_sample;）导致了这次报错，随即我们在开源社区反馈了这例问题。 五、OceanBase自动故障诊断随着越来越多的MySQL迁移到OceanBase，数据库性能、故障定位的实时性和准确性的要求变得越来越高。自动故障诊断系统可以全方位、及时、精准地定位线上问题，为运维和排障提供依据。 5.1 构建实时性能数仓OceanBase性能数仓构建的流程图如下： 收集性能指标相关数据，以下是常用的性能指标对应的数据源： 开发数据收集程序，在服务器本地每10秒采集一次上述性能指标的数据。并在采集之后对数据进行结构化处理，包括对数值型数据进行标准化处理，对文本型数据进行时序化处理。 将结构化处理之后的数据落地存储到ClickHouse中。 5.2 自动化分析自动化分析的流程图如下： 5.3 实时检测性能指标通常判断性能异常的指标包括CPU占用率、磁盘IO占用率、Threads Running、QPS、网卡流量等。基于运维经验，可以针对每个指标设定相应的阈值，当突破阈值时，则认为当前实例存在性能问题。比如CPU占用率高于65%或磁盘IO占用率高于80%则代表服务器出现异常。 5.4 异常数据匹配数仓首先，对于数值型数据，分析工具会自动选取故障指标和故障时间段，通过相似性匹配数仓中数据所有数值型数据包含SQL、Table、Perf三种类型，它们相关的性能指标说明如下： SQL对应的性能指标： 执行次数、总耗时、CPU耗时、逻辑读次数、物理读次数等。 Table对应的性能指标： 增删改行数、增删改的SQL数、相关事务数等。 Perf对应的性能指标： CPU、I/O、RPC时长、索引缓存大小、缓存命中率等。 其次，对于文本型数据，分析工具会通过故障时间区间获取所有时序化的文本数据，通常包含： 数据库服务日志、系统内部任务记录、数据库进程信息等。 最后，基于前面两种类型的数据进行综合性分析，分析要点主要有： SQL层面： SQL性能消耗占比、有无正在执行的慢SQL、是否缺失索引、是否存在远程执行或分布式执行等。 OceanBase内部： OceanBase是否在做合并、是否正在均衡副本、是否存在其他异常日志等。 应用层面： 客户端是否进行发布。 最终基于以上自动化分析，实现服务器性能波动真实原因的精准定位，自动生成故障定位分析报告, 并通过邮件及时推送给DBA和相关开发人员。 5.5 运用案例下面基于该工具自动生成的一例分析报告来介绍该工具的实际运用： 报告的故障指标板块显示4:30后服务器的CPU上升； 报告的OceanBase相关表板块显示CPU上升趋势和下面这张表的访问趋势一致； 报告的OceanBase相关SQL板块显示这张表的访问趋势和下面的SQL语句访问趋势一致； 报告的分析结果板块定位到CPU上升和tablex表的访问上升有关，而这张表的访问上升又和这1条SQL语句访问耗时增长有关，最终定位由于该SQL导致CPU上升。后续我们联系开发确认是正常业务上升，并添加服务器节点缓解CPU负载。 六、迁移遇到的问题和实践6.1 .Net应用访问OceanBase失败在使用和测试OceanBase的过程中，我们发现.Net应用的官方MySQL连接器连接OceanBase执行SQL失败。 经排查，我们发现.Net应用依赖连接中的ConnectionCharSetIndex，而OceanBase不存在ConnectionCharSetIndex=83即utf8_bin，只有utf8mb4_bin。因此我们对OceanBase的源码进行了修复来满足这类应用对OceaBase的适配性。 总结：OceanBase不够完美，但是随着时间推移，通过反复的测试和迭代，正在逐步完善它的各方各面。我们也参与其中，以运维和产品使用者的视角对它进行优化和完善。
