[译] 使用 Cloud SQL for PostgreSQL 指标监控事务 ID 利用率

原文地址：Monitoring transaction ID utilization using Cloud SQL for PostgreSQL metrics
原文作者：Naresh Gandi

PostgreSQL 使用事务 ID（也称为 TXID 或 XID）来实现多版本并发控制语义（MVCC）。PostgreSQL 文档解释了 XID的作用如下：

PostgreSQL 的 MVCC 事务语义依赖于能够比较事务 ID (XID) 编号：插入 XID 大于当前事务 XID 的行版本是“在未来”并且不应该对当前事务可见。但是由于事务 ID 的大小是有限的（32 位），长时间运行的集群会遭受事务 ID 回绕：XID 计数器回绕为零，突然之间，过去的事务似乎在未来 - 这意味着他们的输出变得不可见。简而言之，灾难性的数据丢失。(…) 一个表可以取消清空的最长时间是 20 亿个事务 (…)。如果它的空置时间超过此时间，可能会导致数据丢失。

为了防止事务 ID 回绕，PostgreSQL 使用了一个真空机制，它作为一个名为autovacuum（默认启用）的后台任务运行，或者可以使用VACUUM命令手动运行。真空操作冻结已提交的事务 ID 并释放它们以供进一步使用。您可以将此机制视为事务 ID 的“回收”，尽管使用有限数量来存储事务 ID，但仍可保持数据库运行。

真空有时会由于工作负载模式而被阻止，或者它可能变得太慢而无法跟上数据库活动。如果尽管自动清理或手动清理执行了冻结，但事务 ID 利用率继续增长，则数据库最终将拒绝接受新命令以保护自己免受 TXID 环绕。为了帮助您监控数据库并确保不会发生这种情况，Cloud SQL for PostgreSQL 引入了三个新指标：

• transaction_id_utilization
• transaction_id_count
• oldest_transaction_age

了解交易指标

本节提供的指导适用于使用默认真空设置运行的 PostgreSQL 数据库。如果您的数据库被故意配置为延迟真空操作（例如出于性能原因），您可能会观察到不同的 TXID 使用模式。

无论配置如何，有关检测和缓解 TXID 使用问题的建议都应适用于所有数据库。

事务 ID 利用率和计数

事务开始时分配事务 ID，事务清空时将其冻结。这样一来，TXID 利用率就是未清空事务的数量（“已分配”减去“冻结”），表示为 20 亿最大值的一小部分。

在默认的 PostgreSQL 设置下，真空进程以最佳状态执行且无中断，大多数数据库的 TXID 利用率约为 10%。在繁忙的数据库中可以观察到更高的利用率水平，其中真空频繁地屈服于常规工作负载。如果利用率趋向于非常高的值（80% 或更高），则数据库可能会面临 TXID 耗尽的风险，除非允许清理以更快地进行。

Cloud SQL 提供了两个指标来描述 TXID 的使用情况：

database/postgresql/transaction_id_utilization将未清空事务的数量记录为 20 亿最大值的一小部分。您可以使用此指标进行监控或发出警报，以确保数据库不会遇到事务 ID 不足的情况。
database/postgresql/transaction_id_count记录分配和冻结的 TXID 数量。您可以使用此指标来了解有关您的 TXID 分配和真空模式的更多信息，例如在峰值负载期间每秒/分钟/小时分配了多少 TXID。

例子

下图显示了transaction_id_count“已分配”和“冻结”TXID 之间存在约 2 亿差异的指标。这似乎是一个很大的数字，但它只是 20 亿最大值的 10% 左右，而且该模式保持稳定，没有长期分歧的迹象。这是一个快乐的数据库！

另一方面，下图显示了一个数据库，它继续为新交易分配 TXID，但似乎没有冻结任何 TXID。这表明真空被阻塞。“分配”和“冻结”XID 之间的差异已经增长到约 10 亿（最大的约 50%），如果这种情况持续存在，该数据库可能会用完事务 ID。

这是transaction_id_utilization同一数据库的指标：

3 PostgreSQL 真空.jpg

最老交易年龄

PostgreSQL 只能清理已提交的事务。这意味着旧的（长期运行的）未提交事务将阻塞真空，最终可能导致 TXID 耗尽。

该database/postgresql/vacuum/oldest_transaction_age指标跟踪 PostgreSQL 实例中最旧的未提交事务的年龄，以自最旧事务开始的事务数衡量。

该指标没有单一的推荐值或阈值，但您可以使用它来进一步了解您的工作负载，并确定事务年龄是否可能导致真空积压。

例子

假设最早的事务年龄是 5000 万，这意味着真空将无法处理在最旧的事务之后开始的 5000 万事务。这个值本身既不好也不坏：5000 万个事务在一个大部分空闲的数据库上可能很多，或者在一个每秒运行 13k 转换的繁忙服务器上可能只是一个多小时的工作量。指标值确实表明存在长期运行的事务，但 5000 万个 TXID 的积压只是 20 亿最大值的一小部分，因此该事务不会造成 TXID 耗尽的高风险。您可以出于性能和效率的原因优化事务，但没有直接理由担心真空。

