我们是如何在零停机的情况下处理数据库迁移的

这项迁移在纸面上看起来很简单：添加几列，回填旧记录，然后将应用程序切换为读取新格式。风险在于该表全天都很繁忙，而且旧的 worker 代码在部署期间仍在运行。 我们将它拆分为三个版本发布。第一个版本添加了可为空的列，并同时写入旧字段和新字段。第二个版本在低流量时段分批进行回填，并使用了一个可以随时停止和恢复的任务，无需猜测进度。第三个版本在数据量匹配满一天后，将读取操作切换到新字段。 枯燥的检查清单拯救了我们：设置较低的锁超时时间、在副本上测试批处理大小、监控延迟的仪表板，以及不需要撤销架构变更的回滚路径。我见过有人把迁移仅仅当作一个 SQL 文件来处理。在实时系统上，部署顺序比 SQL 代码看起来是否整洁更为重要。