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

本文根据王英杰老师在〖deeplus直播第234期〗线上分享演讲内容整理而成。 （文末有获取本期PPT&回放的方式，不要错过）

 

大家好，我是陆金所数据库团队的负责人王英杰。这次的分享主要集中在陆金所去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之间的响应时间。

 获取本期PPT请添加助手微信：dbachen 

↓点这里可 回看本期直播
阅读原文