但是，如果最早的交易年龄是 15 亿呢？它不仅表明一个事务已经运行了很长时间，而且该事务还可以防止真空冻结 75% 的总 TXID 范围。这种情况需要仔细调查，因为事务对真空有重大影响，并可能将数据库推向 TXID 耗尽。

使用指标

您可以通过熟悉的 Cloud SQL 工具和功能与事务指标进行交互：

使用Metrics Explorer查看和绘制指标图表。

使用Cloud Monitoring API以编程方式访问指标。

使用仪表板进行方便的手动监控。

为关键指标的自动通知创建警报策略。

transaction_id_utilization本节提供使用该指标的示例。您可以对其他指标执行类似的步骤。

在 Metrics Explorer 中绘制事务 ID 利用率图表
按照这些说明transaction_id_utilization使用 Metrics Explorer 绘制图表。请注意，Metrics Explorer 将值显示为 0% 到 100% 之间的百分比，但基础指标是 0.0 到 1.0 范围内的数字。以编程方式访问指标时，您可以通过将原始值乘以 100% 来计算百分比。

要绘制事务 ID 利用率指标，请执行以下操作：

在 GCP Console 中，选择监控。您也可以使用此直接链接：转到监控

在左侧的导航菜单中，Metrics Explorer。

选择资源管理器选项卡和配置对话框。默认情况下，它们可能已预先选择。

在“资源和指标”部分下，展开选择指标下拉菜单。

选择“Cloud SQL 数据库”资源、“数据库”类别下的事务 ID 利用率指标。在搜索框中输入“交易”后，您将能够更轻松地找到指标：

您现在应该看到项目中所有实例的事务 ID 利用率指标：

或者，您可以添加过滤器以查看特定实例而不是所有实例的指标：

在“过滤器”部分下，单击添加过滤器。将出现一个过滤器表单。

• 在标签字段中，选择database_id。

• 在比较字段中，选择(= equals)。

• 在值字段中输入您的实例名称。

• 单击完成确认。

过滤后的图表现在应该只包含一行描述单个实例的事务 ID 利用率：

作为一项有用的练习，您可以查看多个实例的此指标，并尝试使用您对实例工作负载模式的了解来解释任何峰值或趋势。

创建有关事务 ID 利用率的警报策略

如前所述，如果事务 id 利用率达到 100%，数据库将不再允许写操作来保护自己免受 XID 回绕。因此，监控关键任务 PostgreSQL 数据库上的事务 ID 利用率指标非常重要。

您可以创建警报策略以在指标违反预配置阈值时接收自动通知。一个精心选择的门槛应该有两个目的：

1. 表明数据库正在经历异常的工作负载模式，即使 TXID 回绕并非迫在眉睫。
2. 如果数据库确实趋向于 XID 环绕，请给您足够的时间来纠正这种情况。

以下示例显示如何为阈值 70% 创建有关事务 ID 利用率的警报，这可能适用于大多数数据库。

要创建警报策略，请执行以下操作：

• 在 GCP Console 中，选择监控。您也可以使用此直接链接：转到监控

• 在左侧的导航菜单中，选择Alerting。

• 单击页面顶部附近的创建策略，这将带您进入创建警报策略对话框。

• 在选择指标下拉菜单中，找到事务 ID 利用率指标。

• 对于此演示，保留转换数据下的设置不变。您可以在此处了解有关数据转换的更多信息。

• 或者，您可以添加过滤器以在选定实例而不是所有实例上设置警报。

• 单击页面底部的下一步按钮，这将带您进入配置警报触发器对话框。

• 使用以下设置：

  • 条件类型：阈值。

  • 警报触发器：任何时间序列都违反.

  • 阈值位置：高于阈值。

  • 阈值：70（或您选择的其他值）。

（可选）在高级选项下为条件提供自定义名称，例如“交易 ID 利用率高”。

• 单击页面底部的下一步按钮，这将带您进入配置通知并完成警报对话框。

• 选择您的通知渠道。如果没有可供选择的通知渠道，请按照此处的步骤配置通知渠道。

• 给警报起一个易于识别的名称，例如“Transaction ID Utilization crossed 70%”。或者，提供有助于您对通知做出反应的附加说明或文档。

• 单击页面底部的创建策略按钮。

当警报触发时，您将收到类似以下的通知：

如果您的任何实例当前都没有遇到足以触发通知的 TXID 利用率，您可以暂时使用较低的阈值进行测试。

结论

在这篇博文中，我们演示了如何使用 Cloud SQL for PostgreSQL 探索和解释数据库实例上的事务 ID 利用率指标。我们还学习了如何为 Cloud SQL 实例上的事务 ID 利用率创建警报策略。