用 ECS 自建 MySQL 跑小应用到底图什么图便宜、图可控。可在我把应用迁到瑶池数据库 RDS MySQL 之后回头看这笔账其实没算对——不是 RDS 太贵而是自建的隐性成本被严重低估了。这篇文章就把我从自建 MySQL 迁移到瑶池 RDS 的完整过程记录下来包括方案怎么选、mysqldump 怎么用、切换当天怎么处理、以及迁完之后的账单对比给同样在 ECS 上自己维护数据库的朋友一个可以直接参考的实战样本。先说下背景应用不大高峰并发几十数据量不到 5GBMySQL 版本 8.0原先是应用和数据库挤在同一台 2核4G ECS 上。这种配置在个人项目和小团队里非常典型也是我写这篇的前提。如果你也是类似规模这篇文章会很有用如果你的库有几百 GB 甚至更大迁移思路可以参考但工具选型得调整我会在第二章说明白。1. 自建 MySQL 的隐形账单为什么小应用也扛不住1.1 那台“便宜”的 ECS拆开算并不便宜很多朋友自建数据库的初衷是省钱反正 ECS 都要买MySQL 是开源的装上去就能用何必多花一份 RDS 的钱这个逻辑乍看没问题但你得把账单拆开看。我当初的配置是一台 2核4G ECS40G ESSD 云盘包年折算下来大概每月 250 元左右云盘单独计费40G 大概 20 元/月快照如果开了一个月再多个 5-10 元。如果还买了固定公网带宽又是额外一笔。这还只是“应用和数据库共用一台机器”的情况。问题在于小应用跑着跑着会长大。当数据库和 Web 服务抢 CPU、抢内存、抢磁盘 IO 的时候你只有两个选择一是忍着接受高峰期页面卡顿二是给数据库单独买一台 ECS。如果单独买一台同规格的机器成本直接翻倍一个月就是 500-600 元往上走。到了这个阶段“自建省钱”的论点基本就不成立了。我见过不少团队嘴上说自建省钱实际上数据库服务器和应用服务器分开买了两台加起来一个月五六百元还只是裸算 ECS 和云盘费用后面那些隐性成本根本没算进去。1.2 除了月账单更大的成本是运维精力显性账单只是冰山一角真正把自建 MySQL 成本推高的是运维精力这部分在小团队里往往被忽略因为没人给“自己的时间”定价。先说基础维护MySQL 8.0 的补丁版本更新频繁每次升级都要先备份、再替换二进制、然后跑一轮测试安全补丁更要上心暴露在公网上的 3306 端口如果被扫到轻则被爆破重则数据被加密勒索。你还要处理 binlog 无限增长、临时表空间膨胀、慢查询堆积这些日常问题。我印象很深的一次半夜两点磁盘报警爬起来一看binlog 文件占满了 40G 云盘中的三分之一。那一刻我真的在认真思考人生。再说备份和恢复。自建 MySQL 的常规操作是写个 crontab 定时 mysqldump但有多少人真的定期演练过恢复流程我坦白说迁移前我一次完整的恢复演练都没做过全靠“应该没问题吧”撑着。真到数据损坏那天你面对的是一台可能已经写了几小时新数据的实例如果没有 binlog 增量备份丢几小时数据几乎是必然的。最后是故障处理能力。ECS 自建的 MySQL 是单点ECS 宿主机故障、云盘故障、内核 bug任何一个都能让你从睡梦中爬起来。自己搭主从又涉及半同步复制、脑裂处理、故障切换脚本小团队基本没有精力维护。这些成本很难精确到元但真实存在。1.3 触发我迁移的三个真实信号真正让我下决心迁移的是三个问题同时出现第一磁盘报警越来越频繁。binlog 占空间、慢查询日志占空间、临时排序文件也占空间40G 云盘怎么清都不够用扩容又要停机操作。第二我发现自己长期活在“备份恐惧”里。每次要动数据库结构第一反应是手动导一份 SQL 文件存到本地因为我不确定自动备份任务到底有没有在正常工作更不确定那份备份能不能恢复。第三MySQL 版本升级的需求来了。应用需要用到 8.0 的新特性而自建升级意味着再一次完整走一遍备份、升级、回滚预案的流程周期至少一个晚上还不敢保证一次成功。这三个信号叠加在一起让我认真评估了瑶池数据库 RDS MySQL。对比之后发现RDS 自带的自动备份、一键升级、监控告警恰好就是我在自建场景里一直想做但又没做好的事。于是迁移这事就正式排上了日程。2. 迁移路线怎么定全量导出还是 DTS以及 RDS 规格选择2.1 两种迁移路径的适用边界先把结论放在前面小数据量、可接受短停服的场景直接用 mysqldump 全量导出导入就够了数据量大、几乎不能停服的场景用数据传输服务 DTS 做全量加增量同步。这两种方案我在评估时都测过各有适用边界。mysqldump 全量方案的逻辑很简单在业务低峰期停服导出全量数据导入 RDS切换连接串启动应用。优点是工具通用、流程透明、每一步都可控缺点是需要一个停服窗口窗口长短取决于数据量和导入速度。DTS 全量加增量方案的逻辑是先做一次全量迁移再通过解析源库 binlog 持续同步增量数据等到两边追平后手动切换。优点是停服时间能压缩到分钟级甚至业务无感缺点是需要源库开启 binlog 且格式为 ROW需要额外创建迁移账号并授权对表结构、主键、字符集也有一些兼容性要求。以我的场景为例数据量不到 5GB业务形态是内部工具加小 C 端应用凌晨两点基本没有流量停服 5-10 分钟完全可接受。所以我选了 mysqldump 全量方案省去 DTS 的配置成本和 binlog 相关的前置改造。如果你的库超过几十 GB或者业务 7x24 小时都有写入DTS 方案值得优先考虑。2.2 RDS 规格选型基础版与高可用版的取舍瑶池数据库 RDS MySQL 在购买时面对的第一个选择题就是“基础版”还是“高可用版”。这两个词的差异简单说基础版是单节点架构只有一个数据库实例胜在便宜适合开发测试环境或对可用性要求不高的场景高可用版是一主一备架构主库故障时自动切换到备库RPO 和 RTO 都有保障适合生产环境价格大概是同规格基础版的一倍左右。我当时纠结了很久最终还是选了基础版 2核4G。原因是第一应用本身对分钟级故障可以容忍真有故障大不了重启服务第二预算有限能省则省第三瑶池 RDS 后续可以升级到高可用版不用重新迁移数据相当于给自己留了后悔药。这里有一个值得注意的点升配容易降配难如果你的业务处在增长期建议一开始就按半年后的预期规格来买别省那点钱后面又折腾一次迁移。存储方面小应用建议从 100G 起步。别按当前用量买RDS 的存储扩容虽然可以在线操作但扩容过程会产生额外的 IO 开销和费用而且磁盘使用率超过 80% 之后性能下降会比较明显。100G 对小应用来说既不会太浪费又留下了足够的缓冲空间。2.3 地域、VPC 内网与白名单准备RDS 选地域的原则就一条和你的 ECS 在同一个地域最好在同一个 VPC 内。这样应用连数据库走内网不走公网既能省下公网流量费延迟也更低。我在实操中踩过一个坑创建完 RDS 实例后控制台默认白名单是空的应用连数据库直接超时。原因很常见——我只在 RDS 控制台加了 ECS 的公网 IP没有加内网 IP。ECS 和 RDS 同 VPC 互通时走的是内网源 IP 是 ECS 的内网地址所以白名单里必须放行 ECS 的内网 IP比如 172.16.0.0/16 这个网段下的具体 IP。如果你不确定 ECS 的内网 IP 是多少ECS 控制台实例详情页里能看到。账号权限方面我建议分两个账号一个高权限账号用来管理 DDL一个业务账号只给 SELECT、INSERT、UPDATE、DELETE 权限。不要图省事让业务代码去连高权限账号一旦代码注入或被拖库损失会大得多。RDS 控制台创建账号时能精细控制权限这个能力自建 MySQL 里要手动 GRANT体验完全不同。3. 迁移实操记录从 mysqldump 到行数校验的完整流程3.1 盘点库表、字符集与权限迁移前一定要先盘点这一步直接决定后面导入流程顺不顺利。我是用下面几条 SQL 来摸底的-- 统计各表行数注意InnoDB 的 table_rows 是估算值仅用来了解量级 SELECT table_name, table_rows, data_length, index_length FROM information_schema.tables WHERE table_schema appdb ORDER BY data_length DESC; -- 查看库的默认字符集和排序规则 SELECT default_character_set_name, default_collation_name FROM information_schema.schemata WHERE schema_name appdb;把库里的表、数据量、字符集摸清之后还要确认几类容易被忽略的对象是否有触发器、存储过程、函数、事件调度器。这些对象在业务代码里往往隐藏得很深如果漏导应用可能运行几天后才暴露出某个定时任务没有执行。可以在源库执行-- 查看所有触发器 SHOW TRIGGERS; -- 查看所有事件调度器 SELECT event_name, status, execute_at FROM information_schema.events; -- 查看所有存储过程和函数 SELECT routine_name, routine_type FROM information_schema.routines WHERE routine_schema appdb;盘点完这些我心里就有底了这个库有 3 个触发器、2 个存储过程、1 个事件调度器字符集是 utf8mb4 / utf8mb4_unicode_ci。注意这个排序规则的细节后面导入时会用到。3.2 mysqldump 参数解读与一次权限报错盘点完成后我在源库创建了一个专用的备份账号然后执行导出命令mysqldump \ -h 源库内网IP -P 3306 \ -u backup_user -p \ --single-transaction \ --routines \ --events \ --triggers \ --set-gtid-purgedOFF \ --default-character-setutf8mb4 \ --max-allowed-packet256M \ --databases appdb appdb.sql逐行解释几个关键参数因为不少教程要么不给参数要么给一堆没用的--single-transaction基于 InnoDB 的 MVCC 机制在一个事务里做一致性快照导出过程中不锁表业务可以继续写入。这是 8.0 自建库导出最推荐的参数没有之一。--routines、--events、--triggers分别导出存储过程/函数、事件调度器、触发器。不加这三个参数你会丢东西。--set-gtid-purgedOFF如果源库开启了 GTID导出文件里会带上SET GLOBAL.GTID_PURGED语句导入到 RDS 时可能因为 GTID 状态不匹配而报错。这个参数把它关掉避免不必要的兼容性问题。--max-allowed-packet256M防止某些大字段或大批量插入语句在导出/导入时超过默认包大小限制触发Got a packet bigger than max_allowed_packet bytes的错误。--databases appdb带上库名导出文件里会包含CREATE DATABASE和USE appdb语句导入时更方便。这里我遇到了一次权限报错ERROR 1227 (42000): Access denied; you need (at least one of) the PROCESS privilege(s) for this operation。原因是--single-transaction需要 PROCESS 权限来查看当前事务而我创建的备份账号只有 SELECT 和 SHOW VIEW。解决办法是在源库执行GRANT SELECT, SHOW VIEW, TRIGGER, EVENT, PROCESS ON *.* TO backup_user%; FLUSH PRIVILEGES;注意PROCESS是全局权限不能只授给某个库所以这里必须用*.*。这套权限组合是 mysqldump 做一致性导出的典型最小权限集值得记下来。3.3 导入 RDS 时的兼容性处理先在瑶池 RDS 控制台创建目标库和目标账号。这里有个细节RDS 控制台创建数据库时会让选字符集和排序规则一定要选和源库一致的utf8mb4和utf8mb4_unicode_ci。如果默认选了utf8mb4_0900_ai_ci虽然大部分情况下没问题但索引排序和某些字符的等价判断结果会变最稳妥的做法是和源库保持一致。导出的 SQL 文件里每条 CREATE TABLE 都带有原来的字符集和排序规则信息理论上导入时会自动覆盖库级别设置。但保险起见我建议先只导入结构检查没有问题再导数据。操作方式是把导出文件里的 INSERT 语句去掉或者分两步导出。实际上我更推荐这样操作第一步用--no-data先导一份纯结构文件导入 RDS 后用SHOW CREATE TABLE抽查几张核心表确认结构没问题再导入包含数据的完整文件。多花两步能省去导入到一半才发现字符集对不上的痛苦。导入命令很简单mysql \ -h RDS内网地址 -P 3306 \ -u rds_user -p \ --default-character-setutf8mb4 \ appdb.sql导入过程中遇到的真实报错和大家分享两个第一个是存储过程相关的ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled。这是因为 RDS 账号默认没有 SUPER 权限而创建存储过程时如果数据库开了 binlog会要求账号有 SUPER 或SET_USER_ID权限。解决办法是在 RDS 控制台将参数组里的log_bin_trust_function_creators设置为 ON。注意这个参数在 RDS 控制台可以改改完不需要重启。第二个是导入文件里的DEFINER问题。如果你之前的表、视图或存储过程定义了特定归属者导出文件里会包含DEFINER语句导入到 RDS 时如果这个归属者不存在就会报ERROR 1449 (HY000): The user specified as a definer does not exist。处理办法很简单导出后用 sed 把文件里的 DEFINER 都替换掉sed -i s/DEFINER[^*]*\*/\*/g appdb.sql这条命令会把DEFINER和后面的一段内容替换成空的让导入时使用当前账号作为归属者。对我这种小应用足够用如果场景复杂还是建议在源库就把归属者统一管理清楚。3.4 一致性校验行数、最大 ID 与抽样数据导入完成后不能只看“命令执行成功”就以为万事大吉。我用的是三种校验方法组合起来基本能覆盖数据完整性的检查。第一种是逐表行数对比。小应用表不多我写了个简单的 Python 脚本分别连源库和目标库逐表执行SELECT COUNT(*)然后对比。注意这里不能用information_schema.tables的table_rows字段因为 InnoDB 的这是一个估算值不是精确行数。这个脚本很快5GB 的库大概几分钟能跑完。第二种是自增主键最大值对比。对于有自增主键的表直接对比MAX(id)如果有主从复制或导入过程中有写入这个值能快速暴露问题。命令如下SELECT MAX(id) FROM 核心表名;第三种是抽样数据校验。我挑了几张数据比较敏感的表用MD5或CHECKSUM对抽样行做校验。比如对比某张订单表的最近 1000 条记录是否一致SELECT MD5(CONCAT_WS(|, id, user_id, amount, created_at)) FROM 订单表 ORDER BY id DESC LIMIT 1000;两边执行同样的查询对比结果是否一致。这个方法的原理是如果两边的数据有任何细微差异MD5 值大概率会不同。三种校验都通过后我对数据完整性基本放心了进入切换环节。4. 切换当天停服窗口、验证清单与回滚预案4.1 如何把停服窗口压到 5 分钟我把切换安排在凌晨两点这个时段我的应用几乎没有任何写入。整体流程是先停应用服务再导出最后一次增量数据导入 RDS最后把应用连接串切到 RDS 并重启。为什么停服后还要再导一次增量因为在第 3 章那次全量导出之后到正式切换之前业务可能已经有了新的写入。为了解决这个窗口我在切换当天重新执行了一次完整的 mysqldump 导出导入。由于数据量小全量导出一遍只需要两三分钟这比做增量同步要简单得多。具体时间线大概是02:00停应用服务入口切到维护页02:01在源库执行最后一次 mysqldump导出到本地02:03把 SQL 文件导入 RDS02:06修改应用配置文件里的数据库连接地址从 ECS 内网 IP 改成 RDS 的内网域名02:07启动应用观察日志和接口02:15确认无异常撤下维护页。整个过程不到 15 分钟其中真正影响业务的只有 7 分钟。这是小应用迁移的主场优势不需要搞复杂的 DTS 增量不需要写同步脚本一次全量导出足够。如果你的应用有两台以上 ECS配置文件改起来会麻烦一些建议提前把所有机器的连接串都准备好切换时逐台发布。更规范的做法是先把新连接串作为环境变量配置好切换时只改环境变量指向应用不用动。4.2 切换后的验证清单切换完成后我有一份自己总结的验证清单照着走一遍能覆盖绝大多数问题应用健康检查接口是否返回正常核心业务链路是否通注册、登录、下单、支付回调等每个都实际点一遍定时任务是否执行我在第 3 章提到过源库有一个事件调度器如果 RDS 的event_scheduler参数默认是 OFF这个任务会静默失效。这是一个非常隐蔽的坑建议拿一张有定时任务的表看切换后有没有新数据写入慢查询日志和错误日志有没有异常RDS 控制台直接看自建时还得自己配监控这里省了不少事连接数是否符合预期RDS 默认的max_connections可能比你自建时调得低如果应用连接池没有限制最大连接数有可能直接把连接数打满核心页面的响应时间对比迁移前的基准值确认没有明显劣化。验证时有一个技巧先把维护页撤下但保持数据库侧的应用账号只读等确认所有页面正常后再放开写权限。不过我这个做法只适合小应用内部切换时用对外业务还是按“快速切换、快速验证”的节奏来毕竟只读窗口拉太长会影响用户体验。4.3 回滚预案旧库保留多久、怎么留切换前我做的唯一一件“浪费”但极其重要的事就是没有动旧库。旧 ECS 上的 MySQL 保持原样没有停、没有删、没有把磁盘清空只是应用不再连它了。一旦新环境出现问题且短期无法解决回滚只需要两步把应用连接串改回旧 ECS 内网 IP重启应用。因为旧库一直开着数据还在切换时刻的最终状态。这里有一个细节切换之后新库会产生新写入所以回滚时这些新数据需要想办法同步回旧库。我的处理办法是一旦确定需要回滚立刻停应用把新库的最新数据用 mysqldump 导出一份再导入旧库然后恢复应用连接。这本质上和正向迁移是同一个流程只是方向反了。以我的经验真正需要回滚的情况很少。大部分问题在验证清单阶段就能发现并解决。但“用不上”的预案不代表不值得准备心理层面的安心价值很大。旧库我保留了两周确定新环境稳定后才关闭在 6.3 节我会详细说保留周期怎么定。5. 迁移后的成本对比月账单与隐性成本5.1 同规格下的两张账单先说结论我的实际月账单迁移后没有变贵基本持平但数据库的可用性、备份能力、监控能力全面提升了一个档次。直接贴我自己的账单对比所有价格按包年折算或实际扣费记录地域是某二线城市可用区仅供参考不同地域和不同的活动折扣会有出入。如下表成本项自建 MySQL迁移前迁移到瑶池 RDS 后应用 ECS 2核4G约 250 元/月缩配到 1核2G约 120 元/月数据库承载与应用共用同一台 ECS隐性抢资源RDS 基础版 2核4G约 260 元/月云盘/存储40G ESSD约 20 元/月RDS 存储 100G包含在 RDS 费用套餐内未单独计费快照/备份手动 mysqldump未计费但无保障RDS 自动备份备份存储容量在免费额度内未产生额外费用公网带宽固定带宽约 100 元/月走内网访问数据库这项无需重复购买合计约 370-390 元/月约 380 元/月这里有一个容易被忽略的点迁移后我把应用 ECS 从 2核4G 缩到了 1核2G。因为数据库搬走之后应用本身的负载用 1核2G 完全够用。如果不缩配总成本反而会上升。这也是不少团队迁到 RDS 后感觉“变贵了”的原因——他们保留了原来的 ECS 规格又额外掏了一份 RDS 的钱两边都付了。如果你原来就是“应用一台机器、数据库一台机器”的自建模式那迁移到 RDS 后大概率是直接省钱的。因为 RDS 基础版的费用通常低于一台同规格专门跑数据库的 ECS 费用而且省掉了快照、备份、监控等额外配置的成本。5.2 备份、监控、安全这些看不见的差异账单之外的对比才是自建和 RDS 差距最大的地方。自建时我备份靠 crontab 里的 mysqldump 脚本且不说脚本本身也可能挂掉关键是没人保证恢复过程没问题。RDS 的自动备份是平台能力控制台能看到备份记录还能随时用备份创建新的临时实例来验证数据。监控方面自建时我得额外部署一套监控系统看 CPU、内存、磁盘、连接数、慢查询。RDS 控制台把这些全内置了还能设置告警规则磁盘使用率超过阈值就往钉钉或短信推。迁移后第一天我就把慢查询、磁盘、CPU、连接数的告警全部配好这种“有人在看着”的感觉自建时代真的没有。安全方面RDS 自带白名单、SSL 加密、SQL 注入检测、透明数据加密等能力。这些功能如果在自建环境实现需要部署额外组件成本和工作量都不小。对小团队来说这些安全能力用不用是另一回事但有和没有是完全不同的风险级别。把这些隐性成本量化一下假设一次数据库故障耗时 2 小时按开发者时薪 100 元计直接成本 200 元业务中断的损失另算。RDS 高可用版能把故障概率显著降低基础版虽然单节点但也有自动重建能力和数据冗余保障。对于小应用这笔账算下来RDS 的价值已经不是“方便”而是“用一份合理费用买了一份可靠”。5.3 观察一个月基础版够不够用迁移完成后的一个月我做了持续观察。结果是这样CPU 使用率业务高峰时基本在 30%-50% 之间2核4G 对当前负载来说算比较宽裕连接数方面应用连接池最大配置 50RDS 默认max_connections几百个完全够用磁盘使用率因为从 40G 换到 100G加上 binlog 清理策略更好长期维持在低水位。基础版的唯一短板是高可用性如果底层出现故障RDS 会尝试重建实例过程中可能有几分钟不可用。对我不算什么大问题但如果你做的是电商交易、支付这类对连续性敏感的业务建议直接上高可用版别拿基础版赌运气。另外我注意到瑶池 RDS 控制台里可以一键变配从基础版升到高可用版或者调整规格不需要重新迁移数据。这是自建 MySQL 最头疼的地方——想升级架构就得量数据、开窗口、做演练。RDS 把这个过程压缩到了控制台操作而且变配过程中业务影响很小。这一点的价值只有经历过自建升级的人才能真正体会。6. 迁移后的收尾事项别急着释放旧机器6.1 参数与连接池配置切换到 RDS 之后有几个参数我建议根据应用情况调整不要直接用默认值跑生产。第一个是event_scheduler。RDS 的默认值可能是 OFF你的定时任务如果依赖 MySQL Event必须把它打开否则任务静默失效。RDS 控制台参数组里可以改改完立即生效。第二个是slow_query_log和long_query_time。RDS 自带慢查询日志但默认不一定开了记录阈值。建议把long_query_time设为 1 秒这样连到 RDS 后业务代码里那些隐藏的慢 SQL 能被及时抓到而不是等用户反馈卡顿之后再去翻日志。第三个是应用连接池。自建 MySQL 时你可能习惯了把连接串写成jdbc:mysql://内网IP:3306/appdb迁移后要改成 RDS 给的内网域名。同时把connectTimeout、socketTimeout配置清楚避免网络波动时应用线程长时间挂起。连接池的最大连接数不要盲目调大RDS 的连接数上限是有限资源连接池撑爆实例连接数反而会导致整个应用不可用。我在迁移后顺手做了一件事把所有 SQL 里依赖数据库本地时间的逻辑改成显式指定时区。原因很简单ECS 自建和 RDS 的默认时区可能不同如果业务代码用NOW()或者CURRENT_TIMESTAMP又依赖特定时区迁移后很可能出现时间偏差。RDS 控制台可以设置默认时区为中国标准时间但如果你的应用是多地域访问建议统一在连接串里指定serverTimezoneAsia/Shanghai。6.2 备份策略与真实恢复演练RDS 的备份策略默认是开启的但你怎么设置窗口和保留周期也很重要。自动备份时间窗口建议放在业务低峰期比如凌晨。备份保留周期小应用设置 7 天足够如果磁盘费用也不高可以保留 15 天到 30 天看你的数据需求和成本预算。重点想说的是恢复演练。自建时代最大的隐患就是“备份了但没验证过”迁移到 RDS 之后这个隐患终于能轻松消灭了。RDS 控制台支持用备份创建一个临时实例你可以在这个临时实例上执行几条关键查询或者直接跑一遍业务初始化脚本确认备份数据是可用的。整个过程不需要搭建额外环境也不需要准备新机器。我当时做了一次演练从当天自动备份里克隆了一个临时实例然后在上面执行了SELECT COUNT(*)检查核心表又跑了一个查询脚本确认备份数据能正常支撑应用启动。这个演练在自建时代至少要半小时起步在 RDS 控制台上几分钟就完成了。从那之后我对“备份可用”这件事是真的放心了。6.3 旧 ECS 的保留周期与归档旧库和旧 ECS 的处置我的建议是“留两周想清楚再释放”。第一周保留旧 MySQL 实例运行。这样如果新环境出现严重问题随时可以回滚。这一周内应用已经完全不依赖旧库了所以不需要维护它但也不要顺手删掉数据文件。第二周如果业务运行平稳可以把旧 MySQL 服务停掉但 ECS 不要立刻释放。这一步的目的是让团队消化和沉淀把自建时代的配置、脚本、积累的 SQL 诊断经验整理成文档把原来的 ECS 缩配或改作他用。我实际操作时把旧 ECS 上的 MySQL 服务停了但保留了数据盘万一之后要做数据分析还能直接查旧库。第二周结束后我的做法是把旧 ECS 释放但释放前做了一件事把旧库的最后一份完整导出文件保存到了对象存储里作为最终归档。这样即便以后发现迁移丢了什么还有一个最终的兜底存在成本几乎为零。还有一个细节值得提整个迁移过程中我把所有命令、参数、账号权限、报错信息都记录到了一个文档里。一开始只是为了方便自己排查后来发现这套“迁移 SOP”非常有用——身边有朋友要迁移时直接发文档过去他照着走一遍就能完成省去了重读命令文档和踩一遍同样坑的时间。如果你也要迁强烈建议从第一天就开始记录别等迁完了再回忆。最后再分享一个小技巧迁移后的一到两周一定把慢查询和错误日志的告警开着。自建 MySQL 时代的很多 SQL 写法可能在非严格模式下勉强能跑到了 RDS 默认参数更严格的 8.0 版本下就会暴露问题。比如某些聚合查询、隐式类型转换、排序规则不一致造成的索引失效都是迁完后才慢慢浮现的。开着告警你才能第一时间发现这些隐藏的兼容性问题。