随着移动互联网、云计算、大数据等技术的飞速发展，全球数据量和数据并发处理量呈现爆发式增长，远远超出传统关系型数据库的处理能力，再加上‘传统大小型机+高端商用数据库’的采购运维成本昂贵，各行各业迫切需要具备支持海量数据场景下的高性能、高扩展、高可用等关键特征的安全可靠的分布式数据库。尤其是随着我国移动支付的普及和外部形势变化，自主原创的分布式架构研发成为我国数据库技术发展的必然之路，国内关键行业如金融、电信对分布式数据库有着强烈的需求，这也是超越国外数据库的重要机遇。

国内金融行业较早启动国产数据库的应用实践，并已取得了系列成果，尤其是在核心业务系统方面，中信银行是国内股份制银行中率先完成的。当今，国产分布式数据库在国有大行核心业务的实践备受各方关注，其在国有大行的成功实践具有极高的示范价值。

某国有大行在现有分布式计算整体架构基础上，引入GoldenDB分布式数据库解决大行核心业务下移到开放式平台的关键问题，并使用全行实际业务流量进行了长达一年的并网验证；在整个验证过程中，对分布式数据库的功能、性能，数据的流转、迁移，业务的并行双发、结果比对等问题，做了技术攻关和并网实施，确保了实施替代的效果，为下移成功奠定了基础。

银行核心系统的稳定性非常重要，为了确保能够顺利地对主机做替代，需要有两方面的基础保障：1、需要有能够替换原有传统数据库的产品；2. 能准确且完整地验证替代方案是否可行的方法。

该国有大行业务系统按照新系统与老系统按并网方式同步运行，持续观察优化的方式，对开放式架构+分布式数据库进行整体验证。两套系统从应用、平台到数据库，处理流程中都有一些不同，为保障系统能够顺利进行数据迁移，兼容原有业务请求执行。业务平台在验证过程中，需要进行应用功能数据库无关性改造、数据迁移，应用报文缓存双发、开启白名单交易等一系列工作，来保障核心业务系统完整的全链路跟帐比对。而这些动作的前提是让两套系统在一个数据界面之后同步运行。

一、海量数据与短暂停机窗口的矛盾从主机向分布式迁移，需要保留的数据达到200TB级别。为了让新系统能够跟随主机进行业务请求处理，分布式数据库需要从一个截面数据之后，开始进行事务处理。获取200TB的快照数据，按照万兆网卡的传输速度估算，需要70小时。在这个基础上还需要加上数据处理的时间，数据导入的时间。一次性整体迁移需要较大的停机窗口，这在核心业务系统上是不可行的。

二、双方案并行设计、同步验证功能GoldenDB配合客户从性能、可行性以及争取性上考虑，针对性地制定了工具追数方案及基于修改时间的数据迁移方案的两个方案进行同步验证：

（一）、工具追数方案 

图一：基于数据库日志进行迁移

该方案主要有三个操作步骤：

当前主机核心系统利用磁盘复制技术将DB2日志复制到机房B，该机房Q-Rep读取日志文件并写入灾备数据库；

DTS 工具远程调用MQ接口，将当前灾备系统中MQ内的消息旁路一份出来，解析并封装成DTS数据同步工具的格式，同步到工具组件内存储；

DTS工具将存储的记录按事务封装，并对事务之间的关系进行分析与解耦，并发地向目标端GoldenDB数据库写入，写入到目标端的内容为标准DML语句。

该方案需要解决的主要问题包括：一是DTS工具需要解析大机DB2日志；二是DTS工具迁移速度需要大于生产上日志生成速度。

、基于修改时间的数据迁移方案

图二：基于数据快照的数据迁移

该方案分五个主要步骤：

利用生产同城双活的备机，获取全量数据库；

执行第一次数转：在同城基于全量数据库做全量数转文件生成，执行select * from T 将全量数转文件导入分布式数据库，大约N1天完成，记开始时间戳为T1；

重新连接生产与同城数据库，进行数据复制；执行第二次数转，执行select * from T where ts>T1将第一次数转N1天的增量数转文件导入分布式数据库，N2天完成，记开始时间戳为T2；

重新连接生产与同城数据库，进行数据复制；执行第三次数转，执行select * from T where ts>T2将第二次数转N2天的增量数转文件导入分布式数据库，N3小时完成；

在GoldenDB上剔除数据迁移期间主机DB2上删除的数据行。

该方案需要解决的主要问题包括：

主档表，数据量特别大的表都需要有时间戳字段，并要求行数据变更的时候更新时间戳；

对于覆盖更新，没法将数据的删除操作同步过来，对于执行过删除操作的表需要特殊处理。

需要经历多轮数据上下档，上下档的时间决定了方案是否可行。

对于以上两种方案，项目组认真分析了数据迁移过程需要考虑的内容，从实现难度、同步效率、方案可靠性、数据准确性等角度出发，针对性地进行了方案验证，验证内容如下：

对方案一数据迁移工具解析DB2日志的正确性进行验证；对方案一数据迁移工具能否在迁移过程中进行数据调整转换进行验证；对方案一数据迁移工具的效率进行验证；

对方案二全量的迁移时间进行验证；对方案二几轮增量迁移时间进行验证；对方案二的效率以及对业务的影响进行验证。

创新设计进一步匹配应用易用性和产品化要求，最终，项目组通过实际测试验证了方案二的可行性。

方案二通过不断迭代的方式，在尽量减少最终停机时间的同时，允许在每轮迁移过程中对数据做自定义的调整，这些调整由业务自定义，较为复杂无法在方案一的DTS中进行。

同时，针对方案二，GoldenDB数据库从匹配业务场景的角度增加了如下功能和优化：支持以覆盖更新的方式导入数据；支持FTP以及流式传输两种导入方式；支持定长处理的模式，支持按照字节长度处理字段；增加串行重试功能，避免多并发下gap锁导致的死锁问题；增加对字段跳过、补充默认值等功能。这些功能从易用性、稳定性的角度进一步满足了业务迁移的要求，不仅做到了准确的迁移，更是方便的数据迁移。

项目组基于方案二进行了200T全量数据迁移实施，在生产环境上，通过下档的方式，将DB2数据文件以文件方式传到搬迁环境，搬迁环境下档后，将文件装载到分布式数据库。从T日开始实施，经过三轮全量/增量数据迁移，在T+13日完成所有数据到分布式的处理，仅在T+13日利用了常规停机窗口进行了变更，前两次迁移均未申请停机窗口，对生产业务影响降到了最低。

生产系统的数据库切换涉及到的影响面非常大，从数据库装载数据到应用稳定运行之间存在众多流程，每一个步骤都很重要。本文主要挑选了数据迁移这一基本且重要的实践环节，来说明GoldenDB在国有大行核心系统数据库创新实践上所做的工作。

GoldenDB数据库针对异构的数据库类型如DB2、Oracle等，既支持全量的数据迁移也支持增量的数据同步；同时，针对数据需要修改、转换的处理逻辑，也能够提供完善的解决方案。GoldenDB在国有大行核心系统数据库上的迁移实践经验，为其他银行在采用国产数据库转型中数据迁移的关键环节提供了参考依据，为在行业内推广具有较高的示范价值。