独家揭秘陆金所去Oracle全过程：18个月将90%数据库业务换到MySQL

陆金所目前已经完成全站90%以上的去Oracle工作，并且将在6月底前下线最后一台Oracle。他们是怎么做到的？

在搜集企业去Oracle实践的过程中，我们发现很多企业都会依赖于云厂商或者其它已经去Oracle成功企业的帮助，真正凭借自己力量去Oracle的企业并不多。而今天我们介绍的去Oracle案例，恰恰就是凭借自己力量去Oracle的一家企业，这家企业是陆金所。

陆金所去Oracle实践开始于2018年年中，历时18个月，将全站90%的数据库、数千张表从Oracle无缝切换至MySQL。InfoQ记者为此独家采访陆金所去Oracle实践的负责人王英杰，试图为大家还原全过程。

陆金所的业务场景与去Oracle节奏

陆金所的去Oracle从2018年年中开始启动，涉及大几百个子系统，总数据量超过PB级，去除的Oracle数据库覆盖基金、网贷、信托、资管、银行理财、证 券、保险、主账户等全金融场景，全程使用自动化平台管控和推荐去Oracle实践。

据王英杰介绍，“陆金所全部的研发和技术运营部门都参与了全站去Oracle，至少有500人以上的开发、测试和运维工程师参与其中。”

如果从整个实践过程来看，陆金所去Oracle实践有三个比较关键的阶段：

• 一是通过边缘系统进行方案验证阶段；
• 二是去”O“自动化工具平台构建和优化阶段；
• 三是全自动化标准化去”O“落地阶段。

去Oracle 方案的选择

与大多数企业去Oracle的原因相同，陆金所选择去Oracle也是因为原有的Oracle数据库架构扩展性很差，并且Oracle 软件授权费用太高，无法支撑陆金所从2013年到现在交易量井喷式暴增下的业务需求。

另外，随着陆金所业务逐步扩展为基金、网贷、信托、私募、AI理财、保险、银行等全金融业务线，原来的Oracle数据库不仅在容量上无法支持全金融业务场景，而且在监管上也不一定合规。

在去Oracle之前，陆金所对全站所有应用场景的各个接口和SQL进行了逐一审核，评定替代方案。结果选定了以MySQL作为主替代数据库，同时因为MySQL无法支撑Oracle的所有场景，还引入了Elasticsearch、Redis、TiDB、HBase等多种存储引擎，充分发挥这些存储引擎在各自场景下的优势，从而重构出一个合理的数据库架构来无缝替换Oracle。

陆金所现在的数据库架构

陆金所对于去Oracle的核心诉求是在外部用户不感知的情况下，更换掉核心数据库。因此，陆金所研发了一套数据同步工具，以表为粒度，把MySQL 作为Oracle的备库，实时同步Oracle的DDL和DML变更。同时在应用层实现Oracle和MySQL两套访问数据库的DAO层，以及开关模式的动态数据源，便于流量在Oracle和MySQL之间快速切换，在确保流量切换到MySQL之后，

数据还能够反向向Oracle同步，保证数据一致性。

去Oracle的准备工作：按域拆分

为了顺利完成去Oracle工作，陆金所在2016年到2018年期间进行了数据库的按域拆分。据王英杰介绍，按域拆分的主要目的有三个，分别是：

• 细粒度拆分数据库、分片化，实现数据库容量的水平扩展；
• 应用解耦、服务化，让应用访问数据库的调用更加清晰和规范；
• 严禁应用跨域访问数据库，严禁数据库之间产生数据交互，从业务角度呈现出一个更加完善的数据库架构。

整个按域拆分过程中比较大的难点是大事务拆分和多表关联复杂查询。王英杰表示：“单库上原有的大事务拆分后是通过应用层的分布式事务机制在多库上实现，而单库上原有的多表关联复杂查询在拆分之后，是在应用层实现或在特殊场景中通过分布式存储引擎来支持。”

据了解，陆金所的数据库按域拆分主要有四个关键阶段：

