Marico's space
最近折腾了一个生产环境的数据库迁移，从阿里云RDS换到新版本，踩了几个坑，这篇把思路和具体做法说清楚。
数据库迁移是把数据从一种存储系统、格式或环境搬到另一个地方——可以是本地服务器迁到云，也可以是直接换数据库引擎。核心挑战是在数据完整性和业务可用性之间找平衡。传统的"大爆炸"迁移方式可能需要几小时甚至几天的停机时间，这对7x24小时运营的企业来说完全不可接受。
一次结构完整的迁移远远不只是把行和列搬过去。首先要做的是评估和规划——对源库和目标库都要审查，包括数据量、Schema兼容性（同类还是异构迁移）以及网络延迟，确保复制流量能正常处理。然后是Schema转换，异构迁移（比如MongoDB到PostgreSQL）需要用工具或自定义脚本把NoSQL BSON文档映射到关系型SQL结构，AWS有SCT这样的工具，也很多人写自定义脚本搞定。最后是数据清洗，在迁移前把历史数据归档并标准化，避免把"脏数据"带入新环境。
选哪种策略取决于你的恢复时间目标(RTO)和预算。以下是三种最常用的数据库迁移策略及各自适用场景：
1. 大爆炸迁移 — 在计划的维护窗口内一次性完成所有数据迁移。执行简单且无需数据同步，但风险很高且需要大量停机时间，最适合小型非关键数据库。
2. 增量（分阶段）迁移 — 数据逐步转移，新旧系统并行运行。风险较低且支持实时验证，但管理复杂度很高，需要双向同步来防止数据漂移，适合可以短期接受双系统并行的场景。
3. 零停机迁移（实时复制） — 企业级应用的最佳方案。在目标环境搭建生产库的副本，通过变更数据捕获(CDC)保持两个系统同步直到最终切换，停机时间几乎为零，回滚也很简单，专为需要24x7在线的关键业务设计。
MySQL——主从切换：先用mysqldump或Percona XtraBackup做初始数据导出，恢复到目标端，然后启动二进制日志(Binlog)复制来追平导出期间的增量数据。当复制延迟归零后，把应用切到新库。
PostgreSQL——逻辑复制：PostgreSQL的逻辑复制支持跨大版本迁移（如从PG 12到PG 16），延迟接近零。与物理复制不同，它能只同步指定的表，迁移过程中更灵活。
MongoDB——副本集Oplog尾追：向目标环境的副本集添加新节点，通过Oplog从主节点同步数据。跨平台迁移（比如迁到MongoDB Atlas），可以用Mongomirror这类工具自动化整个过程。
即使做了充分规划，迁移过程中仍会遇到各种边界情况。以下是六个最常见的失败模式：
复制延迟飙升 — 导致切换时数据丢失。预防：计划切换前设置延迟阈值告警，保持在5秒以下。
切换后Schema不匹配 — 应用崩溃并出现NULL约束错误。预防：切勿跳过Schema兼容性检查，尤其是异构迁移场景。
静默数据损坏 — 行数一致但校验和不匹配。预防：对每个关键表使用MD5/SHA校验和验证，不能只检查行数。
网络带宽不足 — 迁移耗时远超预期，复制始终无法追上。预防：根据数据量提前测试网络容量，第一天就做这件事。
缺少回滚方案 — 切换失败但无法恢复。预防：保留源库作为实时备份，维持反向CDC流直到各方确认，并在文档中明确回滚时间窗口。
切换后索引膨胀 — 查询性能在上线后几天内持续下降。预防：切换后立即执行VACUUM/ANALYZE（PostgreSQL）或OPTIMIZE TABLE（MySQL）。
严格的测试策略是区分成功迁移和午夜回滚的关键。
迁移前：验证备份可用、审查Schema兼容性、测试网络吞吐量、在类生产环境至少跑两次完整演练、文档化回滚计划。
迁移中：持续监控复制延迟、盯住CDC错误率、切换前确保延迟低于5秒、保持源库作为实时回滚点。
迁移后：校验行数、执行MD5/SHA校验和检查、与业务方一起做UAT、跟进索引重建和查询计划审查。
核心结论很明确：大多数迁移失败都是可以预防的。平稳切换和代价高昂的故障之间，差的就是准备充分、工具选对、以及在迁移生命周期每个阶段都严格执行测试策略。