从 Oracle 到 MySQL，金融核心场景在线换库落地实战

本文由 dbaplus 社群授权转载。

大家好，我是陆金所数据库团队的负责人王英杰。这次的分享主要集中在陆金所去 O 在线换库的技术特点上，之后详细给大家剖析陆金所设计的在线换库方案以及方案如何在一个庞大的金融系统里通过多个团队的紧密配合稳妥落地。

同时还会给大家介绍我们团队自研的一些去 O 工具，它们是怎么确保陆金所长达两年的全站去 O，来帮助方案从开发测试、架构、运维等各个方面有条不紊地推进和落地。

除了去 O 方案外，我还会解答不少业内朋友的疑问——“为什么陆金所会启动这个全站去 O 的项目”，以及分享我们这个项目背景、去 O 前的设定目标等，以供大家去 O 参考。

希望通过这次介绍能让大家更深入地了解，一个金融系统要把 Oracle 这种商业数据库去掉会碰到的难点和风险，并且给想去 O 但是又不敢落地实施的同学提供一些案例实战解决的思路和方法。

一、成果

在完全不做服务降级的情况下，陆金所整个去 O 项目从 2018 年年中启动以来，历时两年已经把全站 98%的数据库从 Oracle 无缝切换到 MySQL 上，这 98%的数据库涉及到陆金所的账务、资金、资产中心以及我们能够想到的金融行业的主要业务场景。

在整个去 O 过程中我们也实现了全程 0 故障、0 风险、对用户几乎不感知，因为我们在凌晨的流量低峰期才进行切换，而在整个切换过程中我们也不会做服务降级，所以整个过程用户也几乎不感知。

陆金所去 O 具备四大特质：

• 无缝： 在线更换底层数据，库完全不做服务降级，让类似去 O 的重大项目改造、架构改造在最终落地实施的时候对外部用户的影响下降到最小，这一部分非常考验研发团队做去 O 架构改造的技术实现能力；

• 稳妥： 把一个非常大的系统拆分成上百层次，再一点一点把数据库替换掉，全程实现 0 故障、0 风险。在过去两年，陆金所没有因为去 O 而引发任何生产事故，所以说这一块在考验团队研发能力的同时也考验去 O 落地工具的设计和研发水平；

• 高效： 短短两年就完成数据库 98%的去 O 落地，最后 2%也会在 9 月之前全部做完，也就是说在 Q3，陆金所的数据库都会完成去 Oracle 化，整个推进速度还是比较快的；

• 智能： 借助去 O 对陆金所整个生产环境的架构实现比较大范围的重构，实现从开发到测试再到运维自研各种落地智能工具，来把控去 O 各个核心环节的质量，真正对一个庞大复杂、对架构改造来说风险较大的金融核心系统做到大幅度落地去 O。

在这个过程中也大幅度降低了去 O 过程中投入的人力成本，借助经验和辅助工具，在前期提前设计、规划好整个流程，在后期整个研发团队按照规划按部就班地推进，研发投入有了一定可控性。

在去 O 完成以后，也没有因为切换 MySQL 而增加特殊招聘的成本，整个运维团队也跟着实现了从 Oracle 到 MySQL 的转型，在人力成本方面做到了完全可控。

二、背景

1、为什么要启动全站 100%去 O 的项目

为什么我们要启动全站去 O 这个项目，我们在立项之初希望通过去 O 对整个陆金所的研发有三方面的提升。

1）降低运营成本

成本是个非常现实的问题。如果一个金融系统增长的速度很快，体量已经到了一定规模的时候，能够把 IOE 去掉的话，能够很大程度降低运营成本，这一点是非常肯定的。也就是说，一个金融系统越大，它越能完成去 IOE 的话，对降低运营成本的提升也会非常大。

2013 到 2018 年期间，陆金所的业务呈现快速增长的趋势，业务拓展了上百倍，在这种业务体量增长的情况下，我们继续使用传统的 IOE 设备的话对数据库运维成本来说是非常大的挑战。就算我们仅仅把 I、E 去掉，使用 X86 + Oracle 的存储架构、前台也做细粒度的拆分，Oracle 的实例还是会很多，而全都购买 Oracle 实例的软件数对公司成本来说也是非常高的。

