数据库迁移;数据库迁移工具kettle 收藏 0

一步一步教你做系统数据迁移

软件系统数据迁移往往是一项极具挑战性的工作，耗时耗力。特别是对于那种较复杂的业务系统或ERP系统，很能考验做数据迁移的人的综合能力。

并且，数据迁移成功通常也决定着新系统的成功上线和顺利运行。本文将结合我实际执行过的数据迁移案例，介绍一些方法和经验。

软件系统都是有生命周期的，当旧的系统无法满足业务需要时，就会有新的系统去替代旧系统。另一方面，当软件研发团队因为技术架构有重大升级，或为了使软件产品更有竞争力从而对原系统进行大版本升级，这些情况下，通常都会面临数据迁移的工作，把原系统积累的业务数据、基础数据等迁移到新系统。

通常，对于这样的系统升级，新系统较之旧系统发生了很大的变化，比如功能模块的增减与调整，数据库表的构成与设计，甚至数据库本身的选型都有改变。所以说这会使得数据迁移工作变得比较困难。

但就数据迁移本身来说，是可以做到分步进行，化繁为简的。对于数据迁移整体工作，大致可以分为数据提取、数据转换和数据迁移后的测试三个步骤。这些步骤各自又包含一些具体的工作内容，下面将分别展开。

新旧系统的调研。既然要进行数据迁移，首先要理清需要迁移哪些旧数据，以及这些旧数据分别对应到新系统哪个数据库表。对新旧系统的准确调研是后续工作顺利展开的基础，这部分工作可以多花一些时间。

对于新系统，因为时间近，而且一般也是经过分析、设计、开发等各个阶段，文档也比较齐全，即使执行数据迁移的人没有全程参与新系统，熟悉起来也更容易一些。对于旧系统，因为文档的丢失，人员交接等因素，熟悉起来相对困难一些，可以把旧系统的数据库和表作为主要目标。

对系统的调研，需要搞清楚这些点：功能模块构成、主要业务流程、各功能模块对应的数据库表、数据表数据之间的关系、新旧系统数据表之间的大致对应关系、旧系统各个表的数据量大小情况等等。

列出数据迁移大纲。对新旧系统调研之后，基于我们的调研结果。可以整理一份数据迁移大纲，大纲旨在确定数据迁移的范围和边界，确保大的问题没有遗漏。后续可以在此基础上进一步细化。具体内容可以是以下图表中的各项。

数据迁移大纲以新系统功能模块为基准，因为我们数据迁移的目的是为了新系统能够顺利运行。然后可列出新旧系统功能模块的对应，以及各自表的对应关系。大多数情况下，新旧系统功能模块以及它们之间的表并非都能找到对应关系。比如，新系统中有的功能模块旧系统中没有，新系统某个模块对应4张数据库表，但在旧系统中只找到2张相关的表。没有关系，在列出大纲时，只需要基于上一步的调研列出已知的对应关系，经过初步分析后把识别出的问题点注明在“备注”一栏。

在列出大纲之后，可以召集新旧系统相关人员对此大纲进行评审。将大纲整体内容以及“备注”栏的问题进行确认并讨论。该评审的意义在于尽可能让熟悉新旧系统的人参与进来，查漏补缺，以尽可能保证后续的数据迁移准确无误。

列出数据字典对应表。迁移大纲评审之后，就可以进一步基于此大纲完善新旧系统数据字典对应表。这是一项细致的工作，主要是找出新系统数据表中每个字段的来源。可以是以下这样一个表格。

同样地，新系统数据表中的每一个字段也并非能找到旧系统表中的对应字段。可能有些字段需要填充默认值，或者由旧表中多个表或字段计算得出，把这些字段统一在“备注”栏注明。

在完成数据字典对应表后，再进行一次评审。评审通过后进行后面的步骤。

字段转换。基于上一步得出的数据字典对应表，逐一对旧数据表中的来源字段类型、长度、默认值等进行统一。如新表字段类型或长度不兼容旧表数据，就需要对新表做相应的调整；对于常量值，如状态值，新表中使用0、1、2，但旧表中使用a、b、c，就需要明确转换规则，将旧表数据等价转换为新表对应的数据。还有，对于新表中未找到旧表对应字段的情况，要明确填充默认值或NULL。

数据迁移程序编写。字段转换完成之后，就可以编写数据迁移程序了。通常，较为稳妥的方法是用数据迁移程序生成对应新表的INSERT语句。可以为每个表对应的INSERT语句创建一个SQL脚本文件。对于数据量大的表，还需要考虑分拆成多个SQL脚本文件，方便后续的查看和分批执行。

