昨晚从公司打卡下班的时候，已经是深夜十一点了。

本来计划晚上九点开始迁移数据库的，方案计划书也都提前整理好了，结果就是在最后「临门一脚」的时候——歇菜了。然后就开始各种查文档，给领导打电话，各种尝试。

配合迁移的兄弟们都已经摩拳擦掌，跃跃欲试了，我也只能冲他们尴尬地一笑：

「再等等吧，再给我几分钟的时间。」

三分钟，五分钟，十分钟过去了，原本计划九点半就打完收工，各回各家的，结果全部搞完以后，一看手机：十一点过十分。

所以，谨以此文，记录下这难忘的一晚。也算给后面有类似需求的兄弟们，留个纪念。

背景

需求： 出于公司策略调整，需要将阿里云的数据库产品 RDS ，从一个阿里云账号迁移到另一个阿里云账号，实例地域及配置保持不变。

要求：允许迁移期间短时间的停服，但不能时间太长，应该控制在一分钟以内。

规模：原阿里云 RDS 实例下，有多个数据库，每个数据库的表都在 100 个以上，每个数据库占用磁盘空间在 20GB 左右。数据库被多个项目使用，且时时会有数据写入。

简单来讲，就是在代价最小的前提下，把 RDS 从一个阿里云账号迁移到另一个阿里云账号。

计划

虽然任务看似简单，但涉及到的细节比较多。本来之前已经做过几次类似的工作了，但时间一长，记忆就有些模糊了。最让人啼笑皆非的是，自己之前写的文档，现在自己居然看不懂了！

迁移工具的话，我们使用阿里云的数据传输服务 DTS。迁移时间，我们定在晚上九点，这是我们数据库访问的一个低峰期。

我将此次迁移任务，拆分成了三个阶段，分别是：迁移前工作、迁移中工作和迁移后工作。

迁移前工作

1. 新阿里云账号创建数据库实例

这一步是在新的阿里云账号下选购 RDS 产品。

选购时需要注意以下几点：

• 地域和原实例保持一致
• 数据库版本和原实例保持一致
• 配置尽量保持一致，如果有降配需求，需要在了解原实例的性能瓶颈后，再做决定
• 企业版一般选择高可用系列或集群系列，基础系列适用于测试使用，不建议选择

2. 开通外网访问地址

购买完实例以后，需要在数据库连接页面开通外网访问地址。跨阿里云账号访问 RDS 必须要通过外网地址进行访问。

3. 新 RDS 下同步原 RDS 白名单

因为都是外网访问，所以这里仅需要添加外网访问白名单。

阿里云 RDS 不支持白名单一键导出，所以这里需要按分组手动进行复制添加。

4. 新 RDS 下同步创建数据库

同步创建原 RDS 下的数据库，这里需要注意，数据库的字符集和原数据库保持一致。

5. 新 RDS 下同步创建数据库账号

同步创建和原 RDS 一致的数据库账号，并分配一样的权限。这里密码要保持一致，这样业务代码能保持不变。

6. 新 RDS 下同步原 RDS 参数配置

原 RDS 可能在使用的过程中修改了数据库参数，所以这里也要保持同步。

尽管 RDS 提供了参数导出和导入的功能，但不是十分智能。如果两端数据库配置存在差异的话，参数格式或值会存在兼容性问题，这在提交参数时会有错误提示。

这里可以先通过参数修改历史查看一下历史修改的参数。如果不多的话，可以手动进行同步添加。

7. 新 RDS 连通性测试

以上工作做完以后，需要在关联的服务器上，通过 MySQL 客户端检查账号的连通性。

每个服务器，每个数据库下的每个账号都要检查一遍，这样可以提前保证新 RDS 的连通性没有问题。

如果报错的话，可以根据报错信息进行排查报错的原因。

可以使用客户端工具，或者脚本进行检测。

8. 明确原 RDS 影响的业务边界

这一步看似最没有技术含量，实则是整个迁移前工作中最重要的一环。

需要明确有哪些项目使用了原 RDS 的内网连接。

