把自建数据库迁到云 RDS，目标是"少停机甚至不停机、数据不丢"。用 DTS（数据传输服务）能大幅降低难度。
数据层的稳定性，往往决定了一个系统的下限。「数据库平滑迁移上云：DTS 实战与割接」所涉及的数据库迁移与平滑割接，正是最容易「平时看不见、出事要人命」的部分：平时跑得平稳，一旦出问题就是数据丢失或业务停摆，因此值得投入系统性的精力去治理。
迁移流程
结构迁移 → 全量迁移 → 增量同步。DTS 持续追平源库 binlog，业务读写仍在源库，直到最后割接，把停机窗口压到最短。
前置检查
源库开启 binlog（ROW 格式）、准备足够权限的账号、确认字符集与排序规则一致、评估目标库规格与参数。
数据校验
用 DTS 的数据校验功能比对全量与增量的一致性，重点关注行数和关键表的校验结果。
割接窗口
停写源库 → 等增量延迟追平到 0 → 校验数据 → 应用切换到目标库连接 → 观察运行。可先灰度部分流量验证。
回滚预案
割接后保留源库一段时间，必要时反向同步或切回，确保任何时候都能回退。
小结：迁移的稳妥来自"增量同步 + 充分校验 + 明确回滚"，别赌一把梭直接切换。
割接脚本要写成带时间盒的演练，而不是操作清单
很多迁移失败并不是技术问题，而是窗口失控：某一步比预想慢，后面的步骤被迫压缩，最终在「继续还是回退」之间反复犹豫，错过了最佳决策点。把割接当成一次带计时的演练来准备，可以显著降低这种风险。
- 每步计时：停写、追平延迟、数据校验、连接切换、业务验证，逐步骤记录实际耗时。演练至少两轮，用第二轮的数据来定窗口，第一轮的数据通常偏乐观。
- 明确判定点：事先约定在哪个时间点、哪个指标不达标就触发回退，并写成具体时间而不是「视情况而定」，避免现场临时讨论。
- 校验要可量化：不只看总行数，还要对关键表做抽样比对与业务侧校验，例如按时间范围统计的记录数与金额合计，并保留校验脚本和输出结果。
- 切换要可控：应用侧的数据库连接应通过配置中心或统一连接串管理，切换时不需要重新发布；有条件时先灰度部分流量验证，再放量到全部。
- 源库先留后拆：割接成功后源库保持只读状态保留一段时间，确认无异常再下线，同时严格避免双写造成数据分叉。
演练的价值还在于让参与者熟悉自己的动作：谁负责停写、谁负责校验、谁负责宣布结果、谁负责对外沟通，角色明确之后，真正的窗口里沟通成本会低很多，也不会出现两个人同时改同一处配置的情况。
从排查到预防：把经验沉淀为机制
- 慢的问题先定位再动手：用执行计划与监控数据说话，避免凭感觉改索引、改参数。
- 变更留痕：每一次调整记录原因与预期，便于复盘与回退。
- 容量预警前置：为存储、连接数、内存等关键水位设置提前量告警。
- 演练常态化：把恢复演练、切换演练纳入日常，而不是出事才第一次做。
机制化的沉淀，能让数据库迁移与平滑割接从「个人经验」变成「团队能力」。
数据库迁移与平滑割接的三个基本盘
其一是可恢复性：备份的价值不在于「做了」，而在于「能恢复」，定期演练恢复流程比增加备份份数更重要。其二是可回滚性：任何结构或参数变更都应有回退路径，避免把生产当试验场。其三是可预估性：容量与增长趋势要有数据支撑，而不是等到告警才响应。
这三个基本盘稳固之后，再去做性能调优和架构升级，风险会小很多。