这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

监控 Vertica

您可以通过各种日志文件和系统表来监控 Vertica 数据库的活动和运行状况。Vertica 提供了各种配置参数来控制监控选项。还可以使用管理控制台来观察数据库活动。

1 - 监控日志文件

当数据库正在运行时

当 Vertica 数据库正在运行时， 群集中的每个 节点都将消息写入名为 vertica.log 的文件中。例如， Tuple Mover 和事务管理器以特定间隔将 INFO 消息写入 vertica.log，即使没有任何合并活动也是如此。

您配置 vertica.log 文件的位置。默认情况下，日志文件位于：

catalog-path/database-name/node-name_catalog/vertica.log

  • catalog-path 是 NODES 系统表中显示的路径去掉末尾的 Catalog 目录。

  • database-name 是您的数据库的名称。

  • node-name 是在 NODES 系统表中显示的节点的名称。

要实时监控正在运行的数据库中的某个节点：

  1. 在群集中的任意节点上登录到数据库管理员帐户。

  2. 在终端窗口中，输入：

    $ tail -f catalog-path/database-name/node-name_catalog/vertica.log

当数据库/节点正在启动时

系统启动期间，在 Vertica 日志已初始化为写入消息之前，群集中的每个节点都将消息写入名为 dbLog 的文件中。此日志可用于诊断数据库无法启动、进而无法将消息写入 vertica.log 的情况。dblog 位于以下路径中，使用的是上文所述的 catalog-path 和 database-name：

catalog-path/database-name/dbLog

另请参阅

2 - 轮转日志文件

大部分 Linux 分发版都包含 logrotate 实用程序。使用此实用程序可简化日志文件管理。通过设置 logrotate 配置文件，您可以使用此实用程序自动完成以下一项或多项任务：

  • 压缩和轮转日志文件

  • 自动删除日志文件

  • 通过电子邮件将日志文件发送给指定的收件人

可将 logrotate 配置为定期或在日志文件达到特定大小时完成这些任务。

如果安装 Vertica 时存在 logrotate，则 Vertica 会自动将此实用程序设置为查找配置文件。因此，logrotate 会在每个节点的 /opt/vertica/config/logrotate 目录中搜索配置文件。

当您创建数据库时，Vertica 会在群集中的每个节点上创建特定于数据库的 logrotate 配置，以供 logrotate 实用程序使用。之后，它会为每个单独的数据库创建一个路径为 /opt/vertica/config/logrotate/ 的文件。

有关其他设置的信息，请使用 man logrotate 命令。

通过 dbadmin logrotate cron 作业执行 Python 脚本

在 Vertica 安装期间，安装程序会为 dbadmin 用户配置 cron 作业。此 cron 作业被配置为执行运行 logrotate 实用程序的 Python 脚本。您可以通过查看 dbadmin.cron 文件（位于 /opt/vertica/config 目录中）查看此 cron 作业的详细信息。

如果要自定义 cron 作业，以便为 Vertica 数据库配置 logrotate，您必须在 dbadmin 用户下创建 cron 作业。

使用管理工具 logrotate 实用程序

可借助 admintools logrotate 选项为数据库配置 logrotate 脚本并在整个群集上分发这些脚本。使用 logrotate 选项可以指定：

  • 轮转日志的频率

  • 可轮转的日志大小

  • 日志的保留时长

例如：

以下示例显示如何将日志设置为每周轮转一次并保留三个月（12 个日志）。

$ admintools -t logrotate -d <dbname> -r weekly -k 12

有关详细使用信息，请参阅编写管理工具脚本。

为 MC 配置 logrotate

管理控制台日志文件是：

/opt/vconsole/log/mc/mconsole.log

要为 MC 配置 logrotate，请配置以下文件：

/opt/vconsole/temp/webapp/WEB-INF/classes/log4j.xml

编辑 log4j.xml 文件并按如下方式设置相应的参数：

  1. 限制日志的大小：

    <param name="MaxFileSize" value="1MB"/>

  2. 限制日志的文件备份数量：

    <param name="MaxBackupIndex" value="1"/>

  3. 以 root 用户身份重新启动 MC：

    # etc/init.d/vertica-consoled restart

手动轮转日志

要实施自定义日志轮转过程，请执行以下步骤：

  1. 对现有的 vertica.log 文件进行重命名或存档。例如：

    $ mv vertica.log vertica.log.1

  2. 使用以下任一方法向 Vertica 进程发送 USR1 信号：

    $ killall -USR1 vertica

    或

    $ ps -ef | grep -i vertica
$ kill -USR1 process-id

另请参阅

3 - 监控进程状态 (ps)

可以使用 ps 监控数据库和在群集中的每个节点上运行的 Spread 进程。例如：

$ ps aux | grep /opt/vertica/bin/vertica
$ ps aux | grep /opt/vertica/spread/sbin/spread

对于常见配置，您应在每个节点上看到一个 Vertica 进程和一个 Spread 进程。要监控管理工具 (Administration Tools) 和连接器进程：

$ ps aux | grep vertica

连接进程会有许多，但管理工具 (Administration Tools) 进程只有一个。

4 - 监控 Linux 资源使用情况

您应对群集中任何节点或所有节点上的系统资源使用情况进行监控。可以使用系统活动报告 (SAR) 监控资源使用情况。

  1. 在任意节点上登录到数据库管理员帐户。

  2. 运行 top 实用程序

    $ top

    如果 top 中的 CPU 百分比很高，则表示 Vertica 为计算密集型。例如：

    top - 11:44:28 up 53 days, 23:47,  9 users,  load average: 0.91, 0.97, 0.81
Tasks: 123 total,   1 running, 122 sleeping,   0 stopped,   0 zombie
Cpu(s):  26.9%us,  1.3%sy,  0.0%ni, 71.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4053136 total,  3882020k used,  171116 free,   407688 buffers
Swap:  4192956 total,   176k used,  4192780 free,  1526436 cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13703 dbadmin    1   0 1374m 678m  55m S 99.9 17.1   6:21.70 vertica
 2606 root      16   0 32152  11m 2508 S  1.0  0.3   0:16.97 X
    1 root      16   0  4748  552  456 S  0.0  0.0   0:01.51 init
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:04.92 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:11.75 ksoftirqd/0
...

    下面是一些可能造成高 CPU 使用率的原因：

    • 即使未连接至数据库， Tuple Mover 也会自动运行，因而消耗了 CPU 时间。

    • swappiness 内核参数不能设置为 0。从 Linux 命令行执行以下命令，查看以下参数的值：

      $ cat /proc/sys/vm/swappiness

      如果此参数的值不为 0，请按照检查 swappiness中的步骤进行更改。

    • 一些信息源：

  3. 运行 iostat 实用程序。如果在 iostat 中的块读取速率很高的情况下，top 中出现高空闲时间，则表示 Vertica 为磁盘密集型。例如：

    $ /usr/bin/iostat
