回滚要保留数据迁移的兼容路径.md
机制
镜像/代码的回滚是换一个 tag(可追踪、可复现),成本极低;数据库结构变更是一次性、不可逆的。两者不对称:
代码回滚:docker pull <上一个 commit SHA> + up -d ← 秒级
数据回滚:无(除非迁移本身写了向后兼容)
⇒ 旧版本代码若读不懂新结构(或缺列、缺表),回滚就等于把服务打挂。因此:
- 迁移优先选向后兼容的形态:先加列/加表、双写、再切读,最后才删旧结构。
- 破坏性变更(删列/改名)要和代码切换分开发布,中间留一个「新旧都能跑」的版本。
- 回滚步骤必须在发布前就写下来并验证过,不是事后补文档。
相关
- 停机前先确认有可恢复备份
- 滚动部署期间改库结构会撞上旧容器的锁
- Schema是声明Migration是历史
- 改远端库结构前先确认库身份与回滚
- 存量不会自动跟上新逻辑