事务 ID 回卷
大多数人最初意识到这个问题，认为他们需要监控的问题，就是事务 ID 回卷本身，但从技术上讲，事务 ID 的耗尽才是真正的问题。PostgreSQL 在技术上能够很好地处理事务 ID 的回卷。但是，如果达到回卷点，事务 ID 会即将用完，这才是为什么回卷本身会令人担忧的原因。
检查事务 ID 耗尽
以下查询可以提供非常简单的数据，来指示问题的趋势/警报。
WITH max_age AS (
SELECT 2000000000 as max_old_xid
, setting AS autovacuum_freeze_max_age
FROM pg_catalog.pg_settings
WHERE name = 'autovacuum_freeze_max_age' )
, per_database_stats AS (
SELECT datname
, m.max_old_xid::int
, m.autovacuum_freeze_max_age::int
, age(d.datfrozenxid) AS oldest_current_xid
FROM pg_catalog.pg_database d
JOIN max_age m ON (true)
WHERE d.datallowconn )
SELECT max(oldest_current_xid) AS oldest_current_xid
, max(ROUND(100*(oldest_current_xid/max_old_xid::float))) AS percent_towards_wraparound
, max(ROUND(100*(oldest_current_xid/autovacuum_freeze_max_age::float))) AS percent_towards_emergency_autovac
FROM per_database_stats;percent_towards_wraparound 指标是设置警报的真正关键指标。由于它使用 age() 函数来确定事务 ID 值，因此它会考虑它们是否真的处于耗尽点，以查看回卷是否是一个真正的问题。如果达到耗尽，数据库将被迫关闭，并可能导致不确定的停机时间，以进行修复。此查询中有一点缓冲，因为它检查的上限（确切地说是 20 亿）小于导致耗尽的实际最大整数值。但它已经足够接近了，应该立即对达到 100% 的警报采取行动。
percent_towards_emergency_autovac 指标是我们建议监控的一个附加值，特别是对于以前从未监控过此指标的系统（请参阅下面有关冻结的近期好处的说明，了解何时可以调低该警报优先级或移除它）。它将监视数据库中达到 autovacuum_freeze_max_age 的最高事务 ID 值。
这是一个用户可调的值，默认值为 2 亿，当任何表的最高事务 ID 值达到该值时，在该表上会启动一次更高优先级的自动清理。您可以识别出这个特殊的清理会话，因为在 pg_stat_activity 中，它会被标记为 (to prevent wraparound)。从某种意义上说，它的优先级更高，即使禁用了自动清理，它也会运行，如果手动取消该清理，它几乎会立即再次重新启动。它还需要一些不同的内部低级锁，因此根据它们在紧急清理期间的锁定方式，可能会在这些表上引起稍高的争用。
如果您确实遇到争用/锁定问题，并且可以确认问题来源于紧急清理，那么取消它以完成其他事务也是完全安全的。请注意，它会继续重新启动，直到能够成功完成回卷式清理或运行了一次手动清理。
对于每秒事务数很高的数据库，想要避免紧急清理期的频繁出现，增加 autovacuum_freeze_max_age 可能是有益的。增加此值的主要问题是，它可能会增加数据目录下 pg_xact 和 pg_commit_ts 文件夹中的存储空间。同样，请阅读上面链接中的日常清理文档，了解调整此设置时的这些存储要求。一般可以将此值设置为 10 亿，不会有太大问题，但前提是需要确定有在监控回卷并且磁盘空间足够。
修复事务 ID 耗尽
要使最高事务 ID 的 age 值回落，最简单（但不一定是最快）的方法是，强制对整个数据库集群进行一次清理。要实现这种集群范围的清理，最好方法是用 PostgreSQL 附带的 vacuumdb 二进制实用程序。
vacuumdb --all --freeze --jobs=2 --echo --analyze--all 选项可确保对所有数据库都进行清理，因为事务 ID 是一个全局值。--freeze 选项可确保运行更激进的清理，以确保在该表中冻结尽可能多的元组（有关冻结的详细信息，请参阅日常清理）。
--jobs=2 允许并行运行多个清理。这应该设置在系统处理能力的范围内，以加快速度，但要小心设置得太高，因为它会导致额外的 IO 和更快地生成 WAL（增加磁盘使用率）。--echo 只是提供一些很小的反馈，以让您可以看到一些进度。
--analyze确保更新统计信息。如果很在意完成运行清理的时间，则可以将其关闭，稍后使用 --analyze-only 选项作为单独的步骤运行。
冻结的短期好处
在这里要提到的 --freeze 选项的另一个好处是，在未来的清理操作中，可以大大减少 IO 和 WAL 的产生。PostgreSQL 9.6 引入了一项功能，如果页面中的所有元组都已标记为冻结，则 vacuum 能够跳过该页面。PostgreSQL 11 在索引方面对此进行了进一步改进。
因此，如果您有很多旧表不再被写入，那么当它们因任何原因需要 vacuum 时，这是一个成本低得多的操作。这也让 percent_towards_emergency_autovac 警报不那么令人担忧，因为它不会产生太多意外的突发活动。因此，一旦你把事情调整好了，你可以把这个警报看作是低优先级的警告，甚至可以删除它，只用担心对回卷本身的监控。
