《携程 MySQL 迁移 OceanBase 最佳实践_台枫.pdf》由会员分享,可在线阅读,更多相关《携程 MySQL 迁移 OceanBase 最佳实践_台枫.pdf(30页珍藏版)》请在三个皮匠报告上搜索。
1、携程MySQL迁移OceanBase最佳实践业务场景携程数据库的变迁过程SQLServerMySQLNewSQL现状 少量留存的SQLServer 大部分核心业务部署在MySQL上 部分MySQL实例迁移到了NewSQL数据库业务场景MySQL存在的问题和瓶颈1、业务数据模型呈现多元化,OLTP 和 OLAP 出现融合的趋势2、业务数据量增长迅速,容量成本显著提升3、传统分库分表方案对开发不友好,核心库改造成本高4、MHA模式因网络原因切换容易脑裂业务场景OceanBase的优势/劣势优势 分布式协议可以防止脑裂 集群可扩展性强,性能上限高,扩容简单 底层存储压缩率高,大大降低存储成本劣势 分
2、布式架构导致一般场景下性能略弱于单机数据库 分布式架构对运维排障要求更高业务需求MySQL如何平滑地迁移到OceanBase?如何提前预知业务对OceanBase的兼容性?如何判断OceanBase可以支持业务的流量?如何保证迁移前后能够提供相近的运维支持?如何让业务在切换期间尽可能透明?如何支持业务的其他配套设施?(包括发布、闪回、canal等)业务切换后是否有足够的收益?迁移方案评估流程 评估项标准应用中间件版本检查非标应用、非标账号检查分区方案评估推荐业务SQL兼容性和性能评估01020304迁移方案评估流程 构建评估环境My SQLPer formance_schema剔除掉无用SQL
3、或者非迁移对象相关的SQL生成兼容性校验SQLSQL池Druid解析SQL根据SQL的digest生成SQL执行次数占比根据执行量生成性能测试的SQL池迁移方案评估流程 评估改进案例在近期的一次日志库迁移评估中,我们通过优化掉业务在MySQL侧使用的range分区,在压测前端压力不变的情况下大幅提高业务迁移到OceanBase后的吞吐。保留range分区 10000QPS去掉range分区 50000QPS迁移方案评估流程 慢SQL优化案例迁移方案迁移流程 迁移前配置校验 MySQL账号兼容OceanBase带租户账号创建 数据迁移和一致性校验 DDL表结构发布修改暂停 反向同步链路搭建迁移方
4、案迁移流程 数据迁移结构图任务开始表结构校验流程终止进入回退流程数据同步延迟校验禁用My SQL侧应用账号或者Revoke权限Kill掉残留链接数据同步延迟校验删除My SQL到OB的同步链路验证OB端应用账号链接情况DAL连接串切换停止My SQL到OB的同步链路,开启反向链路否否否否迁移遇到的问题和解决方案兼容不适配应用的兼容1、.Net应用访问OceanBase失败2、Druid应用不兼容部分OB语法解析迁移遇到的问题和解决方案读写分离方案优化设计APPobproxyobproxyobproxyobproxy集群流量weak_read_user_list=testerproxy_idc_
5、name=idc2observer1t1(p1)leadert1(p2)followerobserver2t1(p1)followert1(p2)followerobserver3t1(p1)followert1(p2)leadertester 读写写tester 读zone1 idc1zone2 idc2zone3 idc3迁移现状哪些类型的DB我们已经迁移到OceanBase?1、归档库从MySQL搬迁到OceanBase4、少量订单/产品/核心业务库2、部分线上核心日志库3、部分非核心业务迁移收益OceanBase迁移后的部分收益酒店日志系列shard集群迁移至OB后从12台机器压缩到3
6、台机器,成本降低约75%;01归档库从MySQL迁移到OceanBase后,压缩比超过1:4,空间成本大幅降低;02火车票部分核心业务通过租户级别隔离,将多个MySQL集群以租户为单位合并成一个OceanBase集群,大幅提高资源利用率。03迁移案例多Shard合并到一个OB集群 以酒店日志shard合并为例酒店日志shard系列设计初衷:日志数量多容量大,业务上需要较长的保留时间,因此需要更多的机器;订单操作日志,有部分OLTP类需求,无法完全挪到OLAP类数据库上;日志库压力、日志写入量和请求量会随着订单量的波动而波动。010203迁移案例多Shard合并到一个OB集群 以酒店日志shar
7、d合并为例容量评估压缩比1:4SQL评估单Zone综合QPS 50000+表结构调整去除range分区OMS迁移迁移时长 一周Canal反向增量同步延迟 2s迁移案例归档库迁移OceanBaseMySQL作为归档库存在的问题:1.innodb引擎压缩比低,成本偏高;2.myrocks稳定性不够,经常需要人工介入处理;3.无法扩展,同一个db的归档数据可能因为容量原因散落在多组集群上。迁移案例归档库迁移OceanBase归档库迁移方案 新增的归档直接配置目的端到OB上;存量的归档数据一次性全量迁移到OB上;持续归档且业务需求查询的数据通过全量+增量的方式迁移到OB。迁移案例归档库架构集群:cls
8、01Zone:ZONE1Proxy-机房110.10.10.1F物理机Zone:ZONE2Proxy-机房210.20.10.2F物理机Zone:ZONE310.30.10.3L虚拟运维建设监控模块与智能分析 构建监控大盘运维建设监控模块与智能分析 SQL审计MySQL OceanBaseTiDB网卡Trace FilesMySQL协议解析Client运维建设监控模块与智能分析 SQL审计应用在使用MySQL command-line tool连接OceanBase报错利用审计日志定位到客户端连接OB过程中有查询元数据操作,在进行到show tables时候报错断连,进一步排查到有一个表名结尾
9、带分号的特殊表(t_sample;)触发异常报错。运维建设监控模块与智能分析 构建性能数仓收集开始数值收集文本收集数值时序差值化插入Kafka存入ClickHouse收集结束运维建设监控模块与智能分析 自动化分析流程检测开始CPU.ThreadsRunning,QPS,网卡流量,磁盘否吐量。实时检测检测是否异常分析结束自动生成分析报告获取异常前后收集的文本数据确定故障指标及异常时间段获取异常前后收集的数值数据在上万个数值指标中取出故障发生前后有波动的指标故障指标和波动指标进行相似性匹配丢弃指标结合数据进行分析定位问题故障得到和故障指标时序曲线相似的数值指标剔除低消耗或被影响指标无异常有异常不相
10、似相似运维建设监控模块与智能分析 自动化分析流程实例1.报告故障指标显示 4:30 OB集群中出现服务器 CPU上升4.报告的分析结果板块定位到CPU上升和tablex表的访问上升有关,而这张表的访问上升又和这1条SQL语句访问耗时增长有关,最终定位由于该SQL导致CPU上升。2.报告中的表访问趋势板块,发现CPU上升趋势与表访问趋势一致3.报告中SQL板块的相关SQL趋势与表访问趋势相近运维建设配套工具建设1.与原MySQL的表结构发布系统兼容2.利用obcdc支持Canal订阅兼容3.基于ob_admin制作数据闪回工具4.基于sql_audit的准全量trace采集5.分布式数据库日志分析。运维建设灾备方案如何实现?集群:cls01异步集群:cls01mirror异步同步Zone:ZONE1Proxy-机房110.10.10.1F物理机Zone:ZONE2Proxy-机房210.20.10.2F物理机Zone:ZONE310.30.10.3L虚拟Zone:ZONE1Proxy-机房310.40.10.1F物理机总结和未来展望在OceanBase 4 版本下我们还能做些什么?探索新的单机分布式一体化架构01更多的生态和兼容性增强02基于新功能的运维能力提升03Thank you!