Linux 2.6.18-164.el5 (qa01)     02/05/2011
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.77    2.32    0.76    0.68    0.00   95.47
Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
hda               0.37         3.40        10.37    2117723    6464640
sda               0.46         1.94        18.96    1208130   11816472
sdb               0.26         1.79        15.69    1114792    9781840
sdc               0.24         1.80        16.06    1119304   10010328
sdd               0.22         1.79        15.52    1117472    9676200
md0               8.37         7.31        66.23    4554834   41284840

5 - 监控磁盘空间使用情况

可以使用这些系统表来监控群集中的磁盘空间使用情况。

6 - 监控弹性群集重新平衡

Vertica 包括一些系统表，可用于监控弹性群集的重新平衡状态并获得节点上的弹性群集状态的常规信息。

  • REBALANCE_TABLE_STATUS 提供有关重新平衡的常规信息。该表显示了每个表的已分隔数据量、当前正在分隔的数据量以及要分隔的数据量。该表还显示了已传输的数据量、当前正在传输的数据量以及要传输的剩余数据量（或者是估计值，如果未分隔存储空间）。

  • REBALANCE_PROJECTION_STATUS 可用于获取与正在重新平衡的特定投影有关的更多详细信息。它提供的信息类型与上述信息类型相同，但这些信息与投影有关而非与表有关。

在每个表中，SEPARATED_PERCENT 和 TRANSFERRED_PERCENT 列可用于确定总体进度。

有关重新平衡的历史信息

有关已完成工作的历史信息会保留下来，因此使用表列 IS_LATEST 查询可将输出限制为仅包含最近或当前的重新平衡活动。历史数据可能包括与已删除的投影或表有关的信息。如果表或投影已删除并且有关锚表的信息不可用，则将表 ID 显示为 NULL，将表名显示为 <unknown>。与已删除的表有关的信息仍然很有用，例如，可用于在执行任务期间提供理由。

7 - 监控事件

为了帮助您监控数据库系统，Vertica 捕获并记录如果根本原因未得到解决便会影响数据库性能和功能的重要事件。此部分介绍事件的记录位置、Vertica 记录的事件类型、如何对这些事件作出响应、Vertica 为这些事件提供的信息以及如何配置事件监控。

7.1 - 事件日志记录机制

Vertica 将事件发布至以下机制：

7.2 - 事件代码

下表列出了 Vertica 记录到事件系统表的事件代码。

7.3 - 事件数据

为了帮助您解释并解决触发某一事件的问题，每个事件都提供各种各样的数据，具体视所用的事件日志记录机制而定。

下表介绍事件数据并指出其使用位置。

7.4 - 配置事件报告

系统为 vertica.log 自动配置事件报告，并将当前事件自动发布至 ACTIVE_EVENTS 系统表。您也可以将 Vertica 配置为将事件发布至 syslog 和 SNMP。

7.4.1 - 为 syslog 配置报告

Syslog 是一个网络日志记录实用程序，用于发出、存储和处理日志消息。这是一种将异构数据放入单个数据存储库的有用方法。

要将事件记录到 syslog 中，请为希望记录的每个单独事件启用事件报告。默认情况下，消息会记录到 /var/log/messages 中。

配置报告给 syslog 的事件包括以下步骤：

  1. 允许 Vertica 为 syslog 捕获事件。

  2. 定义 Vertica 为 syslog 捕获哪些事件。

    Vertica 强烈建议您捕获“陈旧检查点 (Stale Checkpoint)”事件。

  3. 定义要使用的 syslog 程序模块。

允许 Vertica 为 syslog 捕获事件

要为 syslog 启用事件捕获功能，请发出以下 SQL 命令：

=> ALTER DATABASE DEFAULT SET SyslogEnabled = 1;

要为 syslog 禁用事件捕获功能，请发出以下 SQL 命令：

=> ALTER DATABASE DEFAULT SET SyslogEnabled = 0;

定义要为 syslog 捕获的事件

要定义用来生成 syslog 条目的事件，请发出以下 SQL 命令，命令下方的列表中所述的一个事件：

=> ALTER DATABASE DEFAULT SET SyslogEvents = 'events-list';

其中 events-list 是以逗号分隔的事件列表，其中包含下面的一项或多项：

  • 磁盘空间不足

  • 只读文件系统

  • K-Safety 丢失

  • 当前容错能力处于临界水平

  • ROS 容器过多

  • 节点状态更改

  • 恢复故障

  • 恢复错误

  • 恢复锁定错误

  • 恢复投影检索错误

  • 刷新错误

  • 刷新锁定错误

  • Tuple Mover 错误

  • 计时器服务任务错误

  • 陈旧检查点

以下示例会为低磁盘空间和恢复故障生成一个 syslog 条目：

=> ALTER DATABASE DEFAULT SET SyslogEvents = 'Low Disk Space, Recovery Failure';

定义要用于报告的 SyslogFacility

Syslog 机制可以对日志记录消息进行多种不同的常规分类，这称为程序模块。通常，所有与身份验证相关的消息都使用 auth （或 authpriv）程序模块记录。这些消息预期是安全的并且未经授权的人员无法查看。普通的操作消息使用 daemon 程序模块记录，该程序模块可接收并视情况存储消息。

SyslogFacility 指令可将所有日志记录消息定向到默认设置以外的其他不同程序模块。使用此指令时，所有日志记录操作都将使用指定的程序模块（身份验证（安全）等等）来完成。

要定义 Vertica 使用哪个 SyslogFacility，请发出以下 SQL 命令：

=> ALTER DATABASE DEFAULT SET SyslogFacility = 'Facility_Name';

其中程序模块级别实参 <Facility_Name> 为以下项目之一：

  • auth

  • authpriv（仅限 Linux）

  • cron

  • uucp（UUCP 子系统）

  • daemon

  • ftp（仅限 Linux）

  • lpr（行式打印机子系统）

  • mail（邮件系统）

  • news（网络新闻子系统）

  • user（默认系统）

  • Local0（本地使用 0）

  • local1（本地使用 1）

  • local2（本地使用 2）

  • local3（本地使用 3）

  • local4（本地使用 4）

  • local5（本地使用 5）

  • local6（本地使用 6）

  • local7（本地使用 7）

捕获其他事件类型

要捕获除上面列出的事件之外的事件，请创建一个 syslog 通知程序并允许它使用 SET_DATA_COLLECTOR_NOTIFY_POLICY 捕获所需的事件。

此通知程序类型监视的事件不会记录到 MONITORING_EVENTS 或 vertica.log。

