> For AI agents: the complete documentation index is available at https://www.tteam.icu/zh/llms.txt, the full documentation bundle is available at https://www.tteam.icu/zh/llms-full.txt.

# 从阿里云ECS自建MySQL迁移到阿里云RDS


AI 总结AI 生成

这篇文章完整记录了使用阿里云 DTS 将 4 核 8 GB 的 ECS 自建 MySQL 迁移到同规格 RDS 的过程。
- 迁移采用全量迁移、增量同步和短暂停机割接，重点确认同步延迟归零、业务完全停止写入后再切换连接地址。
- 迁移后 CPU 从高峰期接近占满 4 核降至全程低于 20%，但慢查询、索引和容量增长仍需持续优化。

## 背景

原来 MySQL 一直跑在阿里云 ECS 上，由我自己安装和维护。迁移前和迁移后的配置都是 `4 核 8 GB`，所以这次比较的并不是简单的小规格换大规格。

迁移前，MySQL 在大部分时间就要占用 2 核以上，高峰期大约占用 3.5 核。对一台 4 核实例来说，这相当于接近 `87.5%` 的 CPU 使用率，基本已经达到极限。

这个阶段最担心的不是某个查询偶尔变慢，而是备份、慢查询、突发流量和故障处理撞在一起时，实例已经没有资源余量。因此我决定把数据库从 ECS 自建 MySQL 迁移到阿里云 RDS，先保持和原实例相同的规格进行观察。

[//]: # "## 迁移前的CPU监控"

[//]: #

[//]: # "![迁移前ECS自建MySQL的CPU监控](https://img.tteam.icu/i/2026/09/20/e3cec064.webp)"

[//]: #

[//]: # "从迁移前的监控可以看到，CPU 并不是只在某个瞬间冲高，而是长时间维持在高位，高峰期已经接近把 4 核跑满。"

## 迁移方案

整个迁移采用「全量迁移 + 增量同步 + 短暂停机割接」的方式。先通过阿里云 DTS 将 ECS 自建 MySQL 的数据全量迁移到 RDS，再持续同步迁移期间产生的增量数据。等增量同步追平后，通过一个短暂的停机窗口完成业务切换。

在增量同步进行中，通过短暂停机进行数据库割接（切换）是最安全、也是风险最低的方式。

迁移前需要先完成以下准备：

1. 盘点原库。确认 MySQL 版本、数据库和表、字符集、存储引擎、账号权限、关键参数以及定时任务，同时确认应用使用的连接地址，避免迁移后才发现兼容问题。
2. 创建 RDS。RDS 与原 ECS 尽量保持同一地域和 VPC，完成白名单、账号权限、参数以及备份策略配置，先减少网络和权限方面的变量。
3. 创建 DTS 任务。配置 ECS 自建 MySQL 为源库、RDS MySQL 为目标库，执行一次全量迁移并开启增量同步。迁移期间源库仍可继续提供业务服务。
4. 检查同步状态。确认全量迁移完成，增量同步持续运行，并重点观察同步延迟、目标库 TPS/QPS 和异常日志。
5. 准备割接窗口。选择业务低峰期，提前通知相关人员，并确认应用配置、回退方案和核心功能验证步骤。

## DTS 数据库割接


### 第 1 步：确认增量同步无延迟
登录阿里云 DTS 控制台，查看当前的**增量同步延迟时间**。确保延迟显示为 `0 秒`，或者显示「无延迟 / 已追平」状态，同时确认目标 RDS 的 TPS/QPS 处于平稳状态。
### 第 2 步：暂停业务并停止写入
将线上业务系统停止，或者开启维护模式、只读模式，确保没有新的数据库写入请求。
在 ECS 自建 MySQL 中执行以下命令，检查是否还有业务线程在进行 `INSERT`、`UPDATE`、`DELETE` 等写操作：
```sql
SHOW PROCESSLIST;
```
确认已经完全无新写入后，再进入下一步。
### 第 3 步：确认 DTS 完全追平
再次观察 DTS 控制台，等待几秒钟，确保自建库停止写入后的最后几条 binlog 日志都已经同步到 RDS，延迟显示为 `0 秒`。
只有源库停写后 DTS 仍能追平，才能保证最后一批事务已经进入目标库。
### 第 4 步：停止并结束 DTS 同步任务
在 DTS 控制台**停止并结束**增量同步任务。
确认 DTS 任务状态变为「已完成」或「已停止」，防止任务持续运行并产生额外的变更冲突。
### 第 5 步：修改业务配置与连接地址
将业务系统的数据库连接地址从 **ECS 自建库地址**修改为**阿里云 RDS MySQL 的内网连接地址**，同时核对数据库账号、密码和端口。
如果应用使用配置中心或环境变量管理数据库连接，应统一修改配置来源，避免部分实例仍然连接旧库。
### 第 6 步：重启业务并验证功能
重新启动业务服务，进行核心功能与数据读写测试。
登录 RDS 控制台或使用客户端连接 RDS，执行以下命令，确认新的业务连接已经成功建立：
```sql
SHOW PROCESSLIST;
```
同时检查应用日志是否有连接失败、查询报错或事务异常。

业务恢复后还需要继续观察 RDS 的 CPU、连接数、慢查询、锁等待和应用错误率。暂时不要释放原 ECS 自建库，也不要清理 DTS 配置和备份，保留一段回退窗口。确认数据一致、业务稳定后，再下线旧库连接并清理迁移过程中的临时任务。

迁移过程中，真正需要谨慎处理的是数据一致性和切换窗口。实例创建和网络配置都是准备工作，只有确认增量追平、应用能够稳定连接、关键数据校验通过，才算完成迁移。

[//]: # "## 迁移后的CPU监控"

[//]: #

[//]: # "![迁移后阿里云RDS的CPU监控](https://img.tteam.icu/i/2026/09/20/bb199b46.webp)"

[//]: #

[//]: # "迁移到 RDS 后，在同样是 `4 核 8 GB` 的情况下，CPU 全程不到 `20%`。按 4 核计算，这还不到 0.8 核，和迁移前长期占用 2 核以上形成了比较明显的差距。"

## 为什么同规格下差别这么大

ECS 和 RDS 虽然都是 4 核 8 GB，但实际运行环境并不完全等价，CPU 降低通常不是单一原因造成的：

- ECS 上除了 MySQL，还要承担操作系统、备份、监控以及可能同时部署的其他服务。RDS 则是更接近数据库专用实例的运行环境，资源竞争更少。
- RDS 的参数模板通常会针对实例规格做适配。比如缓冲池、刷盘策略和连接参数如果不合适，会造成更多磁盘读取或并发处理，最终表现为更高的 CPU 占用。
- 数据库对存储延迟比较敏感。更稳定的 I/O 性能可以让查询更快完成，减少请求堆积，也会间接降低 CPU 压力。
- RDS 接管了备份、监控和高可用等运维工作，不需要在同一个 ECS 实例上额外维护这些任务。

所以，同规格的 RDS CPU 更低，不能简单理解为“RDS 让 SQL 自动变快了”，更准确地说，是专用运行环境、参数配置、存储性能和运维方式共同降低了数据库的运行压力。

## 总结

这次迁移的收益比较直接：配置没有升级，迁移前高峰期接近跑满 4 核，迁移后 CPU 全程低于 20%，资源余量明显增加。

不过迁移到 RDS 并不代表以后完全不用处理数据库问题。慢查询、索引设计、连接池和后续数据增长仍然需要持续优化。RDS 解决的是自建 MySQL 在资源、运维和故障处理上的压力，而不是替代所有数据库优化工作。