所以说评估下来，无论是在 IOE 还是 X86+Oracle 的架构，一个金融系统在业务量迅速增长的情况下，数据库运营成本都是非常高的。

2）摆脱技术绑架

其次很重要的一点是，我们想通过去 O 打造一个不依赖特定数据库特性的金融交易系统。

如果我们能够做到这一点，就可以彻底摆脱被商业数据库厂商技术绑架的风险。也就是说，我们希望通过去 O 对我们生产环境的系统进行大规模的重构，包括水平拆分、应用层服务化改造等一系列操作。

很多传统金融行业的系统都非常依赖数据库这个角色，包括利用数据库的存储过程、一些特有特性来确保金融场景的业务，甚至整个数据库的高可用也是通过硬件层面来实现的。

所以我们就想通过去 O、使用最廉价的 X86 服务器，把数据库的角色转化为只支持最基本的增、删、改、查的存储引擎，涉及把原本由数据库实现的一些特性往上移，移到应用层和服务层来进行实现，这也是我们希望通过去 O 来实现的一个目标。

这样我们可以做到把传统金融的数据库承担的大量的业务逻辑和架构属性从数据库这个层面剥离出来，数据库层承担的角色就会更加简单和单一，以至降低整个运维层面的风险和难度。

3）提升研发能力

除了在运营和架构上会有一个很大的提升以外，我们也希望通过全站去 O 这个涉及到开发、测试、架构和 DBA 等全研发团队都参与的一个重大架构改造项目，来锻炼整个研发团队，提升研发能力。

在陆金所去 O 之前，整个系统会更偏向传统金融系统。而且它本身也有一些在历史上的架构设计不完善的问题，我们也希望通过去 O 来实现数据库的拆分、微服务化、分布式事务改造的架构工作，同时锻炼我们研发团队的能力。

以上主要就是陆金所最开始为去 O 制定的一些研发目标和相关的研发任务，后面的介绍的话也会围绕着我们通过解决这三个方面而最终实现了什么效果，给大家详细进行展开。

2、为什么选择 MySQL，但不仅仅是 MySQL

在去 O 之前需要对数据库进行选型，如果把 Oracle 替换掉的话我们要选择什么数据库来承载 Oracle 的流量呢？在这个过程中我们会从功能、资源、案例和压测这四个方面对后续选型进行通篇的考虑。

1）功能和性能

首先我们要评估能承接 Oracle 的数据库各种场景下的计算和 IO 能力。

2）资源

非常重要的是它必须具备非常广泛的社区资源、技术资料、问题处理案例（包括成功和踩坑的经验），这些都是我们评估替换的存储引擎非常重要的因素。

还有一点就是，它要有比较广泛的用户基础，方便我们技术栈后续转型时招聘对应的开发和运维工程师能有更大的选择。

3）案例

在整个行业，特别是金融场景下有比较好的参考案例。国内比较大的互联网公司之前在去 O 方面也给了我们一些好的成功案例以去借鉴和参考。

4）压测

最终在确定之后，陆金所上线之前会通过非常严格的压测环境，把一些想用的存储引擎使用生产环境最真实的数据在陆金所核心应用、核心接口反反复复进行压测，并且得到最终的压测数据，与生产环境的 Oracle 数据库的性能表现做对比以得到最终的评估。

陆金所在切换任何一张表流量的时候，我们都会使用生产环境最真实的数据进行 Oracle 和 MySQL 的压测，最终的压测结果还是非常不错的。我们发现在之前使用 Oracle 11.2 在 sql 语句的话 sql 接口比较简单，区分度和选择性又很高的情况下，其实 Oracle 和 MySQL 在性能上没有太大差别。而且我们也发现了，MySQL 在一些特性，特别是在并行复制上，它的性能和表现比我们想象中的更好。

所以我们在两年前对 MySQL 5.7 进行多能压测以后，最终选定使用 MySQL5.7 成为我们去 O 的主要存储引擎。它在去 O 上主要承接所有与事务相关的写入，还有和用户的交互，金融层面上的订单、交易、账户、资产、资金的数据写入。