以下示例创建了一个通知程序，当 数据收集器 (DC) 组件 LoginFailures 更新时，它会向 syslog 写入一条消息：

  1. 为当前数据库启用 syslog 通知程序：

    => ALTER DATABASE DEFAULT SET SyslogEnabled = 1;

  2. 创建并启用系统日志通知程序 v_syslog_notifier：

    => CREATE NOTIFIER v_syslog_notifier ACTION 'syslog'
    ENABLE
    MAXMEMORYSIZE '10M'
    IDENTIFIED BY 'f8b0278a-3282-4e1a-9c86-e0f3f042a971'
    PARAMETERS 'eventSeverity = 5';

  3. 配置 syslog 通知程序 v_syslog_notifier 以更新具有 SET_DATA_COLLECTOR_NOTIFY_POLICY 的 LoginFailures DC 组件：

    => SELECT SET_DATA_COLLECTOR_NOTIFY_POLICY('LoginFailures','v_syslog_notifier', 'Login failed!', true);

    当用户未能以用户 Bob 身份进行身份验证时，此通知程序将以下消息写入 syslog（默认位置：/var/log/messages）：Apr 25 16:04:58 vertica_host_01 vertica： Event Posted: Event Code:21 Event Id:0 Event Severity: Notice [5] PostedTimestamp: 2022-04-25 16:04:58.083063 ExpirationTimestamp: 2022-04-25 16:04:58.083063 EventCodeDescription: Notifier ProblemDescription: (Login failed!) { "_db":"VMart", "_schema":"v_internal", "_table":"dc_login_failures", "_uuid":"f8b0278a-3282-4e1a-9c86-e0f3f042a971", "authentication_method":"Reject", "client_authentication_name":"default: Reject", "client_hostname":"::1", "client_label":"", "client_os_user_name":"dbadmin", "client_pid":523418, "client_version":"", "database_name":"dbadmin", "effective_protocol":"3.8", "node_name":"v_vmart_node0001", "reason":"REJECT", "requested_protocol":"3.8", "ssl_client_fingerprint":"", "ssl_client_subject":"", "time":"2022-04-25 16:04:58.082568-05", "user_name":"Bob" }#012 DatabaseName: VMart Hostname: vertica_host_01

另请参阅

事件报告示例

7.4.2 - 为 SNMP 配置报告

为 SNMP 配置事件报告包括以下步骤：

  1. 将 Vertica 配置为启用 SNMP 事件陷阱，如下所述。

  2. 将 Vertica 管理信息库 (MIB) 文件导入到 SNMP 监控设备中。

    利用 Vertica MIB 文件，SNMP 陷阱接收器可以了解其从 Vertica 接收的陷阱，进而使您能够配置其在接收陷阱时采取的操作。

    Vertica 支持 SNMP V1 陷阱协议，该协议位于 /opt/vertica/sbin/VERTICA-MIB 中。有关导入 MIB 文件的详细信息，请参阅 SNMP 监控设备文档。

  3. 配置 SNMP 陷阱接收器处理来自 Vertica 的陷阱。

    不同供应商的 SNMP 陷阱接收器配置显著不同。因而，此处介绍的有关配置 SNMP 陷阱接收器处理来自 Vertica 的陷阱的指南为通用指南。

    Vertica 陷阱是包含若干信息标识字段的单一通用陷阱。这些字段相当于监控事件中所述的事件数据。但是，字段名称所使用的格式略有不同。在 SNMP 下，字段名称不包含空格。此外，字段名称会预先加上“vert”。例如，事件严重级别变为 vertEventSeverity。

    配置陷阱接收器时，请确保使用用于在 Vertica 中配置事件陷阱的相同主机名、端口和社区字符串。

    网络管理提供程序示例：

7.4.3 - 为 SNMP 配置事件陷阱

将 Vertica 配置为捕获 SNMP 事件时，默认会捕获以下事件：

  • 磁盘空间不足

  • 只读文件系统

  • K-Safety 丢失

  • 当前容错能力处于临界水平

  • ROS 容器过多

  • 节点状态更改

  • 恢复故障

  • 陈旧检查点

  • CRC 不匹配

要将 Vertica 配置为捕获 SNMP 事件

  1. 启用 Vertica 以捕获 SNMP 事件。

  2. 定义 Vertica 发送陷阱的位置。

  3. （可选）重新定义 Vertica 捕获哪些 SNMP 事件。

要为 SNMP 启用事件陷阱

使用以下 SQL 命令：

=> ALTER DATABASE DEFAULT SET SnmpTrapsEnabled = 1;

要定义 Vertica 发送陷阱的位置

使用以下 SQL 命令，其中 Host_name 和 port 标识 SNMP 所在的计算机，CommunityString 相当于密码，用于控制 Vertica 对服务器的访问：

=> ALTER DATABASE DEFAULT SET SnmpTrapDestinationsList = 'host_name port CommunityString';

例如：

=> ALTER DATABASE DEFAULT SET SnmpTrapDestinationsList = 'localhost 162 public';

也可以指定多个目标，方法是指定以逗号分隔的目标列表：

=> ALTER DATABASE DEFAULT SET SnmpTrapDestinationsList = 'host_name1 port1 CommunityString1, hostname2 port2 CommunityString2';

要定义 Vertica 捕获的事件

使用以下 SQL 命令，其中 Event_Name 是命令下方列表中的一个事件：

=> ALTER DATABASE DEFAULT SET SnmpTrapEvents = 'Event_Name1, Even_Name2';

  • 磁盘空间不足

  • 只读文件系统

  • K-Safety 丢失

  • 当前容错能力处于临界水平

  • ROS 容器过多

  • 节点状态更改

  • 恢复故障

  • 恢复错误

  • 恢复锁定错误

  • 恢复投影检索错误

  • 刷新错误

  • Tuple Mover 错误

  • 陈旧检查点

  • CRC 不匹配

以下示例指定两个事件名称：

=> ALTER DATABASE DEFAULT SET SnmpTrapEvents = 'Low Disk Space, Recovery Failure';

7.4.4 - 验证 SNMP 配置

要创建一组检查 SNMP 配置的测试事件：

  1. 将 SNMP 陷阱处理程序设置为捕获 Vertica 事件。

  2. 使用以下命令测试您的设置：

    SELECT SNMP_TRAP_TEST();
    SNMP_TRAP_TEST
--------------------------
 Completed SNMP Trap Test
(1 row)

7.5 - 事件报告示例

Vertica.log

以下示例展示了在 vertica.log 内发布并清除的 Too Many ROS Containers 事件：

