DB Migrations
Production schema changes fail when old and new code disagree during rollout. Prefer expand/contract: add compatible changes first, remove old shapes later.
When to Offer This Workflow
Trigger conditions:
- - ALTER TABLE in production; large table rewrites
- Blue/green deploys coupled to schema state
- Need zero-downtime or low-downtime migrations
Initial offer:
Use six stages: (1) classify change, (2) expand phase, (3) backfill & dual-write, (4) flip reads/writes, (5) contract phase, (6) verify & rollback). Confirm database engine (PostgreSQL, MySQL, etc.).
Stage 1: Classify Change
Goal: Additive vs destructive; lock risk (full table rewrite vs instant metadata change).
Exit condition: Migration labeled as expand or contract with risk notes.
Stage 2: Expand Phase
Goal: Add nullable columns or new tables without breaking currently deployed code.
Practices
- - Avoid DEFAULT clauses that lock large tables badly on some engines (use phased backfill instead)
Stage 3: Backfill & Dual-Write
Goal: Throttled batch backfill; dual-write old and new representations during transition when needed.
Stage 4: Flip Reads/Writes
Goal: Deploy code that reads new columns only after backfill completes; use feature flags for staged rollout.
Stage 5: Contract Phase
Goal: Drop old columns only after no code references them (search repo, logs, feature usage).
Stage 6: Verify & Rollback
Goal: Monitor errors, slow queries, replication lag; rollback = redeploy previous app version + avoid destructive steps until stable.
Final Review Checklist
- - [ ] Change classified; expand/contract path clear
- [ ] Additive migrations before dependent code
- [ ] Backfill throttled and verified
- [ ] Read/write cutover sequenced with flags
- [ ] Contract only after references gone
- [ ] Monitoring and rollback tested
Tips for Effective Guidance
- - Long transactions on migrations can cause outages—chunk work.
- Use online schema tools (pt-online-schema-change, etc.) when appropriate.
Handling Deviations
- - SQLite/embedded engines have different locking—validate per engine.
数据库迁移
新旧代码在部署过程中不一致时,生产环境的表结构变更会失败。推荐采用扩展/收缩策略:先添加兼容性变更,再移除旧结构。
何时提供此工作流
触发条件:
- - 生产环境执行ALTER TABLE;大型表重写
- 蓝绿部署与表结构状态耦合
- 需要零停机或低停机迁移
初始建议:
采用六个阶段:(1) 变更分类,(2) 扩展阶段,(3) 回填与双写,(4) 切换读写,(5) 收缩阶段,(6) 验证与回滚。确认数据库引擎(PostgreSQL、MySQL等)。
阶段1:变更分类
目标: 区分新增型与破坏型变更;锁定风险(全表重写 vs 即时元数据变更)。
退出条件: 迁移标记为扩展或收缩,并附有风险说明。
阶段2:扩展阶段
目标: 添加可空列或新表,不破坏当前已部署代码。
实践
- - 避免使用DEFAULT子句,某些引擎上可能导致大型表严重锁定(改用分阶段回填)
阶段3:回填与双写
目标: 限速批量回填;过渡期间按需对旧新表示进行双写。
阶段4:切换读写
目标: 仅在回填完成后部署读取新列的代码;使用功能开关进行分阶段部署。
阶段5:收缩阶段
目标: 仅在没有代码引用旧列时删除(搜索仓库、日志、功能使用情况)。
阶段6:验证与回滚
目标: 监控错误、慢查询、复制延迟;回滚 = 重新部署上一版本应用 + 在稳定前避免破坏性操作。
最终审查清单
- - [ ] 变更已分类;扩展/收缩路径清晰
- [ ] 新增型迁移先于依赖代码
- [ ] 回填已限速并验证
- [ ] 读写切换通过开关有序进行
- [ ] 仅在所有引用消失后执行收缩
- [ ] 监控和回滚已测试
有效指导技巧
- - 迁移中的长事务可能导致服务中断——分块处理。
- 适时使用在线表结构工具(pt-online-schema-change等)。
处理偏差
- - SQLite/嵌入式引擎具有不同的锁定机制——需按引擎验证。