tubage109 / 待分类 / 陆金所去Oracle转MySQL全过程(下)

分享

   

陆金所去Oracle转MySQL全过程(下)

2020-03-04  tubage109
陆金所是极少数凭借自己力量去 Oracle 的一家企业,对于其去 Oracle 的实践过程,InfoQ 记者采访了陆金所去 Oracle 实践的负责人王英杰,希望给更多有去 Oracle 计划的团队提供参考。在上一篇文章中,我们分享了陆金所去 Oracle 实践过程中的方案选择与准备工作,本文继续分享其具体的实践过程。
在去 Oracle 之前,陆金所全站的金融 OLTP 业务场景都是由 Oracle 支撑的,而完成之后,全部的金融场景是由 MySQL 支撑,部分 Oracle 上的大事务也被优化成为了 MySQL 上的小事务。
值得注意的是,去 Oracle 完成之后,陆金所中 85% 的数据库查询请求都是简单的单表查询,15% 的关联查询都是比较简单的关联查询,而原先 Oracle 数据库中包含的复杂业务逻辑的多表关联也做了以下的优化:
被拆解成简单查询,在代码层实现部分复杂的关联逻辑;
通过陆金所的数据总线平台,把数据实时同步到 Elasticsearch 里,再实现复杂且高效的关联搜索;
部分在 Oracle 读库上支撑的复杂业务逻辑查询,通过数据总线平台同步到 TiDB ,在 TiDB 里实现复杂的关联查询。
在真正去 Oracle 之前,陆金所先把 MySQL 作为对外提供服务的 Oracle 备库挂在了 Oracle 后面。从 Oracle 到 MySQL 的异构数据库备库,不需要实例级的数据同步,可以按表为粒度进行数据的实时同步。
陆金所整个去 Oracle 实践主要是依赖于其内部的去 Oracle 平台来落地的,在去 Oracle 平台上勾选需要同步的 Oracle 表,数据迁移工作就会自动完成。据介绍,陆金所智能化去 O 平台横跨代码改造到上线切换以及后期运维的全流程自动化保障和落地,其中主要包含的工具有:
Oracle SQL 代码自动转 MySQL SQL 代码工具
O to M 数据字典转化和管理工具
O to M 数据自动迁移和双写工具
去 O 流量一键切换
跨机房一键切换去 O 自愈工具
据王英杰介绍,在陆金所去 Oracle 平台中完成数据迁移的主要过程如下:
首先去 Oracle 平台会解析 Oracle 表结构,并转化成 MySQL 表结构部署到 MySQL 上。之后,Oracle 有任何数据字典变更,去 Oracle 平台都会对 MySQL 进行同步;
将 Oracle 的数据全量同步至 MySQL,因为 Oracle 库还在对外提供服务,所以会记录同步开始时间点,发生过变更的 Oracle 数据;
在全量同步完成后,解析 Oracle 的 redo log,把同步期间发生过变更的数据进行增量追平;
增量追平后,比对 Oracle 和 MySQL 每一笔记录和每一个字段的数据一致性,因为 Oracle 还处在不断更新中,去 Oracle 平台会使用增量补偿重试的方式不断对记录进行一致性校验;
数据完全追平且校验一致后,去 Oracle 平台会开始尝试解析 MySQL binlog,建立从 MySQL 到 Oracle 的数据同步通道;
因为 Oracle to MySQL 和 MySQL to Oracle 的双向数据同步链路都会被自动建立起来,为了防止数据回流,必须区分好是应用层写入的数据还是同步框架写入的数据,确保一份数据无论在 Oracle 还是 MySQL 提交,都会同步到对端,且仅写入一次。
据悉,陆金所核心业务去 Oracle 的时间大约是 6 个月,期间会出现应用中部分表读写流量在 Oracle、部分表读写在 MySQL 的中间状态,而这时陆金所的业务系统还会有大量的功能版本不断上线,如何平衡业务系统的版本上线和去 Oracle 的数据迁移呢?
王英杰表示:“为了降低业务功能改造和去 Oracle 架构改造之间高频交叉上线的风险,陆金所自研的 Bettle 系统实现了业务版本和去 Oracle 版本并行推进,且互相透明的重要功能。”
迁移完成之后,陆金所每 3 个月会通过数据库一键切换平台把全站数据库写库更换一次,一键切换平台在 180 秒完成全站数百套数据库的跨机房切换后,数千张表的 O 和 M 双写同步会自动重建,并确保数据一致性和完整性。
作为去 Oracle 的实践者,王英杰也分享了他在整个实践过程中获得的感悟和经验,希望能对之后想要去 Oracle 的企业有所帮助。
对于严苛的金融系统来说,去 Oracle 是个非常复杂的系统工程,涉及到开发、测试、架构和 DBA 等几乎全部技术部门的通力合作;
整个去 Oracle 改造过程需要在各个阶段都总结出一套完善的方法论,确保各个细节改造工作能稳妥落地;
需要有一套完善的去 Oracle 工具平台来落地整套方法论,让开发、测试和 DBA 在上面开展去 Oracle 工作,通过工具无缝衔接好这些团队在去 Oracle 改造中的协同工作,通过工具确保从代码改造、压测到数据迁移、流量切换等横跨多个团队、长周期的工作风险可控,效果如期。
以上就是今天的内容,希望对你有所帮助。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多
    喜欢该文的人也喜欢 更多

    ×
    ×

    ¥.00

    微信或支付宝扫码支付:

    开通即同意《个图VIP服务协议》

    全部>>