<返回更多

Oracle 到OceanBase如何进行数据迁移?金融客户给出了真实反馈

2023-02-27    科技热谈社
加入收藏

金融企业而言,系统架构从集中式转向分布式是大势所趋。在数据库层面,要从单机数据库转向分布式数据库虽极具诱惑,但更换数据库,企业决策依然会非常谨慎,因为涉及到巨大的风险和成本,其中就包含数据库迁移过程中的风险和成本。而OceanBase数据迁移OMS的出现,至少一定程度上消除了这一阻碍。

以国内某保险客户核心系统FF去O为例,就借助OMS的迁移能力与优势将Oracle数据库迁移到了OceanBase中。

OMS的迁移能力与优势如何?

在业务评估与改造方面,此前迁移一个业务最少需要花费一到两个月时间,进行业务改造和适配,但基于OMS自动化的兼容性评估报告以及负载回放能力,业务前期改造时间可大大缩短。

数据迁移和校验方面,虽然迁移时长与数据量及网络资源密切相关,但在提升迁移质量方面,OMS可以将增量迁移的延迟控制在毫秒级,即便跨城的情况下,最多也只需要三秒钟,而对于验证出所有不一致的数据,OMS还提供修正的结果方案,从而极大提升迁移和校验的整体效率。

在业务切换方面,通常切换前需要制定比较严密的方案,并且切换之前和过程中需要检查和校验环节非常繁琐,因为一步差错就可能会导致数据不一致,OMS通过引入大规模编排能力把所有繁琐环节都落到了平台中,OMS还提供了集成部分中间件的能力,无论在迁移还是校验过程中都用时很少。

保险客户使用OMS,最终迁移效果如何?

据了解,在客户核心系统FF中,Oracle源端总共有15张表分区表,22亿条记录需要迁移到Oceanbase 目标端。未做专门优化前,全量迁移耗时11个小时,平均每秒5.5w条记录,速度太慢,不符合客户目标。

从整个迁移过程来看,OceanBase迁移服务OMS主要解决了四个重要的问题。第一次通过调整OMS参数,增大并发、增加链接数,jvm内存优化后,clog每分钟产生130个64M日志;第二次此次主要对observer内核参数进行优化,调整参数后,每分钟OB日志量下降到20个左后。

第三次通过调整OB部署架构,借助多点写入能力提升性能,OMS每秒迁移提升到大约7w条记录,全量迁移减少到7个小时左右完成;第四次对schemal表结构进行优化,分区表改造成非分区表以及后建索引,OMS在3个小时内完成全量数据迁移,大大减少了数据迁移时间。

值得一提的是,在OMS迁移过程也出现了几次故障。比如是否发生内存或cpu保护,全量进程是否存在gc情况、是否有异常报错等,这些都是需要进一步排查的。而这些故障背后既反映了国产数据库在面对复杂场景上能力的提升,也反映了分布式架构带来的根本性变化。对此,OceanBase对OMS数据迁移性能问题排查进行了方法总结,具体如下:

这些年我们看过很多的文章都是对于数据库替换的分析和畅想,但是面对实际的大规模复杂的核心应用系统的技术平台替换,过程中还有很多在各种“分析”文章中想不到的问题,尤其对于现有运行的环境的各种适配和兼容、对应用的友好性等很多。

关于这些,Oceanbase走出了坚实的一步,积累了弥足珍贵的经验,这些都为今后的国产进程给出了很好的示范效应。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>