Vertica Health Watchdog 智能监控¶

Vertica Analytics Database 专为高性能分析而打造，擅长处理复杂且查询密集型的工作负载。其架构设计注重速度与可扩展性，使其成为数据驱动型企业的首选方案。

然而，与所有在高压环境下运行的系统一样，Vertica 在极端并发负载下也可能面临挑战。此时数据库可能进入性能下降状态，导致查询耗时增加、锁超时（lock timeouts）、ROS 推回（ROS pushbacks）、系统崩溃，甚至出现数据丢失的风险。

为主动应对这些问题，Vertica 推出了一项强大的新功能：Health Watchdog。

这一智能监控组件从24.4版本引入，默认开启，能够实时监测数据库的内部运行状态，确保集群始终保持健康与高响应性。它能够在系统出现压力或故障的早期阶段进行识别，并及时采取纠正措施，从而防止小问题演变为大规模故障。

接下来，我们将深入了解 Health Watchdog 的工作原理，以及它所关注的核心指标。

1. 核心功能¶

自动检测 当数据库因过高的并发负载或内部瓶颈进入“健康异常”状态时，系统可自动识别。
查询阻断 在健康异常期间，系统会阻止 DDL（数据定义语言）和 DML（数据操作语言）操作，以防止问题进一步恶化。
超时控制 被阻止的 DDL 和 DML 操作如果持续阻塞超过 5 分钟（该时长由参数 WatchDogTimeoutInterval 配置），将被自动超时终止。
自动恢复 一旦系统稳定、健康指标恢复正常，Watchdog 会自动解除阻断，并恢复那些阻塞时间未超过 5 分钟的操作（由参数 WatchDogTimeoutInterval 配置）。

2. 关键监控指标¶

2.1 Catalog 元数据版本维护¶

Catalog 截断版本（Truncation Catalog Version）是指在 Vertica 集群发生崩溃、关闭或休眠后，系统将回退到的目录版本。 该版本在集群所有节点间保持一致，具体取决于某个分片中所有订阅者的最大同步版本中的最小值。

current_catalog_version 表示当前集群正在使用的目录版本。

截断版本滞后用于监控 current_catalog_version 与 truncation_catalog_version 之间的差异。如果该差值超过了预设阈值（由参数 TruncationVersionLag 配置），Health Watchdog 会将该模块标记为“健康异常”。

出现该状况时：

所有非超级用户的客户端请求将被阻止，以避免系统状态进一步不一致；
系统将保持在该异常状态，直到完成一次成功的目录同步并更新截断版本；
同步完成后，该模块会被重新标记为“健康”，所有事务操作将恢复执行。

2.2 GCL-X 队列维护¶

在 Health Watchdog 中，有一个关键模块专门用于监控 GCLX 队列——这是执行 DDL、UPDATE 和 DELETE 等操作时依赖的重要组件。这些操作需要对目录锁（catalog locks）进行排他访问，而在高并发负载下，请求很容易迅速堆积。

当数据库同时收到大量 DDL 和 DML 操作时，许多查询会被迫排队等待获取锁，从而导致 GCLX 队列变长，引发性能瓶颈与延迟上升。

为防止这种情况发生，Health Watchdog 会实时监控 GCLX 队列的大小。每当有 GCLX 请求进入或完成，系统都会更新队列长度。如果当前队列长度超过了预设阈值（由参数 GCLXBlockParameter 配置），该模块就会被标记为“健康异常”。

一旦进入异常状态，系统会主动阻止新的事务进入锁等待队列，从而在问题进一步加重之前，缓解 GCLX 子系统的压力。

当队列长度降至 GCLXBlockParameter 阈值的 10% 以下时，系统会解除所有被阻止的事务，并将模块重新标记为“健康”。

这个机制可以有效防止目录锁资源被耗尽，保持系统的整体稳定性与响应能力。

2.3 Mergeout 队列维护¶

许多 Vertica 用户都对 Tuple Mover（简称 TM）有所了解——这是一个后台组件，负责高效地合并 ROS（只读优化存储）容器，并清理已删除的数据。

在高负载环境下，TM 可能会不堪重负。当 mergeout 请求过多而可用的 TM 线程无法及时处理时，系统性能将大幅下降。

为防止系统进一步受压，Vertica 的 Health Watchdog 会介入监控。它通过配置参数 MergeoutBlockParameter 限定 mergeout 队列允许的最大长度。如果队列大小超过该阈值，Watchdog 会将该模块标记为“健康异常”，并阻止新的 DML 事务进入系统。

其工作机制如下：