Oracle 实际上是一个非常好的数据库，它能覆盖非常全面的场景。很多传统型公司，无论是前台交易库还是后台的数据仓库，都会选择使用 Oracle。它在 OLTP 和 OLAP 场景下表现得都非常优秀，但是要把 Oracle 所有的计算场景全都承接下来的话，光使用 MySQL 是不够的。所以在这个过程中，我们也想借助去 O 的这个机会对生产环境引入更多的存储引擎，让它们在最合适的使用场景下发挥最大价值。

在使用过程中我们发现，实际效果还是不错的。基本上很多存储引擎都是开源系统，成本很低，而且在一些特定场景下的性能和处理速度比 Oracle 更快，所以最终选型决定了以 MySQL 为主，以 TiDB、Redis、ES、HBase 等存储引擎为辅的方式。

我们在去 O 的过程中不仅仅是去掉 Oracle，我们也根据不同使用场景来引入更多的主流存储引擎。

三、方案

1、去 O 双写和切换方案

本次介绍特别重要的技术亮点是在线换库，图中左方是在线替换 Oracle 的主要架构图。

应用层面：

说到核心思路，在应用层面上看，Oracle 和 MySQL 两套防御数据库的 DAL 层实现双写，中间有一个流量开关用于控制业务逻辑是走和 Oracle 相关的这一块还是和 MySQL 相关的这一块。

而且在去 O 的时候会有一个整体的规划，很重要的一点是要把一个特别大的系统拆分成多个独立落地的批次。有些像交易、资产中心的系统做底层服务，上面被关联、调用到的系统会很多。

在去 O 过程中的某一个晚上，把特别大的流量从 Oracle 迁移到 MySQL 的风险是非常高的，所以我们在去 O 的过程中会拆分成特别小的批次，而且每一个小的批次做到每一次变更的风险、改造的工作量和难度都在可控范围内。基于这个方式，我们把一个应用系统拆分成多个批次以后，会在应用层面将业务逻辑层面进行上移。

这个时候，我的业务逻辑层面无论是仿 Oracle 还是 MySQL 都是同样的一套，只是最终是由流量开关来决定流量从 Oracle 的 DAL 层走还是从 MySQL 的 DAL 层走，每一个批次都会有专属的流量开关来进行控制。

数据库层面：

在整个改造的过程中，会涉及应用版本的发布。应用在发版的过程中会不断将流量开关发布上线，包括和 Oracle 对等的 MySQL 的代码也一起发布上线。

在发版的过程中 Oracle 数据库并没有发生变化，同时它还在对外提供服务。这个时候我们会在 Oracle 后面建立一个实时数据同步的 MySQL 数据库。

假设 Oracle 这边有一笔事务提交，它会以秒级的速度往 MySQL 数据库进行同步。在这个过程中，大家可以将整个架构理解为，Oracle 后面挂了一个秒级实时同步的备库。

根据这套框架，陆金所研发了一套自动化的双建框架，如果我们的 Oracle 数据库需要去 O，系统流程如下：

• 确定好批次，框定需要去 O 的表的批次再在系统中勾选好 ；

• 系统会对这些批次的表中的数据做全量增量 ，包括双向同步的建立，都在后台自动完成。这样是把整个运维层面、数据库层面等需要人为介入的工作都通过自动化的方式来完成；

• 等待应用版本发布上线以后进行流量切换 。其中设置了一个总控开关控制从应用到数据库，从到 Oracle 到 MySQL 数据同步的整个流向，从而进行全盘切换；

• 最后实现 Oracle 的数据实时同步到 MySQL 。在流量切换的瞬间，可以做到当这笔事务在 Oracle 成功提交且同步到 MySQL 以后，确保在 MySQL 中也成功提交了的话后台会对这笔事务进行最后一次质量校验，校验后才会将流量从 Oracle 切换到 MySQL，全程由流量开关控制整个过程。在这个过程中的步骤比较复杂，无论是哪一步出了问题，总控开关都可以让整个流量切换过程回到最开始的原点。这个过程类似于 Oracle 数据库里的在线重定义，不同的是在线重定义是 Oracle 的一张表到 Oracle 的另一张表，是从 Oracle 到 MySQL，并且流量切换到了 MySQL 以后会把流量进行反向同步。