SQL脚本生成后，就是最后阶段的测试工作了。生成的INSERT语句脚本可以在开发环境、测试环境数据库执行，然后对新系统一系列的功能和性能测试。

重点关注数据量大的业务数据表，我曾遇到的一个问题是，新系统对一个表的数据是以树状菜单的形式展示，但因为旧系统迁移到该表的数据量很大，造成前端页面响应慢甚至卡死。这种情况下，如果确认数据是无误的，那只能对树状菜单的展现形式进行调整了。

最后，测试通过后，就可以择时上线新系统了，将上面生成的SQL语句在线上数据库执行。

从自建到云端，数据库迁移全攻略

在数字化浪潮席卷而来的今天，数据库作为数据存储与管理的核心，其管理和运维显得尤为重要。随着业务规模的持续扩展，为了规避性能瓶颈、安全隐患和扩展性不足等问题，不少用户选择将数据库和应用分开部署。然而，这种做法不仅耗费大量时间与人力成本，还使运维变得更加复杂。那么，如何在不同发展阶段满足多数据库的多样化需求？又如何在保证数据安全、提升可用性和性能的同时，优化成本？这正是数据库迁移技术价值所在。

本方案将为您详细解析如何将网站的自建数据库迁移至云数据库 RDS，有效解决数据库管理中的痛点与难题。通过云数据库 RDS，您可以实现零成本维护、高可用性以及集群秒级故障切换，确保业务的稳定运行，同时优化数据库参数与性能，并全面保障数据安全。

核心优势

• 零成本：公网流量不收费；提供最多 2 倍于存储空间的免费备份空间；通用型数据库代理不收费；支持 Serverless。
• 高可用，保证业务稳定性：高可用和集群系列秒级故障切换，最高保障 99.99% 可用性；基础系列自动故障恢复，承诺 99.5% 可用性；自动读写分离，实现负载均衡。
• 参数持续优化，性能优越：持续优化参数；支持只读实例和读写分离，扩展读性能；支持慢日志分析、自动 SQL 优化；自研 AliSQL 和 AliPG 优化性能
• 数据传输加密，阿里云自动修复：SSL 加密；TDE 加密；SQL 洞察与审计；内核 Bug 由阿里云修复

方案架构

• 由 RDS 实现数据库可靠性、可用性、安全性的保障。
• 应用部署在 ECS 上，通过内网（VPC）访问 RDS 。
• 使用数据传输服务 DTS 将 ECS 上的自建数据库迁移至云数据库 RDS ，迁移过程平滑、安全、高效，应用停机时间降低到分钟级别。

本文提供快速体验教程，全面模拟数据库迁移过程，帮助您快速上手迁移操作。

【】即刻体验！

一键部署资源

您可以通过一键部署模板，快速创建一个云服务器 ECS 实例和一个云数据库 RDS 实例，ECS 实例上已经部署了网站以及自建数据库。本方案以 WordPress 网站为例。

1. 单击一键部署进入 ROS 控制台，在顶部选择华东 1（杭州）。
2. 填写模板参数：为方便体验，您只需关注可用区、ECS 实例密码和 RDS 数据库密码三个参数的选择，其它参数可使用方案默认值或按需选择。
3. 查看页面右下角的资源价格，确认无误后单击创建。

等待资源栈创建，资源部署时间约为 10 分钟，请耐心等候，直至资源栈状态显示为创建成功。

查看已部署的资源

在资源页面，您可以查看上述步骤所生成的 ECS 实例、RDS 实例、WordPress 网站访问地址等。

1. 在资源栈 > 资源栈列表中单击上一步创建的资源栈。
2. 在顶部单击资源页签，可以查看已创建的资源及相关信息。

1. 在顶部单击输出页签，可以查看输出关键字列表，各关键字描述具体见方案详情。

安装WordPress网站

一键部署资源后，进入WordPress安装页面，完成WordPress安装。

1. 访问资源编排管理控制台，在资源栈列表中单击刚创建的资源栈。
2. 在资源栈顶部单击输出页签，并在输出关键字列表中找到ECSWordPressUrl参数对应的值，单击进入网站。

1. 在WordPress安装页面，填写网站相关信息，然后单击Install WordPress。如下图所示：

浏览WordPress网站

1. 返回资源编排管理控制台，在资源栈列表中单击刚创建的资源栈。
2. 单击输出页签中ECSWordPressUrl参数对应的值，即可进入网站浏览。

现在，您可以使用DTS数据传输服务，配置源库和目标库信息，开始迁移数据库的库表结构、全量数据和增量数据。

