保持数据库变更跨发布兼容

映射每个读取者和写入者

在具有代表性脱敏数据的隔离架构上工作。您需要当前和下一个应用程序版本、对迁移框架的了解、经过审查的备份策略以及对长事务的可见性。包括工作进程、计划任务、报告和较旧的应用程序实例。API 可能快速更新，而长时间运行的工作进程仍在写入旧列。

我们的示例报告服务将导出标签存储于 label 并希望 display_name。这是一个设计示例，不是通用的可运行 SQL。在选择迁移语法或锁设置之前，请确认您确切的 PostgreSQL 版本和框架。

扩展而不淘汰旧表示

首先引入新的可空字段。部署一个兼容性发布，在单个事务中写入两个值，并在数据不完整时使用所需的回退进行读取。定义当客户在回填期间编辑记录时会发生什么。重试不得创建第二个逻辑导出。

PostgreSQL ALTER TABLE 操作会获取锁，级别取决于子命令。一个小改动可能在长事务后等待，然后阻塞其他工作。审查具体操作并在演练期间观察等待；增量并不意味着无锁。

技术参考： PostgreSQL ALTER TABLE · PostgreSQL 显式锁定.

使兼容性边界可见

对缺失值的回退无法检测非空但过时的新值。在切换读取者之前，淘汰仅旧写入者并验证一致性。在读取者切换后回滚到仅旧代码可能会重新产生分歧。相反，保留兼容性发布作为经过审查的恢复构件。

以有界、可重启的工作进行回填

查找需要复制的行，而不覆盖较新的客户编辑。使用稳定的排序、并发安全的更新条件和根据工作负载选择的批次。持久化进度，以便故障可以在已知边界处恢复。监控写入量、锁等待、请求延迟和复制（如果存在）。

没有适用于每个应用程序的安全批次大小。在演练中，将小批量与常规流量进行比较，然后选择暂停或停止规则。如果批次失败，在重试前检查已提交的内容。无限重试循环可能将可恢复的不匹配转变为持续的数据库压力。

检查语义，而不仅仅是已填充的行

验证缺失值、代表性标签、新记录和对现有导出的更新。计数非空行可能看起来正确，而值是从错误的来源复制的。针对部分填充的数据测试兼容性构件，并演练在部署之前启动的工作进程。

记录架构版本、迁移修订、完成标准和不兼容组合。在移除任何一个之前，检查回退使用和一致性。如果检查失败，停止回填或提升，保留证据并选择兼容的构件或经过审查的前向修复。不要声称应用程序回滚会重建已提交的数据。

在另一个经过审查的发布中淘汰旧字段

在回填和观察期满足您的标准后，移除旧的读取和写入。检查不频繁的作业以及交互式路由。删除旧字段属于后续变更，并有自己的恢复决策，这样发布问题就不会迫使您将代码修复与数据重建结合起来。

如果淘汰后出现坏数据，停止进一步损害并使用恢复计划或经批准的修复。不要仅仅因为工具暴露了回滚按钮就应用破坏性的向下迁移。将矩阵附加到 发布记录 并演练 数据恢复 在更改生产之前。有用的结果是明确的兼容性边界，而不是零停机保证。