08/14/15 15:07:59 thr:nameless:0x45a08940 [INFO] Event Posted: Event Code:4 Event Id:0 Event Severity: Warning [4] PostedTimestamp:
2015-08-14 15:07:59.253729 ExpirationTimestamp: 2015-08-14 15:08:29.253729
EventCodeDescription: Too Many ROS Containers ProblemDescription:
Too many ROS containers exist on this node. DatabaseName: TESTDB
Hostname: fc6-1.example.com
08/14/15 15:08:54 thr:Ageout Events:0x2aaab0015e70 [INFO] Event Cleared:
Event Code:4 Event Id:0 Event Severity: Warning [4] PostedTimestamp:
2015-08-14 15:07:59.253729 ExpirationTimestamp: 2015-08-14 15:08:53.012669
EventCodeDescription: Too Many ROS Containers ProblemDescription:
Too many ROS containers exist on this node. DatabaseName: TESTDB
Hostname: fc6-1.example.com

SNMP

以下示例展示了发布到 SNMP 的 Too Many ROS Containers 事件：

Version: 1, type: TRAPREQUESTEnterprise OID: .1.3.6.1.4.1.31207.2.0.1
Trap agent: 72.0.0.0
Generic trap: ENTERPRISESPECIFIC (6)
Specific trap: 0
.1.3.6.1.4.1.31207.1.1 ---> 4
.1.3.6.1.4.1.31207.1.2 ---> 0
.1.3.6.1.4.1.31207.1.3 ---> 2008-08-14 11:30:26.121292
.1.3.6.1.4.1.31207.1.4 ---> 4
.1.3.6.1.4.1.31207.1.5 ---> 1
.1.3.6.1.4.1.31207.1.6 ---> site01
.1.3.6.1.4.1.31207.1.7 ---> suse10-1
.1.3.6.1.4.1.31207.1.8 ---> Too many ROS containers exist on this node.
.1.3.6.1.4.1.31207.1.9 ---> QATESTDB
.1.3.6.1.4.1.31207.1.10 ---> Too Many ROS Containers

Syslog

以下示例展示了在系统日志内发布并清除的 Too Many ROS Containers 事件：

Aug 14 15:07:59 fc6-1 vertica: Event Posted: Event Code:4 Event Id:0 Event Severity: Warning [4] PostedTimestamp: 2015-08-14 15:07:59.253729 ExpirationTimestamp:
2015-08-14 15:08:29.253729 EventCodeDescription: Too Many ROS Containers ProblemDescription:
Too many ROS containers exist on this node. DatabaseName: TESTDB Hostname: fc6-1.example.com
Aug 14 15:08:54 fc6-1 vertica: Event Cleared: Event Code:4 Event Id:0 Event Severity:
Warning [4] PostedTimestamp: 2015-08-14 15:07:59.253729 ExpirationTimestamp:
2015-08-14 15:08:53.012669 EventCodeDescription: Too Many ROS Containers ProblemDescription:
Too many ROS containers exist on this node. DatabaseName: TESTDB Hostname: fc6-1.example.com

8 - 使用系统表

Vertica 系统表提供有关系统资源、后台进程、工作负载和性能的信息，例如加载流、查询配置文件和 Tuple Mover 操作。Vertica 自动收集并刷新此信息。

可使用表达式、谓词、聚合、分析、子查询和联接来查询系统表。也可以将系统表查询结果保存到用户表中，以供将来进行分析。例如，以下查询将创建一个名为 mynode 的表，并从 NODES 系统表中选择三个与节点相关的列：

=> CREATE TABLE mynode AS SELECT node_name, node_state, node_address FROM nodes;
CREATE TABLE
=> SELECT * FROM mynode;
    node_name     | node_state |  node_address
------------------+------------+----------------
 v_vmart_node0001 | UP         | 192.168.223.11
(1 row)

系统表位置

系统表可分为以下两个架构：

这些架构驻留在默认搜索路径中。除非您更改搜索路径以排除 V_MONITOR 和/或 V_CATALOG，否则查询可以指定不包含表架构的系统表名。

您可以在 SYSTEM_TABLES 表中查询所有 Vertica 系统表及其架构。例如：

SELECT * FROM system_tables ORDER BY table_schema, table_name;

系统表类别

Vertica 系统表可分为以下区域：

  • 系统信息

  • 系统资源

  • 后台进程

  • 工作负载和性能

Vertica 会保留一些内存以帮助监控繁忙的系统。使用简单的系统表查询可以更轻松地排除问题。另请参阅 SYSQUERY。

权限

您可以授予和撤销对系统表的权限，但有以下限制：

  • 您不能向 SYSMONITOR 或 PSEUDOSUPERUSER 角色授予对系统表的权限。

  • 您不能授予对系统架构的权限。

区分大小写的系统表数据

一些系统表数据可能以大小写混合的形式存储。例如，Vertica 会按照您在 CREATE 语句中所指定的那样来存储混合大小写的标识符名称，即使在查询中引用它们时忽略大小写。当这些对象名称作为数据出现在系统表中时，如果使用等于 (=) 运算符查询它们将会遇到错误，因为大小写必须与存储的标识符完全匹配。特别是，系统表 TABLES 中的列 TABLE_SCHEMA 和 TABLE_NAME 中的数据区分大小写。

如果您不知道标识符的存储方式，可使用不区分大小写的运算符 ILIKE。例如，给定以下架构：

=> CREATE SCHEMA SS;
=> CREATE TABLE SS.TT (c1 int);
=> CREATE PROJECTION SS.TTP1 AS SELECT * FROM ss.tt UNSEGMENTED ALL NODES;
=> INSERT INTO ss.tt VALUES (1);

使用 = 运算符的查询返回 0 行：

=> SELECT table_schema, table_name FROM v_catalog.tables WHERE table_schema ='ss';
table_schema | table_name
--------------+------------
(0 rows)

使用不区分大小写的 ILIKE 的查询返回预期结果：

=> SELECT table_schema, table_name FROM v_catalog.tables WHERE table_schema ILIKE 'ss';
table_schema | table_name
--------------+------------
 SS           | TT
(1 row)

示例

以下示例将展示在查询中使用系统表的简单方法。


=> SELECT current_epoch, designed_fault_tolerance, current_fault_tolerance FROM SYSTEM;
 current_epoch | designed_fault_tolerance | current_fault_tolerance
---------------+--------------------------+-------------------------
           492 |                        1 |                       1
(1 row)

=> SELECT node_name, total_user_session_count, executed_query_count FROM query_metrics;
    node_name     | total_user_session_count | executed_query_count
------------------+--------------------------+----------------------
 v_vmart_node0001 |                      115 |                  353
 v_vmart_node0002 |                      114 |                   35
 v_vmart_node0003 |                      116 |                   34
(3 rows)

=> SELECT DISTINCT(schema_name), schema_owner FROM schemata;
 schema_name  | schema_owner