2、应用流量在 O 和 M 之间快速切换

接下来介绍整个流量切换的三个状态，在图中这三个状态描写得比较简单，在真正的实际操作中大约会有 16 个步骤，但整个流程会在 10 秒内落地完成：

• 初始状态 ：最开始所有的流量会从 Oracle 到同步到 MySQL，这时候还是由 Oracle 提供服务；

• 中间状态 ：切换时，在确保 Oracle 上的最后一笔数据提交成功且同步到 MySQL 以后，完成最后一笔增量比对。在这个过程中，Oracle 和 MySQL 的写服务会短暂地处于不可用状态，为了确保 Oracle 同步到 MySQL 的最后一点数据都没有问题，所以整个过程非常快速。我们实践中完成上百个批次的切换，平均单个批次 4 秒钟；

• 完成状态 ：最后把 MySQL 的写开关打开，几乎所有流量在 MySQL 上且从 MySQL 上写入，之后数据会反向从 MySQL 同步到 Oracle。在整个流量切换的过程中，反向同步是为了避免切换过去后 20%-30%概率的应用问题，比如运用上的 bug，或者说接口性能不符合预期，这种时候就要往回切。

• 往回切时，MySQL 在完成切换的时间点就已经开始对外提供服务了。所以这时要确保 Oracle 和 MySQL 的数据一致性，必须确保在 MySQL 写入的数据实时反向同步到了 Oracle。在切换过去之后，一旦主库从 Oracle 变成了 MySQL，MySQL 的数据就要反向同步回 Oracle，它就变成了一个备库，所以保证两个数据库中的数据一致非常重要；

• 万一切换到 MySQL 的时候出现问题，在 10 秒之内整个流量会从 MySQL 再往 Oracle 切。这个过程中，无论走到哪一步都要确保 Oracle 和 MySQL 的数据一致，其中任何一步出错，都可以快速回滚到最开始的状态。如果整个切换流程结束，但是 MySQL 那边的数据出现问题，也可以快速往 Oracle 回切。

3、适用于金融核心系统的稳妥去 O 推进方案

接下来分享的是大家在去 O 过程中的一个 痛点 ：我们对大规模的系统进行去 O 改造，到底要从哪里入手？怎么做才能将系统风险降到最低而且全程可控？

这个痛点也是非常重要的一点，上面说到过陆金所很多系统的规模都很大，我们就会将其拆分成很多个批次。图中显示的是拆分成的 3 个批次，但在一些更大的系统当中，会被拆分成 15 个以上的批次，整个持续改造的时间超过 12 个月，我们在很长的时间里应用将数据一点一点地从 Oracle 切换到 MySQL。

这整个过程可以总结为： 以表为粒度建立批次，以批次为单位推进去 O 落地 。那我们为什么要这么做呢？

• 如果以表为粒度，把一个包括了庞大金融系统的阀拆分成多个批次的话，我们只要把跟业务、事务相关的表放在同一个批次下，就可以确保在做去 O 改造的过程中单个批次的改造难度、上线进度、切换风险是可控的。这样，我们就把一个需要花费高时间、人力成本要做去 O 的核心系统，通过拆分降低成本，每一次做变更和上线发版的时候就只用对其中的一部分表做去 O，而且整个推进的过程中单个去 O 版本里需要改造的内容也非常少。如果这个批次在改造过程中有些问题，拆分批次的操作也会将全站的风险降到最小；

• 另外，如果在这个批次足够小的情况下，去开发进行去 O 改造，也可以快速落地和推进到生产环节；

• 最后进行相关流量的切换。因为整个流量切换的过程不做服务降级，那么单个批次切换的表越小，单个切换的瞬间对系统造成的影响就会越小。

刚才说的就是一个 “小步快跑”高速迭代 的过程，我们按照这个原则进行操作。图中可以看到，应用层上不断有版本发布，以下是我们实践中的操作流程：

• 将大系统拆分成多个批次；