每当有 mergeout 请求进入或完成时，Watchdog 会实时更新队列状态；
如果请求排入队列时的长度超过 MergeoutBlockParameter，该模块即被标记为异常；
所有新的 DML 事务将被阻止，以避免加重系统负担；
在当前队列长度下降至最大队列限制的 25% 以下时，该模块将被重新标记为“健康”，所有被阻止的事务也将被恢复执行。

这一主动防护机制有助于保持系统稳定，防止性能问题进一步升级或失控。

2.4 资源池内存维护¶

Vertica 通过两个主要的内存池来管理系统内存资源：通用内存池（general pool）和全局内存池（global pool）。系统通过持续监控这两个内存池的可用性，以确保整体稳定性和性能表现。

general资源池可视为系统的主要内存来源，其可用性由参数 GeneralPoolMinFreeMemoryRatio 配置（默认值为 0.25），确保至少保留一定比例的空闲内存，以避免出现 OOM（内存溢出）风险。只要general资源池中剩余内存充足，DML 操作即可正常执行。

当general资源池低于设定阈值时：

Health Watchdog 会进一步评估全局内存池是否还有足够容量支持当前的 DML 操作；
如果该操作请求的内存将导致全局池的使用率超过 GlobalPoolMaxUtilizationRatio（默认值为 0.9），事务将被阻止执行；
当全局池的内存使用率下降到 GlobalPoolMaxUtilizationRatio 的 50% 以下时，模块会被重新标记为“健康”，事务阻止也会解除。

因此，尽管 Health Watchdog 主要监控的是全局内存池的使用情况，但它在做出决策时也间接参考了通用内存池的状态，以综合判断是否需要阻断事务，从而实现对系统资源的动态保护。

3. 相关查询及系统表¶

3.1 相关参数¶

select parameter_name,current_value,default_value,current_level,description from configuration_parameters where parameter_name in ('TruncationVersionLag','WatchdogTimeoutInterval','GCLXBlockParameter','MergeoutBlockParameter','GeneralPoolMinFreeMemoryRatio');
     parameter_name      | current_value | default_value | current_level |                                                                       description
-------------------------+---------------+---------------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------
 GCLXBlockParameter      | 100           | 100           | DEFAULT       | If the current GCLX queue size is greater than set value, we block DDL/DML operations. (0 disables the check)
 TruncationVersionLag    | 500           | 500           | DEFAULT       | The difference between commit version and current truncation version. If difference exceeds set value, we perform catalog sync. (0 disables the service)
 WatchdogTimeoutInterval | 5 minutes     | 5 minutes     | DEFAULT       | Timeout interval for blocking DML/DDLs using Health Watchdog. (0 sets it to indefinite wait.)
 MergeoutBlockParameter  | 100           | 100           | DEFAULT       | If the current mergeout queue size exceeds set value, we block DDL/DML operations. (0 disables the check)
(4 rows)

select get_config_parameter('GeneralPoolMinFreeMemoryRatio');
 get_config_parameter
----------------------
 0.250000
(1 row)

select get_config_parameter('GlobalPoolMaxUtilizationRatio');
 get_config_parameter
----------------------
 0.900000
(1 row)

3.2 查询¶

1. 获取健康状况¶

```sql
=> select check_cluster_health();
                                     check_cluster_health
-----------------------------------------------------------------------------------------------------------------------
 Cluster State: Not Healthy.
Reason: GCLX QUEUE BLOAT
Description: GCLX queue is too large.
Number of blocked transactions: 2
Hint: Try to resubmit request later or Tune the value of the database parameter GCLXBlockParameter to proceed.

(1 row)

-- On resolving
verticadb21249=> select check_cluster_health();
   check_cluster_health
--------------------------
 Cluster State: Healthy.

(1 row)

2. 查询被阻断的任务¶

verticadb21249=> select * from health_watchdog_blocked_transactions;
 node_name |       block_start_time        |                          transaction_description                          |    block_type
-----------+-------------------+-------------------------------+---------------------------------------------------------------------------+------------------
 initiator | 2024-06-17 22:24:08.636447-04 | Txn: a00000000000de 'create table table_t2(b int, c varchar(10), a int);' | GCLX QUEUE BLOAT
 initiator | 2024-06-17 22:28:43.340537-04 | Txn: a00000000000e9 'create table table_t3(b int, c varchar(10), a int);' | GCLX QUEUE BLOAT
(2 rows)

扩展阅读¶

Vertica 监控最佳实践 — 监控 SQL 大全
Vertica 集成 Grafana 连接指南 — Grafana 可视化监控
Vertica 资源池配置的最佳实践 — 资源池调优