--------------+--------------
 v_catalog    | dbadmin
 v_txtindex   | dbadmin
 v_func       | dbadmin
 TOPSCHEMA    | dbadmin
 online_sales | dbadmin
 v_internal   | dbadmin
 v_monitor    | dbadmin
 structs      | dbadmin
 public       | dbadmin
 store        | dbadmin
(10 rows)

9 - 数据收集器实用程序

数据收集器收集并保留重要系统活动的历史记录，并记录基本性能和资源利用率计数器。

数据收集器以最小的开销扩展系统表功能，它执行以下任务：

  • 提供一个用于记录事件的框架

  • 将信息传播到系统表。

您可以通过查询数据收集器信息来获取系统表的过去状态并提取聚合信息。它还可以帮助您：

  • 查看用户已采取哪些操作。

  • 找出性能瓶颈。

  • 确定 Vertica 配置的潜在改进领域。

数据收集器与工作负载分析器搭配使用，后者是一款工具，可智能监控 SQL 查询和工作负载的性能，并通过观察实际工作负载的历史记录来建议优化操作。

配置和访问数据收集器信息

数据收集器根据可配置的保留策略保留它收集的数据。数据收集器在默认情况下处于启用状态；您可以禁用数据收集器，方法是使用 ALTER DATABASE 和 ALTER NODE 分别在数据库级别和节点级别将配置参数 EnableDataCollector 设置为 0。

您可以通过系统表 DATA_COLLECTOR 访问有关所有组件的收集数据的元数据。此表包含有关该组件的当前收集策略以及在内存和磁盘中保留了多少数据的信息。

收集的数据记录在磁盘 Vertica /catalog 路径下的 DataCollector 目录中。您可以从特定于组件的数据收集器表中查询所记录的数据。您还可以使用 Vertica 元函数管理所记录的数据；有关详细信息，请参阅管理数据收集日志。

9.1 - 配置数据保留策略

数据收集器为其监控的每个 Vertica 组件（例如 TupleMoverEvents 或 DepotEvictions）维护保留策略。您可以通过查询 DATA_COLLECTOR 系统表来识别受监控的组件。例如，以下查询返回分区活动组件：

=> SELECT DISTINCT component FROM data_collector WHERE component ILIKE '%partition%';
      component
----------------------
 HiveCustomPartitions
 CopyPartitions
 MovePartitions
 SwapPartitions
(4 rows)

每个组件都有自己的保留策略，保留策略由几个属性组成：

  • MEMORY_BUFFER_SIZE_KB 指定数据收集器在将收集的数据移至磁盘之前，在内存中缓冲的最大数据量（以千字节为单位）。

  • DISK_SIZE_KB 指定为该组件的数据收集器表分配的最大磁盘空间（以千字节为单位）。

  • INTERVAL_TIME 是一种 INTERVAL 数据类型，用于指定给定组件的数据在该组件的数据收集器表中保留多长时间。

Vertica 为所有属性设置默认值，您可以使用元函数 SET_DATA_COLLECTOR_POLICY 和 SET_DATA_COLLECTOR_TIME_POLICY 更改默认值。

您可以通过调用 GET_DATA_COLLECTOR_POLICY 来查看保留策略设置。例如，以下语句返回 TupleMoverEvents 组件的保留策略：

=> SELECT get_data_collector_policy('TupleMoverEvents');
                          get_data_collector_policy
-----------------------------------------------------------------------------
 1000KB kept in memory, 15000KB kept on disk. Time based retention disabled.
(1 row)

设置保留内存和磁盘存储

通过结合使用保留策略属性 MEMORY_BUFFER_SIZE_KB 和 DISK_SIZE_KB 来确定在任何给定时间可用的收集数据量。这两个属性具有以下依赖关系：如果 MEMORY_BUFFER_SIZE_KB 设置为 0，则数据收集器不会在内存或磁盘上保留此组件的任何数据；如果 DISK_SIZE_KB 设置为 0，则数据收集器仅保留它可以缓冲的最大组件数据量（由 MEMORY_BUFFER_SIZE_KB 设置）。

例如，以下语句将 ResourceAcquisitions 组件的内存和磁盘设置从 1,000 KB 内存和 10,000 KB 磁盘空间的当前设置分别更改为 1500 KB 和 25000 KB：

=> SELECT set_data_collector_policy('ResourceAcquisitions', '1500', '25000');
 set_data_collector_policy
---------------------------
 SET
(1 row)

在以下情况下，您应该考虑将 MEMORY_BUFFER_SIZE_KB 设置为较高的值：

  • 数据收集量异常高。如果 MEMORY_BUFFER_SIZE_KB 设置得太低，数据收集器将缓冲的数据刷新到磁盘的速度可能不够快，无法跟上活动级别，这可能导致内存中的数据丢失。

  • 数据收集器记录非常大 — 例如，记录中包含非常长的查询字符串。数据收集器使用双重缓冲，因此它在内存中不能保留比 MEMORY_BUFFER_SIZE_KB 大 50% 以上的记录。

设置基于时间的保留

默认情况下，给定组件的所有收集数据都保留在磁盘上，并且可以在组件的数据收集器表中进行访问，直至达到该组件的保留策略的磁盘存储限值（由其 DISK_SIZE_KB 属性设置）。您可以调用 SET_DATA_COLLECTOR_POLICY 来限制数据在组件的数据收集器表中保留的时间。在以下示例中，对组件 TupleMoverEvents 调用 SET_DATA_COLLECTOR_POLICY 并将其 INTERVAL_TIME 属性设置为 30 分钟间隔：

SELECT set_data_collector_policy('TupleMoverEvents ', '30 minutes'::interval);
set_data_collector_time_policy
--------------------------------
SET
(1 row)

在此调用之后，数据收集器表 dc_tuple_mover_events 仅保留过去 30 分钟内发生的 Tuple Mover 活动的记录。旧 Tuple Mover 数据会自动从该表中删除。例如，在上一次调用 SET_DATA_COLLECTOR_POLICY 之后，查询 dc_tuple_mover_events 会返回过去 30 分钟（在本例中，是从 07:58:21 开始）内收集的 Tuple Mover 活动的数据：

=> SELECT current_timestamp(0)  - '30 minutes'::interval AS '30 minutes ago';
   30 minutes ago
---------------------
 2020-08-13 07:58:21
(1 row)

=> SELECT time, node_name, session_id, user_name, transaction_id, operation FROM dc_tuple_mover_events WHERE node_name='v_vmart_node0001' ORDER BY transaction_id;
             time              |    node_name     |           session_id            | user_name |  transaction_id   | operation