• 逐步对这些批次进行去 O 改造；

• 在做去 O 改造的过程中将整个业务逻辑层往上移；

• 之后完成 Oracle 和 MySQL 两边的流量开关、DAL 层相关的代码的改造工作；

• 持续做版本发布。

整个过程中 Oracle 持续对外提供服务。版本上线后运维会进行测试，之后整个数据库的双写机制就会通过自动化运维体系建立起来。

我们在图中看到，Oracle 和 MySQL 是完全对等的关系，但实际上 Oracle 上 IOE 设备的比例非常重，在拆分的过程中不同的表会往不同的 X86 服务器去拆。我们以表为粒度就实现了数据库的架构拆分的相关工作。

按照这个维度一点点地进行拆分，只要这张表要上线和切换，我们在后台完全建立起这套同步机制之后，就等待应用上线完成。从应用 1.0 版本到 1.1、1.2，最后到应用 1.3 的版本，应用不断迭代发版。

每上线一个版本后台中就会切换一个批次，这个批次从 Oracle 切到 MySQL 只会涉及少量部分的表，切换过去没有问题的话就会在生产环境中不断地跑。如果有问题的话再把它再从 Oracle 往 MySQL 进行回切。整个过程按这种思路来落地和推进的话会非常稳妥。

但是这个过程需要运维团队有足够好的工具进行支撑，才能顺利完成。可以从图中看到，整个过程中有一些应用改造所需要的时间跨度很长，比如说持续超过一年，会有十几个批次需要进行去 O 改造。

第一张表从 Oracle 往 MySQL 切的时候，整个应用的服务会由两个数据库同时对外提供服务，在这个过程中就涉及到了在做版本发布的时候的很多问题。

比如，要发哪个表？加哪个字段的时候要加哪个表？是加 Oracle 还是 MySQL？是先加 Oracle 还是先加 MySQL？这个过程包括了后续相关的运维操作，所以这部分首先需要一整套完善的自动化运维体系来确保这个操作框架顺利推进，同时保证我们在长时间的去 O 改造过程中，以 Oracle 和 MySQL 作为一个应用同时提供服务的时候，每天高频上线的所有版本和数据库变更都不会出任何问题。

以陆金所为例，我们采用了这套框架来推进去 O 改造，我们很多核心系统的改造基本上花费 12 个月或以上，基本上一点点地把 Oracle 数据库给替换掉。并且整个过程是完全不做服务降级的，所以对陆金所 4500 万多用户来说几乎无感知。

四、目标 / 效果

1、通过去 O 大幅降低运营成本

1）去 O 前

陆金所去 O 之前使用的都是 IOE 设备，数据库的量不多、也没有进行服务化的改造。那个时候的架构就是一个比较传统的金融架构，很多应用向一个比较大的 Oracle 数据库进行访问。DBA 团队每天的工作就做好几个核心数据库的预用。

做完去 O 之后的架构没有了 IOE 的设备，通过普通的 MySQL+X86 服务器支撑起陆金所整个的数据库架构。由于 X86 服务器的价格非常低，从投入成本方面来说，每年的运营成本大幅度下降，整个数据库软硬件的采购成本下降至不到之前采购成本的百分之十。

整个去 O 过程持续两年左右，让我们团队对人员的要求有了全方位的变化，因为后续自动化运维体系和 MySQL 的运维都需要有一整套相对完善的自动化运维工具用作支撑。

而且去 O 过程中两个数据库之间会有长达一年的双写过程，整个版本在发布和日常数据库变更中是完全不能出现问题的，所以这个工作必须通过自动化来完成。如果通过人为介入完成双写，在上线之后在很多细节问题上有很大几率会出错，所以我们在这过程中就运用了一套强大的 CMDB 和数据库的运维体系进行支撑。

2）去 O 后

完成去 O 之后，陆金所整体的架构变得非常清晰，同时我们也通过去 O 完成了服务化改造。

这样，我们各个核心的业务模块都以微服务化驱动的方式形成一个分布式的相关架构，而且每个服务都有自己的应用和数据库，每个数据库在完成去 O 和服务化改造之后只给服务内的应用提供直接访问。