• 应用改造实现逻辑拆分：
  • 按表为粒度对大库的数据库对象进行梳理，把每张表归属于不同的应用域。
  • 在应用层根据梳理的结果对操作表的代码进行改造，包括：
    • 拆分复杂的大查询
    • 拆分庞大的事务
    • 操作表的代码全部封装在属主应用的代码中，非属主应用无法直接操作表，通过调用服务接口的方式实现非常规范的应用访问数据库的调用链。
• 逻辑拆分完成后，以数据库的角度对应用改造的结果进行验证：
  • 在同一个物理库，使用逻辑schema的方式对数据库对象的授权进行调整，验证应用改造符合预期。
• 数据库迁移和实时同步：
  • 逻辑层拆分验证完成后，通过实时同步把待拆分的数据库对象实时同步到另外一个物理库。上述所有改造步骤对应用层无感知。
• 物理拆分和切换流量：
  • 源端和目标端保持实时同步后，在某个时间点推送配置并切换流量。整个过程最好有一套完善的自动化运维确保各个细节工作的无缝落地。流量切换操作，必须确保可以随时前滚和回滚。

去Oracle的具体实践

讲完去Oracle的方案和准备工作之后，接下来我们具体讲讲详细的替代过程。

去Oracle前后的数据库架构差异

在去Oracle之前，陆金所全站的金融OLTP业务场景都是由Oracle支撑的，而完成之后，全部的金融场景是由MySQL支撑，部分Oracle上的大事务也被优化成为了MySQL上的小事务。

值得注意的是，去Oracle完成之后，陆金所中85%的数据库查询请求都是简单的单表查询，15%的关联查询都是比较简单的关联查询，而原先Oracle数据库中包含的复杂业务逻辑的多表关联也做了以下的优化：

• 被拆解成简单查询，在代码层实现部分复杂的关联逻辑；
• 通过陆金所的数据总线平台，把数据实时同步到Elasticsearch里，在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数据完全追平且校验一致后，去Oracle平台会开始尝试解析MySQL binlog，建立从MySQL到Oracle的数据同步通道；
• 因为Oracle to MySQL和MySQL to Oracle的双向数据同步链路都会被自动建立起来，为了防止数据回流，必须区分好是应用层写入的数据还是同步框架写入的数据，确保一份数据无论在Oracle还是MySQL提交，都会同步到对端，且仅写入一次。

据悉，陆金所核心业务去Oracle的时间大约是6个月，在这6个月中会出现应用中部分表读写流量在Oracle、部分表读写在MySQL的中间状态，而这时陆金所的业务系统还会有大量的功能版本不断上线，如何平衡业务系统的版本上线和去Oracle的数据迁移呢？

王英杰表示：“为了降低业务功能改造和去Oracle架构改造之间高频交叉上线的风险，陆金所自研的Bettle系统实现了业务版本和去Oracle版本并行推进，且互相透明的重要功能。”

迁移完成之后，陆金所每3个月会通过数据库一键切换平台把全站数据库写库更换一次，一键切换平台在180秒完成全站数百套数据库的跨机房切换后，数千张表的O和M双写同步会自动重建，并确保数据一致性和完整性。（陆金所跨机房切换的具体实践可以参看InfoQ之前发布的文章《陆金所机房一键切换平台建设》）

经验总结

作为去Oracle的实践者，王英杰也分享了他在整个实践过程中获得的感悟和经验，希望能对之后想要去Oracle的企业有所帮助。

• 对于严苛的金融系统来说，去Oracle是个非常复杂的系统工程，涉及到开发、测试、架构和DBA等几乎全部技术部门的通力合作；
• 整个去Oracle改造过程需要在各个阶段都总结出一套完善的方法论，确保各个细节改造工作能稳妥落地；
• 需要有一套完善的去Oracle工具平台来落地整套方法论，让开发、测试和DBA在上面开展去Oracle工作，通过工具无缝衔接好这些团队在去Oracle改造中的协同工作，通过工具来确保从代码改造、到压测、到数据迁移、到流量切换等横跨多个团队、长周期的工作风险可控，效果如期。

嘉宾介绍：

王英杰，陆金所数据架构团队负责人，负责陆金所全站存储引擎运营和智能化工具研发。