因为我们迁移的思路是将新 RDS 的外网地址替换为原 RDS 的外网地址，这样可以降低迁移的影响时间。所以，需要提前找到，哪些项目中用到了原 RDS 的内网连接地址。

如何找到哪些项目使用了原 RDS，可以参考 《MySQL 实用小技巧——谁动了我的 MySQL ？》这篇文章的思路。

迁移中工作

1. 两端账号创建 AliyunDTSDefaultRole 角色

在第一次使用 DTS 时，需要创建名称为AliyunDTSDefaultRole的默认角色，并将系统权限策略AliyunDTSRolePolicy授权给该角色。

经过授权后，DTS可访问当前云账号下的RDS、ECS等云资源，在执行数据迁移、同步或订阅任务的配置时可调用相关云资源信息。

具体操作可参考 [授予DTS访问云资源的权限]。

2. 新阿里云账号创建 RAM 角色

在使用 DTS 配置跨账号任务时，需要使用数据库实例所属的阿里云账号（主账号）配置 RAM 授权，将创建 DTS 任务的阿里云账号（主账号）作为授信云账号，允许其通过数据传输服务访问数据库实例所属阿里云账号的相关云资源。

简单讲，就是你将 A 账号的 RDS 迁移到 B 账号，如果 DTS 迁移任务创建在 A 账号下的话，你需要在 B 账号下配置 RAM 授权，目的是为了允许 A 账号访问 B 账号的相关云资源。

两个关键点：

• 配置 RAM 授权通过阿里云主账号配置
• A 账号下创建 DTS 迁移任务，B 账号下配置 RAM 授权

具体操作可参考 [跨阿里云账号任务如何配置RAM授权]。

3. 修改项目中原 RDS 内网访问地址为外网访问地址

根据迁移前工作中第 8 步整理的文档，依次修改每个项目中用到原 RDS 内网地址的部分，统一调整为外网地址。

4. 创建 DTS 迁移任务

创建 DTS 迁移任务流程比较固定，按照正常的流程创建即可。

这里有一点需要特别注意，是否跨阿里云账号，源端选择的是同账号，目标端选择的是不同账号，这里一定不要搞混了。

就是这个问题，让我从晚上九点钟干到十一点钟，SHIT！

5. 启动 DTS 迁移任务

创建完 DTS 迁移任务以后，就可以启动 DTS 迁移任务了。

这里依次会经过全量同步表结构，全量同步数据和增量同步数据几个主要步骤，每个步骤都会有对应的进度提示。

当界面显示增量同步数据，且数据同步无明显延迟以后，说明 DTS 任务已到了正常增量同步的阶段。

6. 验证增量同步结果

DTS 任务到了增量同步数据以后，理论上讲，源端和目标端的数据已经保持一致了，此时可以进行一个简单的验证。

可以在 MySQL 的客户端开两个窗口，同时连接新 RDS 和原 RDS ，选择一个数据写入比较频繁的表，按自增 ID 倒序查看。如果两侧新写入的数据保持一致，证明同步任务正常。

7. 备份并修改原 RDS 外网地址

DTS 正常同步以后，就可以准备正式迁移了。

正式的迁移动作其实很简单，第一步，现将原 RDS 的外网地址修改掉。

在数据库连接界面修改 RDS 外网地址，如下：

注意：在修改之前，一定要保存好原 RDS 外网地址，后面会用到。

8. 检查原数据库是否停止写入

修改 RDS 外网地址需要一分钟左右的时间，修改成功以后，原有的外网地址就不能访问了。

此时，可以打开数据库监控页面进行查看。如果所有访问入口都调整成内网访问的话，数据库连接数曲线，应该会降低至0。这说明，原 RDS 已经停止写入了。

9. 停止 DTS 迁移任务

在确认原 RDS 已经无数据写入以后，需要先停止掉 DTS 迁移任务。

因为我们一般采用单向同步的策略，所以，在新 RDS 启用之前，必须停止掉 DTS 迁移任务。

10. 修改新 RDS 外网地址为原 RDS 外网地址

最后一步，将新 RDS 的外网地址替换成原 RDS 外网地址。