如果非服务内的应用想直接访问数据库的话，我们会通过配置中心进行配置，它们是完全没有相关访问权限的；如果服务之外的应用想要访问数据库的话，必须走应用层提供的相关服务接口，这样就避免了跨服务器直接访问数据库。

整个服务访问分为同步调用和相关异步调用。如果服务比较大，在服务内部我们就会对数据库进行水平拓展；如果是类似用户、交易、资金这种公共类服务，后续它们会陆续迭代成一些比较大的中台服务。

通过整个去 O 的过程，陆金所整个 IT 的架构就变成集中式的大库和 MySQL 的小库。之后如果对容量有扩展的需求，我们还可以对这套架构进行更细粒度的拆分，可以呈现数据库水平扩展。

2、通过去 O 在架构上大幅优化

完成去 O 之后，我们实现了数据库层面的几个特性：

• 去中心化 ：在去 O 之前，陆金所的几套大库如果任何一套出现问题，都会对陆金所的全站可用率产生影响。而拆分到 MySQL 之后，MySQL 跑到 X86 上，X86 的硬件可用率比之前存储盒小型机的时候差很多，所以在 MySQL 这部分会做更细粒度的拆分。对单个 MySQL 数据库来说，拆分之后一旦出现故障、需要切换的时候，对全站可用率的影响完全可控。实现这套框架后，我们也可以把不同的 MySQL 布置在不同的机房，在网络调用可控的情况下，实现真正意义上的机房多活；

• 弹性扩容；

• 应用层的服务化拆分；

• 应用访问数据库的规范化落地。

3、通过去 O 在各种不同场景引入最合适的存储引擎

陆金所在去 O 前对存储引擎进行了架构选型，涉及到架构选型的时候会支持哪些业务场景、通过哪些数据库承接。

去 O 不仅仅是流量去到 MySQL，因为 MySQL 无法承接 Oracle 的全部流量，所以需要特别考虑下面几种场景的流程承接方案：

• Oracle 当中少量 hash join 查询场景： 这些在 OLTP 场景下的查询的 qps 不大，Oracle 处理这种查询相对比较得心应手，而在 MySQL 5.7 下完全无法处理这种查询；

• Oracle 中多表关联和多层复杂嵌套查询场景；

• 在 MySQL 细粒度拆分后，跨库、跨分片的查询场景；

• 在 MySQL 集群和 Hadoop 集群之间构建一个秒级数据同步的 ODS 层。

为了解决以上问题，我们引用了一些新的存储引擎，发现它们在合适的场景下替换 Oracle 产生的效果不仅比 IOE 的成本更低、性能更快。

五、场景

使用 TiDB 承接 Oracle 流量：

六、落地

1、应该如何落地呢

左边是一套传统的金融架构系统框架，那么怎样变成右边这一套做过 I 域拆分、水平分片、去 O 改造的一套陆金所系统架构？PPT 里画得比较简单，在实际生产环境中系统还在对外提供服务的时候，我们应该怎样对一个 7*24 小时的金融核心系统进行这么大的架构改造呢？

这本身就是一个高风险的工作。我们在过程中要做到规避风险，又确保各种工程实现细节有效落地，还同时保证系统的业务连续性，甚至是对外部用户几乎不感知。

2、理解去 O 这类架构改造的本质

3、建立起强大的去 O 风控系统

4、有效支持多团队协同配合

5、陆金所去 O 的落地节奏

七、写在最后

比起降低成本，陆金所去 O 收益更大的是整个研发团队的提升：

去 O 的细节内容除了数据库外，还会涉及：

• 去 O 的架构改造方案

• 去 O 中间件

• 去 O 的开发规范和开发技巧

• 如何进行去 O 压测

• 去 O 的运维变更方案

• 去 O 工具

通过全站系统的去 O 落地实践，我们对去 O 改造各个阶段中需要谨慎处理哪些细节，规避什么风险都有了一定的研究和积累。

Q & A

Q1： 这里的数据同步用的工具是什么？ Oracle 和 MySQL 间数据如何实时同步 ？事务提交是否要在 Oracle 和 MySQL 双提交交易才返回？ 最后一步交易如何识别？

