云时代，好用的数据迁移方案推荐

数据库作为企业核心的数据存储引擎，在其提供服务的过程中，经常会因为各种各样的原因需要进行数据的迁移。数据库迁移作为一个古老的话题并不神秘，但因为迁移数据的重要性，以及业务对数据库可用性的高要求，导致数据库迁移的复杂度极高，一般都需要专业工具的协助才能完成。当前 ，市面上也已经提供了各种各样的数据库迁移工具。本文将介绍数据库迁移的步骤以及市面上常见的迁移工具。

一、 为什么要做数据库迁移

数据库在提供服务的过程中，经常需要进行数据迁移，常见的场景包括：

• 数据库上云迁移，业务上云，要求数据库上云，此时涉及数据库的迁移；
• 数据库跨云迁移，业务需要跨云迁移时，要求数据库跨云迁移；
• 数据库版本升级，例如数据库内核发布新版本，需要从旧版本迁移到新版本；
• 数据库扩容或缩容，例如数据库所在服务器资源不足，需要跨机器迁移数据库以实现数据库扩容；
• 异构数据库迁移，数据库中的部分业务需要迁移到另外一种更适合的引擎时，涉及的数据库迁移工作。例如从单机数据库迁移到分布式数据库；从关系型数据库迁移到 NoSQL，或，从关系型数据库/ NoSQL 把数据迁移到数据仓库、大数据或数据湖中进行数据分析。

二、 数据库迁移的步骤

不同于应用搬迁，数据库在数据迁移过程中，业务仍然持续写入数据，数据一直处于动态变化的状态，整个迁移过程相对比较复杂。根据是否能支持数据迁移过程中，数据库为业务持续提供读写服务，将迁移方案分为：停机迁移、零停机迁移。为了满足业务服务的高可用及迁移数据的完整性，推荐大家选择能够支持“零停机迁移”的工具产品。

• 停机迁移，即迁移之前需要停止数据库的写能力，即数据库上层业务不能有写请求，业务停服。然后，在数据库完全静态的情况下，进行数据库迁移。
• 零停机迁移，即在数据库迁移的过程中，业务仍然继续提供服务，业务不受影响。

在数据库迁移过程，零停机迁移的迁移步骤包括如下几步。而停机迁移，只支持存量历史数据的搬迁。

• 存量历史数据的搬迁，存量历史数据搬迁主要进行结构定义及数据的迁移。例如对于关系型数据库(例 MySQL、SQLServer 等)，结构迁移会进行表结构、视图、存储过程、函数等的定义迁移。
• 增量更新数据，由于存量历史数据搬迁一般会持续数小时甚至上天，在这期间为了实现数据库可服务，数据库会继续接受业务写入请求。对于这部分新增的数据，也需要迁移到目标数据库，以保证迁移数据的完整性。当然市面上很多工具不提供这个能力，其要求业务完全停止服务 ，保持数据库的完全静态后，再进行数据迁移。
• 迁移数据对比，在完成数据迁移后，一般都需要校验迁移数据的一致性，避免因为软硬件或人为误操作等原因，出现迁移数据不一致导致业务受影响。

三、 常见的数据库迁移方法

当前市面上主流的数据库迁移工具，主要分为如下几种方案：

备注：上述评测仅根据当前各个产品的情况得出的结论

1、NineData

NineData 是玖章算术旗下的多云数据管理平台，它支持数十种常见数据源(例：MySQL、SQLServer、Clickhouse、Kafka等)之间的同异构数据迁移。NineData 提供了数据的单向及双向复制。其提供的单向数据复制功能，包括了结构复制、全量数据复制及增量复制能力，基于这几个复制步骤，可以在业务零停机的情况下，完成数据库的无缝迁移。

NineData 作为一个即开即用的SAAS服务，围绕数据迁移功能，也提供了一系列完善的配套服务，包括告警监控、权限管控、迁移限流及数据一致性对比等。其中，数据对比功能非常有特色，其支持所有对象的结构对比及数据对比，同时，为降低对比对数据库的压力影响，还提供了快速对比、对比限流等能力，在对比完成后，其还会提供详细的不一致数据及订正语句。

除了完善的功能外，NineData 的迁移性能也很优秀，用sysbench模型测试了下，它的全量迁移速度高达130MB/s，增量复制速度能达到10万+TPS。

NineData 比较有特色的是：可完全自动化得实现数据库的零停机迁移；提供高效、易用完善的数据一致性对比工具；对云数据库、云主机及IDC自建数据库的支持同样完善。

图一：配置任务的第一步骤，选择迁移的数据源及迁移的步骤

图二、配置任务的第二步骤，选择复制对象

图三：配置任务的第三步骤，配置映射关系及数据过滤条件

图四：配置任务的第四步骤，迁移前的前置检查

图五：任务详情及运维界面

图六：复制任务的数据对比详情

果图七：复制任务的对比结果，不一致数据的详情

2、备份集恢复

一般各个数据库引擎都会提供备份恢复工具，例如 MySQL 的 xtrabackup。借助备份集恢复功能实现数据库迁移的步骤一般如下图所示。整个恢复过程纯依赖手动调度、手工执行。这种恢复方案因依赖数据库本身工具，迁移的完整度很高。但是实现复杂度也比较高，比较容易出错。且恢复工具不提供辅助的诊断运维能力，使用门槛比较高，不是很推荐。

备份恢复迁移方案的特征为：纯手工操作复杂度高且容易出错，迁移的完整性较高，但只适合同网络环境下的同构同版本数据库之间的数据迁移。

3、数据导出+数据导入

一般各个数据库引擎都会提供导入导出的工具，例如 MySQL 的 mydumper + myloader。

同时，各大数据库开发工具也会提供数据导出+导入的功能，例如 navicat。这种工具只能支持历史存量数据的迁移，不支持增量数据迁移。所以，为了保障迁移数据的完整性，要求业务停机后，再进行数据迁移。

基于数据导出导入的迁移方案的问题是：要求业务停机迁移，业务影响大；只适合小规模数据量情况下的数据迁移。

4、云厂商数据库迁移工具

云厂商数据库迁移工具，其中以阿里云数据传输 DTS 为代表。云厂商一般都会提供数据库迁移工具，以支撑数据库上云迁移。云厂商的数据库迁移工具一般也支持结构复制、全量数据复制及增量数据服务，可以实现业务零停机情况下的数据库迁移。同时，云厂商一般也会提供内置的数据校验工具，但一般只支持数据的校验，不提供结构校验能力。云厂商迁移工具一般由数据库团队负责，所以其对云数据库的迁移支持较好，但是对于云主机上自建数据库以及 IDC 自建数据库支持不好甚至不支持。例如，大部分云厂商迁移工具都不支持自建数据库作为迁移工具的目标数据源。

云厂商迁移工具的特征是：可完全自动化得实现数据库的零停机迁移；对云数据库的支持较完善，基本不支持云主机及 IDC 自建数据库。

四、 小结

总的来说，数据库作为核心业务支撑，其在数据库搬迁过程中的可用性及搬迁数据的完整性至关重要。为了满足服务高可用及迁移数据的完整性，推荐大家选择能够支持“业务零停机迁移”的工具产品。同时，平台工具(例 NineData ) 的自动化体验及配套设施（例：数据校验工具、迁移限流、监控告警等）一般较为完善，是比较推荐的选择。