携程 MySQL 迁移 OceanBase 最佳实践_台枫.pdf

《携程 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迁移案例多Shar