-------------------------------+------------------+---------------------------------+-----------+-------------------+-----------
 2020-08-13 08:16:54.360597-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807826 | Mergeout
 2020-08-13 08:16:54.397346-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807826 | Mergeout
 2020-08-13 08:16:54.424002-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807826 | Mergeout
 2020-08-13 08:16:54.425989-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807829 | Mergeout
 2020-08-13 08:16:54.456829-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807829 | Mergeout
 2020-08-13 08:16:54.485097-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807829 | Mergeout
 2020-08-13 08:19:45.8045-04   | v_vmart_node0001 | v_vmart_node0001-190508:0x37b08 | dbadmin   | 45035996273807855 | Mergeout
 2020-08-13 08:19:45.742-04    | v_vmart_node0001 | v_vmart_node0001-190508:0x37b08 | dbadmin   | 45035996273807855 | Mergeout
 2020-08-13 08:19:45.684764-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x37b08 | dbadmin   | 45035996273807855 | Mergeout
 2020-08-13 08:19:45.799796-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807865 | Mergeout
 2020-08-13 08:19:45.768856-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807865 | Mergeout
 2020-08-13 08:19:45.715424-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807865 | Mergeout
 2020-08-13 08:25:20.465604-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807890 | Mergeout
 2020-08-13 08:25:20.497266-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807890 | Mergeout
 2020-08-13 08:25:20.518839-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807890 | Mergeout
 2020-08-13 08:25:20.52099-04  | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807893 | Mergeout
 2020-08-13 08:25:20.549075-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807893 | Mergeout
 2020-08-13 08:25:20.569072-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807893 | Mergeout
(18 rows)

25 分钟过去后，这些记录中有 12 条超出了为 TupleMoverEvents 设置的 30 分钟间隔，将从 dc_tuple_mover_events 中删除：

=> SELECT current_timestamp(0)  - '30 minutes'::interval AS '30 minutes ago';
   30 minutes ago
---------------------
 2020-08-13 08:23:33
(1 row)


=> SELECT time, node_name, session_id, user_name, transaction_id, operation FROM dc_tuple_mover_events WHERE node_name='v_vmart_node0001' ORDER BY transaction_id;
             time              |    node_name     |           session_id            | user_name |  transaction_id   | operation
-------------------------------+------------------+---------------------------------+-----------+-------------------+-----------
 2020-08-13 08:25:20.465604-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807890 | Mergeout
 2020-08-13 08:25:20.497266-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807890 | Mergeout
 2020-08-13 08:25:20.518839-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807890 | Mergeout
 2020-08-13 08:25:20.52099-04  | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807893 | Mergeout
 2020-08-13 08:25:20.549075-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807893 | Mergeout
 2020-08-13 08:25:20.569072-04 | v_vmart_node0001 | v_vmart_node0001-190508:0x375db | dbadmin   | 45035996273807893 | Mergeout
(6 rows)

元函数 SET_DATA_COLLECTOR_TIME_POLICY 也设置保留策略的 INTERVAL_TIME 属性。与 SET_DATA_COLLECTOR_POLICY 不同，此元函数仅设置 INTERVAL_TIME 属性。不同之处还在于，您可以使用此元函数通过省略组件实参来更新所有组件上的 INTERVAL_TIME。例如：

SELECT set_data_collector_time_policy('1 day'::interval);
set_data_collector_time_policy
--------------------------------
SET
(1 row)

=> SELECT DISTINCT component, INTERVAL_SET, INTERVAL_TIME FROM DATA_COLLECTOR WHERE component ILIKE '%partition%';
      component       | INTERVAL_SET | INTERVAL_TIME
----------------------+--------------+---------------
 HiveCustomPartitions | t            | 1
 MovePartitions       | t            | 1
 CopyPartitions       | t            | 1
 SwapPartitions       | t            | 1
(4 rows)

要清除 INTERVAL_TIME 策略属性，请调用带有负整数实参的 SET_DATA_COLLECTOR_TIME_POLICY。例如：

=> SELECT set_data_collector_time_policy('-1');
 set_data_collector_time_policy
--------------------------------
 SET
(1 row)

=> SELECT DISTINCT component, INTERVAL_SET, INTERVAL_TIME FROM DATA_COLLECTOR WHERE component ILIKE '%partition%';
      component       | INTERVAL_SET | INTERVAL_TIME
----------------------+--------------+---------------
 MovePartitions       | f            | 0
 SwapPartitions       | f            | 0
 HiveCustomPartitions | f            | 0
 CopyPartitions       | f            | 0
(4 rows)

9.2 - 查询数据收集器表

您可以从数据收集器表中获取特定于组件的数据。数据收集器将其日志文件中的组件数据编译为可以通过标准 SQL 查询进行查询的表格式。您可以通过数据收集器系统表识别特定组件的数据收集器表名。例如：

=> SELECT distinct component, table_name FROM data_collector where component ILIKE 'lock%';
  component   |    table_name
--------------+------------------
 LockRequests | dc_lock_requests
 LockReleases | dc_lock_releases
 LockAttempts | dc_lock_attempts
(3 rows)

然后，您可以查询所需的数据收集器表 — 例如，检查 dc_lock_attempts 中的锁定延迟：

=> SELECT * from dc_lock_attempts WHERE description != 'Granted immediately';
-[ RECORD 1 ]------+------------------------------
time               | 2020-08-17 00:14:07.187607-04
node_name          | v_vmart_node0001
session_id         | v_vmart_node0001-319647:0x1d
user_id            | 45035996273704962
user_name          | dbadmin
transaction_id     | 45035996273819050
object             | 0
object_name        | Global Catalog
mode               | X
promoted_mode      | X
scope              | TRANSACTION
start_time         | 2020-08-17 00:14:07.184663-04
timeout_in_seconds | 300
result             | granted
description        | Granted after waiting

9.3 - 管理数据收集日志

启动时，Vertica 在每个节点的数据库编录目录下创建一个 DataCollector 目录。对于各个组件，此目录包含一个或多个日志。例如：

[dbadmin@doch01 DataCollector]$ pwd
/home/dbadmin/VMart/v_vmart_node0001_catalog/DataCollector
[dbadmin@doch01 DataCollector]$ ls -1 -g Lock*
-rw------- 1 verticadba 2559879 Aug 17 00:14 LockAttempts_650572441057355.log
-rw------- 1 verticadba  614579 Aug 17 05:28 LockAttempts_650952885486175.log
-rw------- 1 verticadba 2559895 Aug 14 18:31 LockReleases_650306482037650.log
-rw------- 1 verticadba 1411127 Aug 17 05:28 LockReleases_650759468041873.log

对于每个组件，DataCollector 目录还包含一对 SQL 模板文件：

  • CREATE_component_TABLE.sql 提供用于创建表的 DDL，您可以在其中加载给定组件的数据收集器日志 — 例如，LockAttempts：

    [dbadmin@doch01 DataCollector]$ cat CREATE_LockAttempts_TABLE.sql