A： 数据同步是使用陆金所自研的同步工具，原理是解析 Oracle 的 redolog 和 MySQL 的 binlog 来实现 O 和 M 之间的双向同步，要特别注意解决循环写入的问题。事务只要在当前的写流量所在的写库提交即返回事务成功响应。以 CAP 的方式来看待这个方案，可以理解为在数据同步双写阶段是一个确保 AP 模式的分布式架构，在写流量切换的一瞬间切换为 CP 模式，切换完成后又恢复到 AP 模式。目标是确保以异步方式实现双写，不要因为双写同步而影响生产的写流量。

Q2： 前后数据库服务器的数量增加了多少？

A： 因为服务化和分片改造，去 O 后 MySQL 的实例数量大概是 Oracle 的 5 到 10 倍之间。

Q3： 存储过程是如何处理的？全部转移到应用端处理吗？

A： 存储过程的业务逻辑在应用层通过 java 重构，存储过程的数据库交互操作在应用 DAL 层实现，SQL 写在 mybatis 里。

Q4： 这个切换的批次是如何划分的？有什么方法吗？

A： 按在业务和服务尽可能的拆分小，让单个批次的去 O 改造工作量和变更风险足够可控。

Q5： 单个微服务 MySQL 采用什么高可用架构?

A： 一主多从，两地三中心，MHA。

Q6： 选型时有考虑 PostgreSQL 吗？

A： PGSQL 这几年成长很快，但目前找到顶尖的 PGSQL 工程师相对 MySQL 工程师会更难。同时金融场景使用 MySQL 重构在一线互联网公司有更多的落地，所以我们选择了使用 MySQL 来替换 Oracle 中的事务写入场景。未来我们会在陆金所生产环境使用更多的 PGSQL 来承接流量。

Q7： 有运行在国产处理器平台的数据吗？

A： 国产处理器评估中，未来会采用。

Q8： 异地机房数据同步怎么做的？

A： 使用 MySQL 原生的主备同步模式。

Q9： 在保证 Oracle 与 MySQL 写保持一致时，对前端业务会有影响吧？有多大影响？

A： 切换期间写操作会有瞬间抖动，抖动持续几秒后恢复，写接口具备重试能力且批次拆分的足够小，对外部用户几乎不感知。

Q10： 是否全部是 community 版本？分库分表使用现有中间件还是自研的？

A： Percona 分支版本，自研中间件。

Q11： 请问自动化管理工具是用什么开发的？

A： Python，涉及到运维和开发两个板块。

Q12： 请问你们的异步消息总线用的什么？

A： 自研的日志解析器+消息中间件+管理平台。

Q13： 切换到 MySQL 后，同城双活架构（数据层双活）变成怎么样的？

A： 基于数据路由层+数据库分片架构实施。

Q14： Oracle redolog 解析是用的开源工具还是自研工具？

A： 自研。

Q15： 对于有关联的业务查询，拆分细了如何解决？有时关联操作的代价太大了。

A： 先做服务化改造，数据库对象仅提供给服务内的应用访问，服务之外的应用不能直接访问数据库对象。这是去 O 改造的基础。

Q16： 传统行业的存储过程是怎么处理的？

A： 具体问题具体分析，功能拆分、服务化、数据库拆分是重点工作，在这个过程中实现去存储过程、去 O。

Q17： 双写的功能可以开发，但切到 MySQL 之后，如何评估它是否能支撑原来 Oracle 的高并发业务？或者说，压测如何模拟实际业务的流量？

A： 在切换之前要进行严格的压力测试，压测数据库的数据来源于生产脱敏，确保数据量和数据分布和生产一致。压测需要覆盖每一个去 O 接口，开发和 DBA 需要自动或人工审核每一笔改造的 SQL 执行计划，压测需要得到所有接口和 SQL 在 O 和 M 之间的响应时间。

作者介绍：

王英杰，陆金所数据架构团队负责人

• 陆金所数据库团队负责人，主导和见证了陆金所数据库和大数据平台全程的建设和演进过程。

原文链接：

从Oracle到MySQL，金融核心场景在线换库落地实战