随着数据库技术与高速网络通信、云计算、人工智能等信息技术的不断深化融合，数据库和应用系统的存在形式愈发丰富，数据库技术生态呈现上云、开源和分布式的趋势。数据库之间的相互迁移已成为常态化，从同构到异构数据库之间的迁移，从数据到数据及应用系统的迁移，从本地间到上云迁移，迁移的表现方式不一而足。近年来，应用对底层数据的要求越来越多样化和复杂化，伴随企业日益增长的数据处理分析和丰富的应用场景需求，不论是企业数字化转型，还是IT系统上云搬迁，亦或是数据库产品变更，都可能涉及从原有数据库向分布式数据库的迁移。目前，针对此领域指导性流程指南的发展仍在起步阶段。 分布式数据库迁移的目的是保证原有业务逻辑不变，仅变更支持系统运行的数据库，因此原有数据无损，原有业务不变，原有的用户体验提升是数据库迁移的最基本原则。从技术层看，数据库迁移的本质即两个数据库系统间的比较与转换，通常情况下，应用系统越简单，使用数据库特性越少，迁移越容易；反之，则困难得多。分布式数据库迁移是个复杂的系统工程，迁移成功与否除了需要技术保障外还依赖各环节的有序组织，即多应方用的系积统极使配用合方、应用开发测试团队和数据库厂商等多方的积极配合。目前，行业缺乏指导性工程方法和配套工具，同时存在迁移成本居高不下、迁移风险较高等问题。
分布式数据库迁移需要完备的规划方案和谨慎的实施操作，迁移的前中后期稍有不慎，就会导致迁移失败，丢失宝贵数据，甚至造成系统混乱、业务中断等灾难性后果。针对整个迁移工作中不同阶段的实际情况，下面列举了一些应当特别注意的痛点。
按照迁移各阶段的场景，迁移的痛点可以分为以下8类。 （1）源数据库与应用调研的痛点，如源数据库使用的特定开发接口在目标数据库是否兼容、应用系统架构和数据库系统之间的关系梳理是否困难、原应用是否绑定了某些特性。 （2）兼容性评估和风险评估的痛点，如源数据库到目标数据库迁移有多少不兼容的语法、对象等；数据库对象兼容性问题的确认存在不同数据库之间库、表改造难度的判定；目标数据库的可用性、性能是否能够满足原应用的需求；如何科学评估迁移的成本及工作量。（3）可行性验证的痛点，如核心业务系统迁移，怎样制定不停机或尽可能少停机的迁移方案；数据库、应用改造工作量巨大，怎样通过工具或产品实现半自动化或自动化改造。（4）全面业务改造的痛点，如应用改造和目标数据库改造的分工可能不明确；由于考虑不周，全面业务改造可能存在遗漏，只完成部分业务改造。 （5）迁移执行的痛点，如迁移的时间窗口能否满足；数据量较大如何实现快速、准确迁移；需要迁移的系统较多时，能否借助自动化工具实现迁移。（6）业务验证的痛点，如业务验证是否能够覆盖全面功能；业务连续性是否能够满足需求。（7）上线割接的痛点，是否能够在时间窗口内顺利完成迁移割接；能否保证数据回流一段时间，以防止割接后应用异常需要回退。 （8）护航保障的痛点，迁移完成后如果存在多种数据库架构，是否能实现数据库同步；数据库性能监控及保障如何快速响应。 第一，数据库产品的不同导致执行相同业务所需资源可能存在差异，源、目标数据库支持相同业务的资源成本需要尽可能精准的评估，否则目标数据库可能无法承载源数据库的负载业务；第二，数据库种存在较多显、隐式转换时，不同数据库可能存在不同类型的转换规则；第三，不同数据库时间日期类型的格式可能存在差异，对于时间格式要求比较敏感的业务，需要对时间格式进行充分测试；第四，数据库之间的数据类型默认长度可能存在差异，同名函数可能存在功能不同的现象；第五，应用开发框架使用的数据库方言包可能存在差异。迁移过程中需要使用与目标数据库适配的方言包，使用不适配的方言包可能导致应用无法运行。此时可通过嵌入业务模块代码的方法，绕过方言包。 分布式数据库迁移的工程按照进度可以划分为前期规划、中期实施和后期运维3个阶段，具体可以分为源数据库及应用系统调研、兼容性和风险评估、可行性验证、全面业务改造、全面业务测试、割接演练、迁移执行、业务验证、正式割接和护航保障10个关键环节（见图1）。源数据库及应用系统调研有助于后续深入评估改造点和工作量，有利于定位系统迁移过程中的难点和风险，其调研内容可以分为源数据库、应用系统、数据库和应用系统3个方面。 （1）源数据库调研：需要考虑数据库结构、数据类型、数据库性能、数据使用场景4部分基础数据。数据库结构和数据类型是静态数据，可以通过语法、语义比对完成调研；数据库性能和数据使用场景是动态数据，与其对应的业务属性、数据库硬件资源、数据库自有能力、数据属性和应用系统属性直接相关。 （2）应用系统调研：主要是发现应用和数据库之间的调用关系和调用方式，厘清应用各个模块与数据库调用SQL的兼容特点，明确应用在各个模块转换的改造点。通过调用SQL详情实现改造点定位，即交互SQL点定位。 （3）数据库与应用系统调研：数据库与应用系统的关联关系通常包含但不限于数据复制链路、API结构调用、DBlink链路等内容，其架构关系的梳理是迁移流程的重中之重，需要投入大量人力物力。掌握源数据库和应用的结构、架构、性能、关系拓扑，有助于后续决策。 调研完成后，进入兼容性和风险评估环节。兼容性评估工作宜从结构语法分析、结构语义分析、上下文环境兼容分析几方面进行；风险评估工作主要包括目标库性能风险、数据一致性风险、应用改造风险、时间窗口风险和上线误操作风险五大方面。充分调研和评估后，迁移工程进入到可行性验证环节，即POC测试。其流程可划分为4个阶段：其一，选取业务中典型的交易模块，制定POC测试内容；其二，准备、部署POC测试环境；其三，根据POC预设，完成测试需求；其四，POC测试总结。针对分布式数据库的特性，在可行性验证过程中需重点关注几个方面：其一，异常场景下事务是否一致；其二，异常场景下副本是否一致；其三，异常场景下大批量已提交事务回滚是否对系统有影响；其四，锁冲突较多的场景下是否对系统有影响；其五，副本数据的时延是否满足系统要求。验证结束后，需出具可行性验证报告，说明应用系统迁移至分布式数据库是否可行，以及相关注意事项，为后续迁移工作打好基础。改造工作繁琐，需要对业务逻辑、应用程序、源和目标数据库相关语法规则进行深入了解，为保证改造有效进行，宜遵循3个原则：其一，业务改造过程中需要谨慎地规划以及选取良好的方法，结合数据库产品自身技术特点，进行一系列数据库及应用程序的调整；其二，业务改造宜遵循从宏观到微观、从整体到局部、自顶向下的方式；其三，宜遵循先实现再调优的原则，性能调优需根据实际软硬件环境和业务场景，一次或者多次调整。业务改造可以从几个方面依次进行：首先是数据类型，目标数据类型范围和精度应不小于源数据类型，以确保业务数据不会丢失，且目标数据类型范围和精度应避免超大于源数据类型，以免带来性能下降。其次是函数，改造场景可能会遇到函数同名，但在源数据库和目标数据库功能不同或不完全相同；函数同名，但参数隐式转换规则不同；函数同名，但参数个数或者参数类型不同；函数不同名，但功能相同；无对应函数，需通过其他方式实现。最后是语法规则，除了应当遵循ANSI或ISO的SQL标准语法，数据库方言的使用难以避免，因此需要将源数据库自身支持的语法规则调整为目标数据库的语法规则。测试环节是迁移关键环节的重中之重，需要投入大量的时间和资源，稍有不慎，可能会导致后续的迁移失败、数据丢失甚至是业务中断、混乱的灾难性后果。全面业务测试通常包含功能测试、性能测试、稳定性测试、可靠性测试、扩展能力测试、安全能力测试、回退方案验证等。测试环节的典型测试类型及测试项如表1~表4所示。 割接演练是针对正式迁移前，模拟真实上线环境下，对系统进行的压力测试和破坏性测试，主要分为割接方案制定、压力测试和破坏性测试、测试总结、新旧系统同步互备和切换演练5部分。割接方案中应包含系统备份方案、应急预案、回退方案，明确割接的操作步骤、操作时间和操作人员，对新系统实施压力测试和破坏性测试，模拟在最极端环境下新系统功能的完整性、稳定性和高可靠性。正式割接前的备份工作必不可少，在新环境上线前务必做好旧程序包的保留和数据同步，以便在紧急情况可以快速回退。切换演练需制定切换检查清单，演练期间严密监控容灾数据库的系统负载、异常等待事件等内容。 迁移执行宜按照最少改动的数据库结构和应用系统SQL代码；完整、准确的数据对象及数据迁移；最短的业务中断的原则进行，其包含的流程如图2所示。
迁移环境检测包含主机环境检测、网络环境检测和数据库环境检测。结构迁移是指将源数据库的建表语句迁移到目标端不同数据库中，迁移完成保证源、目标数据库中的建表语句功能、性能等价使用。数据迁移分为全量数据迁移和增量数据迁移。迁移结束环境确认需要重建序列、启用触发器和收集执行计划等。构建数据回流是为保证业务迁移后目标数据库切换为生产库出现故障无法持续对外提供业务时，保证目标端已经变化的数据能够迁移回流到原来的生产库，并保证业务不中断。 业务验证分为迁移数据验证和业务功能验证。从源数据库导入到目标数据库中的历史数据文件可以按主键顺序进行组织，以文本文件的方式卸载迁移数据，并确保导出数据能够按照主键有序输出。对导入文件和导出文件分别进行比较操作，通过比对结果是否一致，完成迁移数据的一致性验证。业务功能验证分为运行过程比对、运行结果比对和静态数据比对。 （1）运行过程比对：通过在原和新应用系统前端增加网络镜像分流设备，将发往原应用系统的网络数据镜像分流到新应用系统中，使用覆盖实际交易场景的大量生产数据进行连续测试。在运行过程中，解析目标、源数据库中的日志文件，根据流水号、主键、时间等唯一性标识，比对日志文件中新旧值的变化，找出异常过程，达到验证目标系统数据正确性与一致性目的。 （2）运行结果比对：在原应用系统和新应用系统前端增加网络镜像分流设备，将发往原应用系统的网络数据镜像分流到新应用系统中，将目标、源数据库返回的结果信息保存到文件或数据库中，根据流水号、主键、时间等唯一性标识，比对目标、源数据库的交易结果。（3）静态数据比对：根据源数据库的每日备份时间，在目标数据库做相同时刻的备份操作，备份完成后，将两份备份文件导入到比对库中，按表逐条比对两份数据一致性以及每张表的数据总量，验证目标系统数据的正确性与一致性。 割接前通常需要至少3次割接演练，以确保割接过程中各个环节没有疏漏，并根据不同业务系统情况制定割接流程，分配每个流程责任人，通关制完成各个环节。正式割接环节分为生产环境准备和按照割接方案正式执行割接两部分。 迁移完成后，最危险的环节是切换后生产环境的第一个业务高峰，需要配置专业的数据库专家，快速响应应用和数据库出现的突发问题。之后，需要定期跟踪一定时间，以保障业务系统的稳定运行。最终的护航时间，需要根据实际情况确定。如果遇到突发情况，在无法处理的情况下，应依据回退方案和演练细则逐步完成回退。迁移服务能力可以针对服务提供方的迁移场景、 流程、工具、人员4个方面进行评估。迁移场景方面，可以从能否提供离线迁移、在线迁移、同构迁移、异构迁移、数据迁移和应用迁移进行评价；迁移流程方面，可以从服务提供方的迁移体系是否构建，如可提供合理的数据库选型方案、迁移方案、回流方案，是否能够结合实际迁移环境不断优化完善迁移方案和步骤，是否可提供有效的迁移实施管理办法和手段来进行评价；迁移工具方面，可以从服务提供方是否具有自主知 识产权的迁移工具、能否熟练使用第三方数据库迁移工具、能否集成不同迁移工具和提供统一迁移管理平台等角度进行评价。 迁移工具可以从在线迁移、旁路迁移、增量迁移、转换迁移、迁移比对、迁移回流、对象迁移、异构迁移的基础能力，以及一体化迁移、高性能迁移、特殊场景迁移和系统画像的高级能力两方面来进行评价。 数据库迁移是一项复杂的系统工程，涉及多方多部门人员的深度配合协作，同时需要迁移需求方的慎重考量和较大的改造决心。数据库迁移不是一蹴而就的，需要精准规划评估、稳步实施测试和专业运维保障。世界上没有任何两款数据库产品完全相同，目标数据库无法兼容适配的工作，需要由应用程序一定程度的改造完成。本文从分布式数据库迁移的难点、痛点和常见问题出发，梳理了迁移工程各个关键环节的流程和测试方法，最后从迁移服务能力和迁移工具能力两方面对迁移服务提供方提出了相应要求，旨在使数据库迁移行业规范化、标准化和专业化，进而推动数据库服务行业高质量发展。
参考文献
[1] 教雪娅. 多数据库环境下数据迁移技术的研究与应用[D]. 北方工业大学, 2015.
[2] 彭展, 李密, 杨楠. 基于XML数据迁移技术应用研究[J]. 现代计算机(专业版), 2017(7):79-82.
[3] 杜伟, 洪超, 冯宝, 等. 政务系统迁云上云方法研究[J]. 电信技术, 2019(12):12-15.
[4] 刘娟. Oracle超大型数据库数据迁移方法论[J]. 电脑知识与技术, 2016,12(30):7-8.
[5] 马鹏玮, 魏凯, 姜春宇, 等. 分布式事务数据库系统评估体系[J]. 信息通信技术与政策, 2019(5):14-18.
[6] 于振华, 怀文佳. 分布式事务数据库评测体系研究与实践[J]. 中国金融电脑, 2018(1):47-50.
[7] 殷圣忠. 数据库容灾系统可行性测试[J]. 网络安全和信息化, 2017(2):60-63.
作者简介
刘思源
中国信息通信研究院云计算与大数据研究所工程师，研究方向为大数据、数据库服务等。
论文引用格式
刘思源. 分布式数据库迁移方法研究[J]. 信息通信技术与政策, 2020(11): 91-96.
《信息通信技术与政策》是工业和信息化部主管、中国信息通信研究院主办的专业学术期刊。本刊定位于“信息通信技术前沿的风向标，信息社会政策探究的思想库”，聚焦信息通信领域技术趋势、公共政策、国家/产业/企业战略，发布前沿研究成果、焦点问题分析、热点政策解读等，推动5G、工业互联网、数字经济、人工智能、区块链、大数据、云计算等技术产业的创新与发展，引导国家技术战略选择与产业政策制定，搭建产、学、研、用的高端学术交流平台。