\set dcschema 'echo ${DCSCHEMA:-dc}'
CREATE TABLE :dcschema.dc_lock_attempts(
  "time" TIMESTAMP WITH TIME ZONE,
  "node_name" VARCHAR(128),
  "session_id" VARCHAR(128),
  "user_id" INTEGER,
  "user_name" VARCHAR(128),
  "transaction_id" INTEGER,
  "object" INTEGER,
  "object_name" VARCHAR(128),
  "mode" VARCHAR(128),
  "promoted_mode" VARCHAR(128),
  "scope" VARCHAR(128),
  "start_time" TIMESTAMP WITH TIME ZONE,
  "timeout_in_seconds" INTEGER,
  "result" VARCHAR(128),
  "description" VARCHAR(64000)
);

  • COPY_component_TABLE.sql 包含用于（通过 COPY）将数据日志文件加载到 CREATE 脚本所创建的表中的 SQL。例如：

    [dbadmin@doch01 DataCollector]$ cat COPY_LockAttempts_TABLE.sql
\set dcpath 'echo ${DCPATH:-$PWD}'
\set dcschema 'echo ${DCSCHEMA:-dc}'
\set logfiles '''':dcpath'/LockAttempts_*.log'''
COPY :dcschema.dc_lock_attempts(
  LockAttempts_start_filler FILLER VARCHAR(64) DELIMITER E'\n',
  "time_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "time" FORMAT '_internal' DELIMITER E'\n',
  "node_name_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "node_name" ESCAPE E'\001' DELIMITER E'\n',
  "session_id_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "session_id" ESCAPE E'\001' DELIMITER E'\n',
  "user_id_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "user_id" FORMAT 'd' DELIMITER E'\n',
  "user_name_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "user_name" ESCAPE E'\001' DELIMITER E'\n',
  "transaction_id_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "transaction_id" FORMAT 'd' DELIMITER E'\n',
  "object_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "object" FORMAT 'd' DELIMITER E'\n',
  "object_name_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "object_name" ESCAPE E'\001' DELIMITER E'\n',
  "mode_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "mode" ESCAPE E'\001' DELIMITER E'\n',
  "promoted_mode_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "promoted_mode" ESCAPE E'\001' DELIMITER E'\n',
  "scope_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "scope" ESCAPE E'\001' DELIMITER E'\n',
  "start_time_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "start_time" FORMAT '_internal' DELIMITER E'\n',
  "timeout_in_seconds_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "timeout_in_seconds" FORMAT 'd' DELIMITER E'\n',
  "result_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "result" ESCAPE E'\001' DELIMITER E'\n',
  "description_nfiller" FILLER VARCHAR(32) DELIMITER ':',
  "description" ESCAPE E'\001'
)  FROM :logfiles RECORD TERMINATOR E'\n.\n' DELIMITER E'\n';

日志管理元函数

您可以使用 Vertica 元函数 FLUSH_DATA_COLLECTOR 和 CLEAR_DATA_COLLECTOR 管理数据收集器日志。这两个函数都可以指定单个组件，也可以对所有组件执行：

  • FLUSH_DATA_COLLECTOR 等待内存日志移至磁盘后，刷新数据收集器，同时将日志与磁盘存储同步。例如，对所有组件执行以下语句：

    => SELECT flush_data_collector();
 flush_data_collector
----------------------
 FLUSH
(1 row)

  • CLEAR_DATA_COLLECTOR 清除数据收集器表和日志中的所有内存及磁盘记录，并重置 DATA_COLLECTOR 系统表中的收集统计信息。例如，对为 ResourceAcquisitions 组件收集的数据执行以下语句：

    => SELECT clear_data_collector('ResourceAcquisitions');
 clear_data_collector
----------------------
 CLEAR
(1 row)

10 - 监控分区重组

在使用 ALTER TABLE...REORGANIZE 时，操作会在后台重组数据。

可以通过轮询以下系统表来监控重组进程的详细信息：

11 - 监控资源池

您可以使用以下内容查找有关资源池的信息：

您还可以使用管理控制台获取有关资源池使用情况的运行时数据。

查看资源池状态

以下示例在 RESOURCE_POOL_STATUS 中查询内存大小数据：

=> SELECT pool_name poolName,
    node_name nodeName,
    max_query_memory_size_kb maxQueryMemSizeKb,
    max_memory_size_kb maxMemSizeKb,
    memory_size_actual_kb memSizeActualKb
    FROM resource_pool_status WHERE pool_name='ceo_pool';
 poolName |     nodeName     | maxQueryMemSizeKb | maxMemSizeKb | memSizeActualKb
----------+------------------+-------------------+--------------+-----------------
 ceo_pool | v_vmart_node0001 |          12179388 |     13532654 |         1843200
 ceo_pool | v_vmart_node0002 |          12191191 |     13545768 |         1843200
 ceo_pool | v_vmart_node0003 |          12191170 |     13545745 |         1843200
(3 rows)

查看通过查询获取的资源

以下示例显示了授予当前正在运行的查询的所有资源。这里显示的信息存储在 RESOURCE_ACQUISITIONS 系统表中。您可以看到查询执行使用了 GENERAL 池中 708504 KB 的内存。

=> SELECT pool_name, thread_count, open_file_handle_count, memory_inuse_kb,
   queue_entry_timestamp, acquisition_timestamp
   FROM V_MONITOR.RESOURCE_ACQUISITIONS WHERE node_name ILIKE '%node0001';

-[ RECORD 1 ]----------+------------------------------
pool_name              | sysquery
thread_count           | 4
open_file_handle_count | 0
memory_inuse_kb        | 4103
queue_entry_timestamp  | 2013-12-05 07:07:08.815362-05
acquisition_timestamp  | 2013-12-05 07:07:08.815367-05
-[ RECORD 2 ]----------+------------------------------
...
-[ RECORD 8 ]----------+------------------------------
pool_name              | general
thread_count           | 12
open_file_handle_count | 18
memory_inuse_kb        | 708504
queue_entry_timestamp  | 2013-12-04 12:55:38.566614-05
acquisition_timestamp  | 2013-12-04 12:55:38.566623-05
-[ RECORD 9 ]----------+------------------------------
...

您可以确定查询运行之前在队列中的等待时间。为此，您应使用以下示例中所示的查询，获取 acquisition_timestamp 和 queue_entry_timestamp 之差：

=> SELECT pool_name, queue_entry_timestamp, acquisition_timestamp,
    (acquisition_timestamp-queue_entry_timestamp) AS 'queue wait'
   FROM V_MONITOR.RESOURCE_ACQUISITIONS WHERE node_name ILIKE '%node0001';

