共计 4155 个字符，预计需要花费 11 分钟才能阅读完成。
作者：熊浪，安全科技资深数据库架构师，在关系型和非关系型分布式数据库技术畛域具备丰盛的教训，负责安全团体去 O 分布式项目经理，负责分布式数据库选型和架构设计工作。
安全科技是安全团体旗下科技解决方案专家，践行“科技赋能金融、科技驱动生态”的企业使命，赋能团体金融服务、医疗衰弱、汽车服务、智慧城市生态圈建设，致力于成为国内当先的科技公司。
UbiSQL 简介
UbiSQL 这个词对大家来说可能比拟生疏，UbiSQL 是安全团体外部打造的分布式数据库产品，代码基于 TiDB，齐全兼容 TiBD 4.0 版本。在 TiDB 的个性之上，UbiSQL 在稳定性、安全性和应用性下面都做了晋升，打造出一个金融级且内核源码自主可控的分布式数据库，提供一栈式 HTAP 解决方案。
UbiSQL 的布局是提供金融级别的平安能力，比方加密算法、给 TDE 的通明算法做加强，以及集群外部治理的增强。因为后续会减少到上千套集群，咱们对于集群的治理做了增强，监控都做了合并。此外，UbiSQL 提供冷热数据的拆散，反对把集群的冷数据都拆散到 SATA 盘上，从而升高存储老本。
从 Oracle 迁徙到 UbiSQL 的过程
接下来分享一个比拟具体的 Oracle 迁徙实际，这是咱们在安全团体外面做了多年去 O 工作的总结，心愿给到大家借鉴。团体的外围领取零碎迁徙的数据量大略在 8 T 左右，因为都是 rac 节点，为了防止节点之间的相互影响，就把它迁徙到两个 UbiSQL 的实例下面。
图：迁徙前后集群的比照
UbiSQL 的架构是通过 F5 负载平衡，打到三个数据中心的 TiDB 集群下面，F5 在三地机房都有部署，通过 DNS 形式拜访相应 UbiSQL 的实例，在机房 IDC1、IDC2、IDC3 的集群之间通过 UbiSQL 本身的 Raft 协定实现强统一的数据同步，再通过 Drainer 工具进行异步复制，复制到近程的灾备集群。
图：迁徙后的 UbiSQL 架构
首先是迁徙前对于现状的剖析，次要包含三个方面：
数据库的负载以及迁徙 SQL 的金融性、对象，存储过程的剖析，确定是不是都能够迁徙，这部分剖析是 DBA 通过代码的扫描、报告得出的。
利用方面的剖析，应用层须要看新的数据库是不是能适配，能不能兼容利用，理解应用层的构造还有相应的 JDBC 的版本。
关联系统的剖析，Oracle 数据库有很多通过 OGG 或者 ETL、Kettle 或者调用第三方进行同步，接口调用状况也须要做相应的梳理。
接下来基于剖析的后果，做数据库的选型：
抉择 RDBMS 还是选其余的开源数据库或是分布式数据库，咱们须要依据应用层的要求来看，是做到双活，还是做到疾速的扩容，亦或是分布式，而后依据要求来做相应数据库的选型。数据库的架构设计计划，是不是须要做多活，还是 NG 就足够了，也须要依据相应的业务需要做设计。
利用零碎的拆分与解耦计划，确定利用是整个迁徙，还是只迁徙一部分，而后再启动利用的后期革新。
关联数据的同步方案设计，这部分就是 OGG 或者其余 ETL 数据的同步，分布式数据库以及开源的 PG，目前不反对 OGG 为源的，所以须要借助于第三方，比方 Kafka 之类的工具做相应的数据同步。
而后是相应的迁徙计划和回退方案设计，须要做相应的人力布局，还要看一下投入多少人力和老本。
在这些筹备都做完后，咱们就开始搭建数据库、开发环境、测试环境、生产环境。筹备好当前咱们开始做数据的迁徙，将后面梳理进去的一些表构造、对象之类的迁徙到新的 UbiSQL 上，须要波及到表构造的比对和数据的比对，这部分前面会具体介绍。
利用性能的革新和测试是最重要、最外围的局部，开发人员须要对相应的性能、SQL 以及存储过程这方面进行革新，这是整个脱 O 的外围局部，如果存储过程较大，有几十万行之类的，须要评估人力的投入。咱们往年脱 O 的我的项目存储过程大略有 2 万行左右，投入的人力约 10 集体，做了两个月左右，把整体约 100 个 package，全副转换为 java 代码，这块的人力投入是挺大的。这部分做完之后就是应用层性能的全回归测试，校验开发转化的性能是否完全一致，和原来 Oracle 的逻辑是否完全一致。接下来顺次是做利用的性能压测、数据库的压测，而后是相应的迁徙手册。
接下来进入生产施行的阶段，依照理论的状况和计划步骤进行迁徙，可能是“一次迁徙，一次切换”，也可能是“多批次迁徙、逐渐切换”，因为有一些外围零碎的迁徙须要做保障措施，比方切过去不能有任何问题，可能切一些灰度数据过来。后续进入到生产数据库的并行运行阶段，咱们对迁徙后的数据库做相应监控和报告，紧接着下线老的 Oracle 数据库和回滚链路，进行我的项目的总结。
流量复制与回放计划
重点分析一下流量复制和流量回放方面咱们的实现计划。首先，为什么有流量复制和流量回放？流量回放是因为 Oracle 转化为 java 代码后，不晓得这个逻辑对不对，齐全通过测试人员做回归测试，可能测试不全，也有可能遗漏掉很重要的局部，咱们想通过流量回放的计划保障生产业务流量齐全在测试环境做相应的利用。
流量复制是因为能够做压测，把生产的流量间接引入到迁徙之后的环境，而后把流量做到翻倍，翻到两三倍做压测，做完之后还能够在后续外围零碎去 O 下面做反复利用，从而节约了相应的老本和人力。
图：流量复制
流量复制借助的是 F5，或者 Ngnix 的流量，将所有客户端的流量通过 F5 拜访到 Oracle 的环境，也能够在 F5 这一层将流量做镜像，将实时到 F5 的流量转发到应用层，应用层通过拜访 UbiSQL，再通过挡板程序做到相应业务的拜访。整个环节的外围在 F5，所有的流量都要通过 F5，如果没有走 F5 的流量则没有方法抓取到相应 SQL 的调用或者执行。挡板程序则是将所有环境依照生产环境进行调用，如果拜访其余数据库的话，不须要做相应的拜访，在这个中央会有一个挡板程序。这个挡板程序就是间接拜访其余数据库，间接获取后果，不在其余数据库执行，不然会呈现数据凌乱。
图：流量回放计划
流量回放绝对比较复杂，次要是开发同学实现的。次要的实现逻辑，就是通过外围零碎的调用，通过 Traceid 拜访相应的性能点，性能点下面会有一个 Agent，会去把相应调用的状况和参数，调用到哪个接口记录下来，存储到日志平台上。再通过日志平台外面的存储，将这部分存储下来，存储后调用后续领取零碎的 UbiSQL，就能够做到数据的回放。
因为是存储下来，想什么时候调用就能够什么时候去调，这个中央也有相应的挡板程序。做完之后咱们能够做到 Oracle 和 UbiSQL 数据库的比照，因为之前的 SQL 都是一样的，而且是全量的，那么就能够把 Oracle 的数据通过复原的形式复原到某一个工夫点，而后再把 UbiSQL 的数据通过流量回放的形式把那天的数据进行回放，这两边的数据根本就是统一的，再通过数据比对工具比对两边数据是否统一，这样来验证性能是不是完全一致。
流量复制或回放计划通过搭建生产旁路验证环境，在旁路环境进行回退链路的生产级别验证。相比传统数据库回放，这个计划进行利用 + 数据库整体架构层面的验证，升高重大外围业务零碎新技术上线投产危险。并行验证通过后，实现数据迁徙比对后，可间接切换上线，缩小了投产工夫。
数据比照与切换计划
数据切换和数据比对的计划，先看数据比对的局部。迁徙 Oracle 会有一个数据比对的过程，安全团体外部的有一个 Ludbgate 工具能够实现表构造的转化、全量数据的同步、增量数据的同步，还有全量数据的比对，增量数据的比对，它是整个迁徙过程中数据比照的全链路工具。
数据比对大抵的逻辑是，当开始做数据同步的时候，会在日志外面记录相应的日志点，开始全量同步，全量同步实现之后就能够启动增量同步，因为记录了相应的启动工夫点，后续就能够通过这个工夫点做增量同步，在做增量的同时，会在两头的 MySQL 外面创立一个影子表，这个影子表的作用次要是记录过程启动后同步表的所有 dml 操作的主键值。
数据同步实现之后就能够做相应的全量同步，这时所有增量及全量数据始终在一直变动，须要进行全量的比拟，能够基于这个工夫点比对两边的数据，不论是否动态都能够进行比拟。全量比拟次要通过把数据做肯定的分区，首先对表记录做分区划分，用于多过程解决，每个过程依据对应分区的 rowid 去 Oracle 获取对应的记录并算出 md5 值，同时在 UbiSQL 这端获取到这个主键值，并通过查问整个行的数据，计算出 md5 值进行比对，如果比对后果不统一就会存到影子表外面。
全量比对实现之后会启动增量比照，增量比照是每个小时启动一次，会将影子表外面的主键值拿到 Oracle 外面读取相应的记录，计算出 md5 值，再在 UbiSQL 里获取相应记录并计算出 md5 值，而后进行比照，如果统一，将此主键值从影子表中删除，如果不统一，下次在启动的时候会再次做相应比照，这样缩小了比对的工夫，做到最短的停机工夫。
图：数据比照和切换计划
数据的切换计划通过 Oracle Ludbgate 拜访到 UbiSQL 这一端，Oracle 这边有到其余 Oracle OGG 的链路，迁徙是通过局部流量的切换，因为是资费零碎，它须要保障迁徙是齐全的，没有任何问题，波及到钱的问题，大家都感觉比拟麻烦，所以咱们依照切局部用户的形式去做。
咱们依照切大量流量，在利用端做相应的性能开关，去做到大量数据切到 UbiSQL 这边，而后做利用的验证，如果没有问题，流量会一点一点地切到 UbiSQL 这一端。另外它有相应到第三方的同步，会启用到 kafka，同步到其余的 Oracle 数据库。这个计划有一个短板，即不能保障回退的机制，因为写到 UbiSQL 之后，UbiSQL 的新增数据没有方法写回到 Oracle。也就是说回退的时候这部分数据不再被须要。咱们给 TiDB 社区提了相应的需要，是不是能够做到在 TiDB 外面进行用户写入的辨别，这样咱们就能够做到 Oracle 到 TiDB 双向的同步，就不会存在无奈回退的问题。
图：迁徙后性能比照
最初看下迁徙后的性能比照，能够看到，因为都是资费零碎，均匀响应工夫特地短，迁徙到 UbiSQL 后进行了大抵的统计，在执行 Count 语句的时候性能有晋升，在其余的查问或插入性能方面有损耗，然而损耗不大，根本在 10% 以内，利用端是能够承受的。用这套办法咱们迁徙了对立领取、CF2 客户关系零碎以及工作流零碎，这些都是属于安全团体外部比拟外围的业务零碎。