1. 登录DMS数据管理服务。
2. 在顶部菜单栏选择集成与开发（DTS） > 数据传输（DTS） > 数据迁移。
3. 单击创建任务。
4. 配置源库及目标库信息。（具体配置请点击方案详情）
5. 单击测试连接以进行下一步，系统会自动为ECS添加DTS安全组，为RDS添加DTS服务器IP至白名单，以允许DTS访问ECS和RDS。如果有失败信息，参考对应的错误提示进行修改即可。
6. 配置迁移任务。（具体配置方法请点击方案详情）
7. 预检查通过率达到100%后，单击下一步购买。选择数据迁移实例的链路规格（本案例以small规格为例），阅读并选中《数据传输（按量付费）服务条款》，单击购买并启动。
8. 迁移任务正式开始。

单击迁移任务ID可以查看具体进度。当您看到如下界面，表示存量数据已迁移完成，增量数据会实时同步。此时您可以进入下一步，验证RDS里的数据。

通过查看RDS实例中的数据，验证数据迁移结果

1. 登录RDS实例

a. 单击资源栈顶部资源按钮，然后单击Database资源ID进入RDS控制台，单击登录数据库。

b. 在弹出的DMS页面中，填写RDS高权限数据库账号和密码，然后单击登录。

1. 全量数据验证

a. 在SQLConsole窗口，在左侧双击目标数据库名称wordpressdb，可以看到自建数据库所有库、表数据已经完成迁移。

3. 增量数据验证

a. 在SQLConsole窗口，双击wp_comments表名，再单击执行，查看wp_comments表的数据。

b. 前往资源编排管理控制台，在资源栈列表中单击之前创建的资源栈。

c. 在资源栈顶部单击输出页签，并在输出关键字列表中找到ECSWordPressUrl参数对应的值，单击进入网站，往下浏览找到如下图，点击进入评论区。

d. 在网站中新增一条评论或多条评论，如下图

e. 再次查看RDS实例中wp_comments表的数据，执行查询语句可以看到增加的评论，说明增量数据已迁移成功。

通过切换数据库连接并访问网站，验证RDS服务可用性

1. 从自建数据库切换到RDS

为避免数据丢失，建议先停止写入数据，然后再将应用程序的数据库连接配置修改为云数据库RDS的连接地址。

a. 停止写入数据到源数据库。

b.修改WordPress配置文件中的数据库连接配置。

（1） 在资源列表中单击WebServer资源ID进入ECS控制台，点击远程连接使用ECS账户登录。本示例中，ECS账号为root，密码为用户自定义密码。

【说明：如果提示用户名或密码不正确，可能是因为密码错误或者操作系统未完全启动，请确认输入的用户名和密码，或者稍后再尝试登录。】

（2） 打开配置文件。

sudo vim /usr/share/nginx/html/wp-config.php

（3） 按i进入插入模式。

（4） 修改数据库连接配置：

• 修改数据库账号：将wordpressuser改为RDS高权限账号dbuser。
• 修改数据库密码：将password修改为您自定义的密码。
• 修改数据库连接地址：将localhost修改为RDS内网连接地址（可以直接复制资源栈输出页签中RDSInternalAddress关键字对应的值）。

1. 按Esc键退出插入模式。
2. 输入:wq，并按Enter键退出vim编辑器。

【说明：以上仅为本示例教程的切换步骤，关于生产环境的切换和回滚方案，请参见业务切换流程。】

1. 验证切换后的服务可用性

a. 返回资源编排管理控制台，在资源栈列表中单击刚创建的资源栈。

b. 单击输出页签中ECSWordPressUrl参数对应的值，进入网站浏览，可观察到网站与切换前保持一致。如下图:

c. 在网站新增一条评论，再次查看RDS实例中wp_comments表的数据，执行查询语句可以看到增加的评论。

想必你通过阅读，已经学会如何将网站的自建数据库迁移至云数据库 RDS。现在邀请你体验【】

数据库迁移新手必看：一步一步创建你的第一个迁移脚本

在项目开发过程中，数据库结构的管理往往让人头疼，尤其是当你需要跨多个环境进行数据库迁移时。你可能曾因数据库版本不一致而大伤脑筋，甚至差点与数据库打起来。今天，我们将带你走一遍创建和管理数据库迁移脚本的全流程——不但帮助你在代码和数据库之间搭建稳固桥梁，还能轻松应对结构变更。放心，虽然讲解专业性十足，但我会把这篇文章写得幽默又生动，保证让你在学习过程中，既收获知识，又能笑出声来！

