Postgres必须设置用于防止事务ID回绕失败的监视和警报

防止 PostgreSQL 数据库中的事务 ID 环绕失败涉及设置监控和警报系统，以便在潜在问题导致严重问题之前主动识别和解决它们。 PostgreSQL 使用 32 位事务 ID，当达到最大值时，会发生回绕，这可能会导致数据损坏。以下是设置监控和警报的步骤：

监控交易 ID：

  • 定期监控PostgreSQL数据库中当前的事务ID。您可以使用以下查询来获取当前事务 ID：SELECT txid_current();
  • 跟踪事务 ID 随着时间的推移的增长率，以预测何时可能发生回滚。

设置数据库统计监控：

  • 启用并定期监控 PostgreSQL 的内置统计收集器。这可以在 postgresql.conf 文件中进行配置。 

# In postgresql.conf
stats_temp_directory = 'pg_stat_tmp'
track_counts = on

  • 使用pg_stat_bgwriter和pg_stat_database等查询来监控数据库统计信息。

其他措施：

  1. 实施监控工具：
    • 使用 Aurora、Nagios、Prometheus、Grafana 等监控工具或其他数据库监控解决方案来跟踪关键数据库指标，包括与事务 ID 相关的指标。
    • 配置定期执行的自定义脚本或查询以检查潜在问题。
  • 设置阈值和警报：
    • 定义关键指标的阈值，例如接近事务 ID 环绕限制。
    • 配置警报以在达到阈值或检测到异常模式时通知管理员。
    • 确保通过电子邮件、短信或其他可以及时引起数据库管理员注意的渠道发送警报。
  • 自动化预防性维护：
    • 安排定期数据库维护任务，例如清理和分析，以帮助管理事务 ID 的增长。
    • 考虑实施autovacuum流程来自动执行维护任务。
  • 定期检查和审查：
    • 定期检查监控配置，并在必要时根据历史数据和不断变化的数据库使用模式调整阈值。
    • 执行定期检查以验证警报是否按预期工作。
  • 日志记录和审计：
    • 在 PostgreSQL 中启用详细日志记录以捕获相关事件和错误。
    • 定期检查数据库日志以识别与事务 ID 相关的任何警告或错误。
  • 文档：
    • 记录监控设置和程序，以确保其他团队成员能够理解和维护监控系统。

    上下文原因：

    • Postgres TX id是32位的，即有一个4.2B id的值范围
    • 为了允许更多的TX，id被重用为模样式（您可以使用环结构来可视化它）。对于MVCC，PG需要知道哪些id是过去的，以便确定堆元组的可见性。一半的id（2.1B）在未来，另一半在未来。
    • 过去为了避免id耗尽，PG vacuum进程将TX id“冻结”在堆元组中：将它们设置为一个特殊值，表示“始终可见”。
    • 但是，如果新的id从id环中获取的速度比真空冻结的速度更快，就会出现一个问题：如果你比2.1B更接近.
    • 如果当前 TX 使用的是最老的非冻结 TX ID，那么这个 ID 就会突然出现在环的 "未来 "部分，从而使当前 TX 不再可见。这可不妙！因此，PG 会在您靠近时首先发出警告，最后关闭，允许您对 DB 进行抽真空处理。但您确实应该这样做。
    • 通过及早吸尘和进行监控以检测任何潜在的包裹相关问题，就不会出现这种情况。


    参考 PostgreSQL 内部原理并发控制