3

我正在对大型数据库执行架构更改，纠正古老的设计错误（将主键及其相应的外键从INTEGERto 扩展BIGINT）。基本流程是：

  • 关闭我们的应用程序。
  • 删除数据库触发器和约束。
  • 执行更改（ALTER TABLE foo ALTER COLUMN bar TYPE BIGINT对于每个表和主/外键）。
  • 重新创建触发器和约束 ( NOT VALID)。
  • 重新启动应用程序。
  • 验证约束（ALTER TABLE foo VALIDATE CONSTRAINT bar对于每个约束）。

笔记：

  • 我们的 Postgres DB（版本 11.7）和我们的应用程序托管在 Heroku 上。
  • 我们的一些表非常大（数百万行，最大的是 ~1.2B 行）。

问题出在最后的验证步骤中。当条件刚刚“合适”时，单机ALTER TABLE foo VALIDATE CONSTRAINT bar可以以超过 WAL 的写入容量的速度创建数据库写入。这会导致不同程度的不愉快，直至数据库服务器崩溃。（我的理解是 Heroku 使用定制的 WAL 插件来实现他们的“持续备份”和“db follower”功能。我已经尝试就这个问题联系 Heroku 支持 - 他们的回应没有帮助，即使我们'重新签订企业级支持合同）。

我的问题：将这些限制留在该NOT VALID州有什么不利之处吗？

相关：有谁知道为什么验证约束会产生如此多的写入活动？

4

1 回答 1

0

将约束视为无效有缺点。首先，您可能有不符合约束要求的数据，这意味着您有不应该在表中的数据。但是查询规划器也不能使用约束谓词来排除满足或不满足约束要求的行。

至于所有 WAL 活动，我只能想象那是因为它必须为这些行设置标志以将它们标记为有效。相对于实际的行更新，这应该会产生相对少量的 WAL，但我想如果你有足够的行被验证，它将产生大量的 WAL。除非存储已满，否则这通常不会导致崩溃。

于 2020-05-21T07:22:35.713 回答