数据库迁移（Database Migration）指的是管理数据库版本和结构变化的一种方法。通常，随着项目迭代，数据库结构会发生变化，比如新增表、修改字段类型等。为了确保开发环境和生产环境中的数据库一致，使用迁移脚本是一个必不可少的步骤。

在本文中，我们将使用常见的数据库迁移工具来演示如何创建第一个迁移脚本，帮助你快速掌握这一技巧。通过自动化迁移脚本生成和执行的方式，我们能够简化数据库管理工作。

迁移脚本（Migration Script）：记录数据库结构变更的代码文件，包含对数据库的增、删、改操作。就像是数据库的“变形金刚”，随时准备应对不同环境下的变化。

版本化（Versioning）：数据库结构的每一次变更都对应一个唯一标识，通常结合时间戳，确保每次迁移都有清晰的历史记录，方便后期追踪和管理。就像是数据库的身份证，每次变更都会印上时间戳，确保“身份”独一无二。

SQL（Structured Query Language）：结构化查询语言，广泛应用于关系型数据库的操作。它是数据库开发者的“语言”，无需翻译就能直达数据库的核心。

版本号（Version Number）：迁移脚本的唯一标识，通常带有时间戳，用来区分不同的迁移脚本。就像是每个迁移脚本的“身份证号码”，让它在所有脚本中永远独一无二。

同步结构变更：迁移脚本的核心任务是确保数据库结构的每一次变动都能精准同步，保证不同环境中的数据库保持一致性。

每次变更都要写迁移脚本：每当数据库结构发生变化，无论是增加表格还是修改字段，都需要创建一个迁移脚本。这个脚本就像是数据库变更的“护照”，确保每一次调整都有据可依。

版本号与时间戳：版本号和时间戳让每个迁移脚本都拥有独特身份，避免不同开发者提交的脚本发生冲突。它们像是数据库迁移的“身份证”，帮助管理不同版本的迁移。

自动化执行：使用迁移工具能够自动执行这些脚本，减少人工操作，确保数据库结构在各个环境中的一致性，避免因为手动执行脚本带来的错误。就像是给数据库装上了“自动驾驶”系统，让它自己按照预定路线行驶。

现在你已创建项目并配置好目标数据库，接下来可以添加第一个迁移脚本。

1.在“迁移”标签页中，点击“+ 添加迁移（Add Migration）”。

2.输入以下详细信息：

a. 类别（Category）：版本化（应默认选中）

b. 版本（Version）：默认值为 001_yyyymmddhhmmss，时间戳默认包含，避免多个用户使用相同版本号。

c. 描述（Description）：创建 person 表

d. 脚本（Script）：

e.点击“保存（Save）”按钮。

在一次项目开发过程中，团队成员小王突然有了一个“灵感”——手动修改数据库结构！他觉得，迁移工具这么麻烦，直接通过 SQL 语句把表结构调整一下，不就行了？于是，他信心满满地执行了一条 ALTER TABLE 命令，修改了一些表字段和约束条件，操作完后，他还拍了拍自己的胸脯，心想：“这下优化得更好了，简直是小菜一碟。”

然而，第二天，事儿就大条了。另一位开发人员小张拿到最新的代码，照例运行迁移脚本，准备将数据库结构更新到最新版本。运行时，他突然遇到了一连串报错：表字段不对，约束条件冲突，甚至有些数据类型不匹配！他摸了摸脑袋：“这是哪里出问题了？明明前几天一切正常呀。”

经过一番排查，小张发现，原来小王就在昨天偷偷“优化”了数据库的结构，结果这一手操作直接覆盖了之前已经定义好的结构——就像是在高楼大厦上打了个小洞，结果整座楼塌了。更糟糕的是，这些变更并没有被记录到迁移脚本里，导致其他团队成员根本不知道这些变化。

小王一脸懵逼地说：“我只是想优化一下表结构，谁知道会这么复杂？我这不就是在做一些小改动嘛，哪知道会这么大影响！”他开始怀疑，自己是不是得罪了什么数据库神明，导致这场“数据灾难”。

小张耐心解释：“你可以优化表结构，但必须通过迁移脚本，确保每个人都能同步这些变更。手动修改？那就像是一个人在房间里自己装修，结果整个楼的结构都被搞得乱七八糟。”

这时，小王才意识到问题的严重性：“原来迁移脚本是这样的一回事啊！不但可以帮忙记录每次数据库变更，还能让大家在修改数据库时有据可依，避免像今天这样‘拆东墙补西墙’。”