替换成功后，系统就可以正常访问了。此时观察新 RDS 监控，已经有新的数据开始写入了。

温馨提示： 第 8，9，10步可以分别在多个浏览器窗口或者多台电脑上依次操作，这样可以缩短操作的时间。

迁移后工作

1. 检查新 RDS 实例读写是否正常

迁移完成以后，我们需要在第一时间，检查新 RDS 的各项指标是否正常。

如果出现异常情况，应该及时排查原因。

2. 检查各业务系统访问是否正常

除此之外，测试人员应该检查各业务系统，是否能正常使用。

这是在非技术层面的一层验证。

3. 检查是否有报错日志

同时，我们还需要关注业务系统的错误日志，看是否有相关错误产生。

如果是数据库相关的报错，需要及时排查原因。

4. 知会相关人员，随时关注异常动态

除了一线人员各有分工之外，还要尽早通知到相关的业务人员。

及时关注相关产品的动态，以及客户反馈，第一时间收集迁移可能产生的问题。

5. 删除原 RDS 白名单

如果在平稳地度过一段时间后，各系统运行正常，那说明我们此次的迁移任务已经算是平稳落地，可以暂时告一段落了。

我们可以删除掉原 RDS 的白名单，这样是为了百分百阻止原 RDS 还有数据写入。

6. 释放 DTS 迁移任务

DTS 迁移任务暂停以后，还是会按时间收费的。所以，我们在确认迁移工作完成以后，需要在第一时间将迁移任务释放掉，避免不必要的成本。

7. 释放原 RDS 实例

如果过了十天半个月，新 RDS 已经正常运行了。这时候可以考虑将原 RDS 做个备份，然后释放了。

毕竟，早一天释放，还能早回收几毛钱。

迁移问题

虽然迁移计划看上去滴水不漏，但真到了实际执行阶段，却还是出现了一些意料之外的问题。

同步数据库参数问题

在迁移前工作第 6 条中已经详细阐述。

此问题在迁移过程中困惑了我一些时间。当时还有另一种方案可选，就是在导入参数的基础上，一个个去修改参数，保证最后能正常提交。但是一堆的异常参数，不知道修改完要到什么时候。

幸运的是，我意外发现了参数修改历史的选项。更幸运的是，修改过的参数并不多。

不管怎么说，真正尝试过，才知道孰优孰劣。

角色授权问题

关于角色授权问题，也是困扰了我很长时间。

现在想想，可能当时事情一多，脑子不够用了。

其实也没那么复杂，AliyunDTSDefaultRole角色是为了两端的DTS都能访问当前阿里云账号下的云资源。而 RAM 授权，是为了让源端阿里云账号能够操作目标端阿里云账号的 RDS 资源。

理解清楚了，也就没那么绕了。

是否同阿里云账号选择问题

这个问题说来真的是惭愧，印象中，之前我就在这里栽过跟头。

一开始的时候，看到是否跨阿里云账号，我便下意识地选择了不同账号。因为满脑子想的都是，跨阿里云账号迁移数据库，结果就是怎么都不对。

折腾了快两个小时，各种求助，各种尝试，最后在是否两个字上犹豫了片刻：哪个是否？迁移主体的是否，还是其他是否？

又仔细看了看，明白了：人家说的是源 RDS 是否和当前登陆的阿里云账号是同一个阿里云账号。

答案是：同账号。

改完以后，顺利通过。然后运行迁移任务，到全部操作完，也就十分钟的事情。

而解决这个问题，用了我快两个小时！

总结

虽是一次普通的迁移任务，也算是充满了跌宕起伏。

总结下来，用一句话概述，流程固然重要，避免思维定式同样重要。谨记！

【前方高能，紧急插播一条广告】

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

我的公众号 [快乐的皮拉夫] 已经开通有一段时间了，感兴趣的朋友可以去捧个场，加个关注，爱你们哟～

公众号内容主要是我目前在写的一本书 ——《写给班吉的书》，欢迎各位看官老爷留言评论。

本作品采用《CC 协议》，转载必须注明作者和本文链接