从阿里云ECS自建MySQL迁移到阿里云RDS
这篇文章完整记录了使用阿里云 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，先保持和原实例相同的规格进行观察。
迁移方案
整个迁移采用「全量迁移 + 增量同步 + 短暂停机割接」的方式。先通过阿里云 DTS 将 ECS 自建 MySQL 的数据全量迁移到 RDS，再持续同步迁移期间产生的增量数据。等增量同步追平后，通过一个短暂的停机窗口完成业务切换。
在增量同步进行中，通过短暂停机进行数据库割接（切换）是最安全、也是风险最低的方式。
迁移前需要先完成以下准备：
- 盘点原库。确认 MySQL 版本、数据库和表、字符集、存储引擎、账号权限、关键参数以及定时任务，同时确认应用使用的连接地址，避免迁移后才发现兼容问题。
- 创建 RDS。RDS 与原 ECS 尽量保持同一地域和 VPC，完成白名单、账号权限、参数以及备份策略配置，先减少网络和权限方面的变量。
- 创建 DTS 任务。配置 ECS 自建 MySQL 为源库、RDS MySQL 为目标库，执行一次全量迁移并开启增量同步。迁移期间源库仍可继续提供业务服务。
- 检查同步状态。确认全量迁移完成，增量同步持续运行，并重点观察同步延迟、目标库 TPS/QPS 和异常日志。
- 准备割接窗口。选择业务低峰期，提前通知相关人员，并确认应用配置、回退方案和核心功能验证步骤。
DTS 数据库割接
第 1 步：确认增量同步无延迟
登录阿里云 DTS 控制台，查看当前的增量同步延迟时间。确保延迟显示为 0 秒，或者显示「无延迟 / 已追平」状态，同时确认目标 RDS 的 TPS/QPS 处于平稳状态。
第 2 步：暂停业务并停止写入
将线上业务系统停止，或者开启维护模式、只读模式，确保没有新的数据库写入请求。
在 ECS 自建 MySQL 中执行以下命令，检查是否还有业务线程在进行 INSERT、UPDATE、DELETE 等写操作：
确认已经完全无新写入后，再进入下一步。
第 3 步：确认 DTS 完全追平
再次观察 DTS 控制台，等待几秒钟，确保自建库停止写入后的最后几条 binlog 日志都已经同步到 RDS，延迟显示为 0 秒。
只有源库停写后 DTS 仍能追平，才能保证最后一批事务已经进入目标库。
第 4 步：停止并结束 DTS 同步任务
在 DTS 控制台停止并结束增量同步任务。
确认 DTS 任务状态变为「已完成」或「已停止」，防止任务持续运行并产生额外的变更冲突。
第 5 步：修改业务配置与连接地址
将业务系统的数据库连接地址从 ECS 自建库地址修改为阿里云 RDS MySQL 的内网连接地址，同时核对数据库账号、密码和端口。
如果应用使用配置中心或环境变量管理数据库连接，应统一修改配置来源，避免部分实例仍然连接旧库。
第 6 步：重启业务并验证功能
重新启动业务服务，进行核心功能与数据读写测试。
登录 RDS 控制台或使用客户端连接 RDS，执行以下命令，确认新的业务连接已经成功建立：
同时检查应用日志是否有连接失败、查询报错或事务异常。
业务恢复后还需要继续观察 RDS 的 CPU、连接数、慢查询、锁等待和应用错误率。暂时不要释放原 ECS 自建库，也不要清理 DTS 配置和备份，保留一段回退窗口。确认数据一致、业务稳定后，再下线旧库连接并清理迁移过程中的临时任务。
迁移过程中，真正需要谨慎处理的是数据一致性和切换窗口。实例创建和网络配置都是准备工作，只有确认增量追平、应用能够稳定连接、关键数据校验通过，才算完成迁移。
为什么同规格下差别这么大
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 在资源、运维和故障处理上的压力，而不是替代所有数据库优化工作。