这个事件也让团队成员更加深刻地认识到，迁移脚本不仅仅是技术工具，它实际上是一个项目协作的核心。每次数据库的变动，都应该通过规范的迁移流程来进行，确保每个成员都能在同一个“数据库框架”内工作，避免“手动操作”的乌龙事件。

从此以后，小王也成了团队里最积极使用迁移工具的成员之一，每当他需要修改数据库结构时，总是会先问：“迁移脚本写了吗？”大家都忍俊不禁，却又心照不宣地为他点了个赞。

1.迁移脚本怎么回滚？

如果迁移脚本执行有问题，别慌！许多数据库迁移工具都提供回滚功能。你只需找到相应版本，执行回滚命令，数据库便能恢复到迁移前的状态。就像按下“撤销”按钮，瞬间回到原点，避免大规模“灾难”发生。

2.每次迁移都要手动写 SQL 吗？

其实不完全是！很多数据库迁移工具支持自动生成迁移脚本，极大地减少手动编写 SQL 的繁琐。你可以像搭积木一样，快速生成所需的数据库结构变更，只需少量干预，省时又省力。

3.迁移失败了怎么办？

迁移失败时，第一步是检查 SQL 脚本的语法和逻辑错误。常见的失败原因通常是权限不足或脚本本身的错误。如果数据库无法执行脚本，确保脚本书写无误且数据库连接正常。就像调试代码一样，找出错误的根源，重新执行即可。

1.项目开发中的数据库结构变更

随着业务不断发展，数据库结构时常需要调整。每次结构变更，迁移脚本就像是数据库的“进化日志”，确保不同环境中的数据库始终保持同步，避免因为手动修改产生的混乱。让你随时随地，轻松应对数据库的“变身”。

2.多人协作的项目

当多个开发人员共同参与项目时，手动修改数据库结构很容易引发冲突。迁移脚本则能有效避免这种情况。每个人都可以在自己的环境中独立进行变更，所有的修改通过迁移脚本自动合并，确保团队合作不受“数据库之乱”的困扰。

3.CI/CD 自动化部署

在持续集成和部署（CI/CD）流程中，数据库结构的变更也必须与代码保持同步。通过自动化执行迁移脚本，你的数据库就像是一个自动调整的“小机器人”，随着代码更新，结构自动升级，省时省力，让部署过程流畅无缝。

1.版本号的唯一性

每次生成新的迁移脚本时，一定要确保版本号唯一，避免与已存在的脚本冲突。版本号就像迁移脚本的“身份证”，每个脚本都有自己的唯一标识，保证它们能有序地“排队”执行，避免混乱。

2.及时提交迁移脚本

数据库结构变更后，别忘了及时生成并提交迁移脚本，确保团队中的每个成员都能同步更新数据库结构。就像做作业一样，拖延只会导致大家的进度不同步，造成不必要的麻烦。

3.测试迁移脚本

在将迁移脚本投入生产环境之前，务必先在开发或测试环境中验证它的正确性。毕竟，生产环境就像是比赛的“终极赛道”，一旦出错，后果可能不堪设想。先在沙盘上练习，确保万无一失，再上“主战场”。

1.小步快跑

每次生成迁移脚本时，尽量将变更拆分成小块，而非一次性做大规模调整。这样可以降低风险，让每个变更都像是“小步快跑”，避免“踩雷”的机会。小步走，稳稳进，确保每个步骤都可控。

2.记录变更

每次生成迁移脚本时，要清晰描述变更内容，这不仅方便日后的回顾，也能帮助团队成员快速理解迁移的目的和影响。就像写日记一样，把每次的调整都记录下来，让数据库迁移有迹可循。

3.版本控制

将迁移脚本纳入版本控制系统，确保每次修改都有明确的记录，方便追踪与恢复。这样，你就能像掌握历史档案一样，随时查看迁移的“历史轨迹”，在遇到问题时迅速回溯。

4.回滚策略

每次迁移脚本都应该配有相应的回滚操作。假如“意外”发生，能够及时恢复到变更前的状态，就像为数据库穿上了“保险套”。有备无患，避免数据库“一失足成千古恨”。

今天的内容让你掌握了如何创建和管理数据库迁移脚本。通过迁移脚本，你和团队能够轻松应对数据库结构变更，避免手动修改带来的混乱。数据库迁移不仅是技术工作，它更是团队协作的关键环节，能让开发、测试、生产环境的数据库保持同步。希望你通过这篇文章，学到更多实用技巧，享受迁移的过程，并在未来的项目中得心应手！

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com