-[ RECORD 1 ]---------+------------------------------
pool_name             | sysquery
queue_entry_timestamp | 2013-12-05 07:07:08.815362-05
acquisition_timestamp | 2013-12-05 07:07:08.815367-05
queue wait            | 00:00:00.000005
-[ RECORD 2 ]---------+------------------------------
pool_name             | sysquery
queue_entry_timestamp | 2013-12-05 07:07:14.714412-05
acquisition_timestamp | 2013-12-05 07:07:14.714417-05
queue wait            | 00:00:00.000005
-[ RECORD 3 ]---------+------------------------------
pool_name             | sysquery
queue_entry_timestamp | 2013-12-05 07:09:57.238521-05
acquisition_timestamp | 2013-12-05 07:09:57.281708-05
queue wait            | 00:00:00.043187
-[ RECORD 4 ]---------+------------------------------
...

查询用户定义的资源池

系统表 RESOURCE_POOLS 和 RESOURCE_POOL_STATUS 中的布尔列 IS_INTERNAL 允许您仅获取有关用户定义的资源池的数据。例如：

SELECT name, subcluster_oid, subcluster_name, memorysize, maxmemorysize, priority, maxconcurrency
dbadmin->     FROM V_CATALOG.RESOURCE_POOLS where is_internal ='f';
   name       |  subcluster_oid   | subcluster_name | memorysize | maxmemorysize | priority | maxconcurrency
--------------+-------------------+-----------------+------------+---------------+----------+----------------
 load_pool    | 72947297254957395 | default         | 0%         |               |       10 |
 ceo_pool     | 63570532589529860 | c_subcluster    | 250M       |               |       10 |
 ad hoc_pool  |                 0 |                 | 200M       | 200M          |        0 |
 billing_pool | 45579723408647896 | ar_subcluster   | 0%         |               |        0 |              3
 web_pool     |                 0 | analytics_1     | 25M        |               |       10 |              5
 batch_pool   | 47479274633682648 | default         | 150M       | 150M          |        0 |             10
 dept1_pool   |                 0 |                 | 0%         |               |        5 |
 dept2_pool   |                 0 |                 | 0%         |               |        8 |
 dashboard    | 45035996273843504 | analytics_1     | 0%         |               |        0 |
(9 rows)

12 - 监控恢复

当您的 Vertica 数据库从故障中恢复时，监控恢复过程非常重要。有多种方法可以监控数据库恢复：

12.1 - 查看每个节点的日志文件

在数据库恢复期间，Vertica 会向每个主机上的 vertica.log 添加日志记录消息。每个消息均标有字符串 [Recover]。

使用 tail 命令查看相关状态消息以监控恢复进度，如下所示。

$ tail -f catalog-path/database-name/node-name_catalog/vertica.log
01/23/08 10:35:31 thr:Recover:0x2a98700970 [Recover] <INFO> Changing host v_vmart_node0001 startup state from INITIALIZING to RECOVERING
01/23/08 10:35:31 thr:CatchUp:0x1724b80 [Recover] <INFO> Recovering to specified epoch 0x120b6
01/23/08 10:35:31 thr:CatchUp:0x1724b80 [Recover] <INFO> Running 1 split queries
01/23/08 10:35:31 thr:CatchUp:0x1724b80 [Recover] <INFO> Running query: ALTER PROJECTION proj_tradesquotes_0 SPLIT v_vmart_node0001 FROM 73911;

12.2 - 使用系统表来监控恢复

使用以下系统表来监控恢复：

具体来讲，recovery_status 系统表包括有关正在恢复的节点、要恢复的时期、当前恢复阶段以及运行状态的信息：

=>select node_name, recover_epoch, recovery_phase, current_completed, is_running from recovery_status;
node_name            | recover_epoch | recovery_phase    | current_completed | is_running
---------------------+---------------+-------------------+-------------------+--------------
 v_vmart_node0001    |               |                   | 0                 | f
 v_vmart_node0002    | 0             | historical pass 1 | 0                 | t
 v_vmart_node0003    | 1             | current           | 0                 | f

projection_recoveries 系统表维护投影恢复的历史记录。若要检查恢复状态，可汇总正在恢复的节点的数据，并多次运行同一查询以查看计数是否发生变化。计数不同表示正在执行恢复工作，所有丢失的数据正在恢复中。

=> select node_name, status , progress from projection_recoveries;
node_name              | status      | progress
-----------------------+-------------+---------
v_vmart_node0001       | running     | 61

若要查看 projection_recoveries 系统表中的单个记录，请向查询中添加限值 1。

恢复完成后，Vertica 继续存储这些表中的最近恢复的信息。

12.3 - 查看群集状态和恢复状态

使用 admintools view_cluster 工具从命令行查看群集状态：

$ /opt/vertica/bin/admintools -t view_cluster
DB | Host | State
---------+--------------+------------
<data_base> | 112.17.31.10 | RECOVERING
<data_base> | 112.17.31.11 | UP
<data_base> | 112.17.31.12 | UP
<data_base> | 112.17.31.17 | UP
________________________________

12.4 - 监控恢复后的群集状态

恢复完成时：

  1. 启动管理工具。

  2. 从“主菜单 (Main Menu)”中选择查看数据库群集状态 (View Database Cluster State)，然后单击确定 (OK)。

    实用程序将节点状态报告为 UP。

13 - 清除投影刷新历史记录

系统表 PROJECTION_REFRESHES 记录刷新操作成功和失败的相关信息。PROJECTION_REFRESHES 将保留投影刷新数据，直到出现以下事件之一为止：

  • 给定的投影中开始出现另一个刷新操作。

  • CLEAR_PROJECTION_REFRESHES PROJECTION_REFRESHES 被调用并清除所有投影的数据。

  • 已超出表的存储配额。

要立即清除此信息，请调用 CLEAR_PROJECTION_REFRESHES：

=> SELECT clear_projection_refreshes();
clear_projection_refreshes
----------------------------
 CLEAR
(1 row)

另请参阅

PROJECTION_REFRESHES

14 - 使用通知程序监控 Vertica

Vertica 通知程序是一种基于推送的机制，用于将消息从 Vertica 发送到 Apache Kafka 或 syslog 等端点。例如，您可以将长时间运行的脚本配置为在各个阶段以及任务完成时发送通知。

要使用通知程序：

  1. 创建 syslog 或 Kafka 通知程序。

  2. 使用以下任何内容向 NOTIFIER 端点发送通知：

    • NOTIFY：手动向 NOTIFIER 端点发送消息。

    • SET_DATA_COLLECTOR_NOTIFY_POLICY：创建一个通知策略，当指定的事件发生时，该策略会自动向 NOTIFIER 端点发送消息。