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

返回本页常规视图.

时期

时期代表数据库中历史数据的一个截止点。给定时期内所有提交的时间戳等于或小于该时期的时间戳。当您需要执行以下操作时，了解时期很有用：

  • 数据库恢复Vertica 使用时期来确定上次数据在数据库群集中的所有节点之间保持一致的时间。

  • 执行历史查询：包括 AT epoch 子句的 SELECT 语句仅返回在指定时期或之前提交的数据。

  • 清除删除的数据：删除的数据在从数据库中清除之前不会从物理存储中移除。删除的数据只有在早于 Ancient History Mark (AHM) 时期时才能从数据库中清除。

Vertica 有一个开放时期和任意数量的封闭时期，具体取决于您的系统配置。新的和更新的数据被写入开放时期，每个封闭时期代表一个对数据库的先前提交。当使用 DML 操作（INSERT、UPDATE、MERGE、COPY 或 DELETE）提交数据时，Vertica 会写入数据，关闭开放时期，然后打开一个新时期。提交到数据库的每一行都与写入它的时期相关联。

EPOCHS 系统表包含有关每个可用封闭时期的信息。epoch_close_time 列存储提交日期和时间。epoch_number 列存储对应的时期编号：

=> SELECT * FROM EPOCHS;
       epoch_close_time        | epoch_number
-------------------------------+--------------
 2020-07-27 14:29:49.687106-04 |           91
 2020-07-28 12:51:53.291795-04 |           92
(2 rows)

时期里程碑

随着时期在其生命周期中向前推移，它达到里程碑，Vertica 使用里程碑来执行各种操作并维护数据库的状态。下图大致描述了时期生命周期中的里程碑：

Vertica 对每个里程碑的定义如下：

  • 当前时期 (CE)：您当前正在向其中写入数据的当前开放时期。

  • 最新时期 (LE)：最近封闭的时期。

  • 检查点时期：仅限 Enterprise 模式。节点级别的最新时期，在该时期内，数据在该节点上的所有投影之间保持一致。

  • 上一个完好的时期 (LGE)：数据在所有节点之间保持一致的最小检查点时期。

  • Ancient history mark (AHM)：包含历史查询可访问的数据的最旧时期。

有关每个阶段的详细信息，请参阅时期生命周期。

1 - 时期生命周期

时期生命周期由一系列里程碑组成，使您能够执行各种操作并管理数据库的状态。

Vertica 提供时期管理参数和函数，以便您可以检索和调整时期值。此外，请参阅配置时期获取有关如何为特定用例设置时期的建议。

当前时期 (CE)

包含您当前写入数据库的所有未提交更改的开放时期。当前时期存储在 SYSTEM 系统表中：

=> SELECT CURRENT_EPOCH FROM SYSTEM;
 CURRENT_EPOCH
---------------
         71
(1 row)

以下示例演示了当您提交数据时当前时期如何前进：

  1. 查询 SYSTEM 系统表以返回当前时期：

    => SELECT CURRENT_EPOCH FROM SYSTEM;
 CURRENT_EPOCH
---------------
         71
(1 row)

    当前时期是开放时期，这意味着它是您当前正在向其中写入数据的时期。

  2. 向 orders 表中插入行：

    => INSERT INTO orders VALUES ('123456789', 323426, 'custacct@example.com');
 OUTPUT
--------
      1
(1 row)

    每行数据都有一个隐含的时期列，用于存储该行的提交时期。您刚刚插入到表中的行没有提交，因此 epoch 列是空白的：

    => SELECT epoch, orderkey, custkey, email_addrs FROM orders;
 epoch | orderkey  | custkey |     email_addrs
-------+-----------+---------+----------------------
       | 123456789 |  323426 | custacct@example.com
(1 row)

  3. 提交数据，然后再次查询该表。提交的数据与时期 71（即先前从 SYSTEM 系统表返回的当前时期）相关联：

    => COMMIT;
COMMIT
=> SELECT epoch, orderkey, custkey, email_addrs FROM orders;
 epoch | orderkey  | custkey |     email_addrs
-------+-----------+---------+----------------------
    71 | 123456789 |  323426 | custacct@example.com
(1 row)

  4. 再次查询 SYSTEMS 表以返回当前时期。当前时期高 1 个整数：

    => SELECT CURRENT_EPOCH FROM SYSTEM;
 CURRENT_EPOCH
---------------
         72
(1 row)

最新时期 (LE)

最近封闭的时期。在提交操作之后，当前时期成为最新时期。

LE 是存储在 EPOCHS 系统表中的最近的时期：

=> SELECT * FROM EPOCHS;
       epoch_close_time        | epoch_number
-------------------------------+--------------
 2020-07-27 14:29:49.687106-04 |           91
 2020-07-28 12:51:53.291795-04 |           92
(2 rows)

检查点时期 (CPE)

仅在企业模式下有效。每个节点都有一个检查点时期，这是该节点上的数据在所有投影之间保持一致的最近一个时期。当数据库以最佳方式运行时，检查点时期等于 LE，它总是比当前时期早一个时期。

在节点故障和恢复期间使用检查点时期。当单个节点发生故障时，该节点会尝试从其他节点重建超出其检查点时期的数据。如果故障节点无法使用这些时期中的任何一个时期来恢复数据，则故障节点将使用检查点时期来恢复数据。

使用 PROJECTION_CHECKPOINT_EPOCHS 来查询有关检查点时期的信息。以下查询返回有关用来存储 orders 投影的节点上的检查点时期的信息：

=> SELECT checkpoint_epoch, node_name, projection_name, is_up_to_date, would_recover, is_behind_ahm
      FROM PROJECTION_CHECKPOINT_EPOCHS WHERE projection_name ILIKE 'orders_b%';
 checkpoint_epoch |    node_name     | projection_name | is_up_to_date | would_recover | is_behind_ahm
------------------+------------------+-----------------+---------------+---------------+---------------
               92 | v_vmart_node0001 | orders_b1       | t             | f             | f
               92 | v_vmart_node0001 | orders_b0       | t             | f             | f
               92 | v_vmart_node0003 | orders_b1       | t             | f             | f
               92 | v_vmart_node0003 | orders_b0       | t             | f             | f
               92 | v_vmart_node0002 | orders_b0       | t             | f             | f
               92 | v_vmart_node0002 | orders_b1       | t             | f             | f
(6 rows)

此查询确认数据库时期正在以正确方式前进。当上一个完好的时期 (LGE) 等于 CPE 时，would_recover 列显示 f，因为 Vertica 会尽可能优先考虑 LGE 进行恢复。is_behind_ahm 列显示检查点时期是否在 AHM 之后。在数据库或节点出现故障时，早于 Ancient History Mark (AHM) 的时期中的任何数据都不可恢复。

上一个完好的时期 (LGE)

数据在群集中的所有节点之间保持一致的最小检查点时期。每个节点都有一个 LGE，Vertica 评估每个节点的 LGE 以确定群集 LGE。群集的 LGE 存储在 SYSTEM 系统表中：

=> SELECT LAST_GOOD_EPOCH FROM SYSTEM;
 LAST_GOOD_EPOCH
-----------------
              70
(1 row)

您可以通过查询预期恢复时期来检索每个节点的 LGE：

=> SELECT GET_EXPECTED_RECOVERY_EPOCH();
INFO 4544:  Recovery Epoch Computation:
Node Dependencies:
011 - cnt: 21
101 - cnt: 21
110 - cnt: 21
111 - cnt: 9

001 - name: v_vmart_node0001
010 - name: v_vmart_node0002
100 - name: v_vmart_node0003
Nodes certainly in the cluster:
        Node 0(v_vmart_node0001), epoch 70
        Node 1(v_vmart_node0002), epoch 70
Filling more nodes to satisfy node dependencies:
Data dependencies fulfilled, remaining nodes LGEs don't matter:
        Node 2(v_vmart_node0003), epoch 70
--
 GET_EXPECTED_RECOVERY_EPOCH
-----------------------------
                          70
(1 row)

因为 LGE 是磁盘上所有最近数据的快照，所以使用它从数据库故障中恢复。管理工具使用 LGE 手动重置数据库。如果您在非正常关闭后从数据库故障中恢复，Vertica 会在重新启动期间提示您接受使用 LGE 进行恢复。

Ancient history mark (AHM)

包含历史查询可访问的数据的最旧时期。AHM 存储在 SYSTEM 系统表中：

=> SELECT AHM_EPOCH FROM SYSTEM;
 AHM_EPOCH
-----------
        70
(1 row)

AHM 之前的时期不可用于历史查询。以下示例返回 AHM，然后在执行早于 AHM 的历史查询时返回错误：

=> SELECT GET_AHM_EPOCH();
 GET_AHM_EPOCH
---------------
            93
(1 row)

=> AT EPOCH 92 SELECT * FROM orders;
ERROR 3183:  Epoch number out of range
HINT:  Epochs prior to [93] do not exist. Epochs [94] and later have not yet closed

AHM 根据您的 HistoryRetentionTime、HistoryRetentionEpochs 和 AdvanceAHMInterval 参数设置前进。默认情况下，AHM 每 180 秒前进一次，直到等于 LGE。这有助于减少保存到时期映射的时期数量，从而减小编录大小。AHM 无法超越 LGE。

AHM 充当从物理磁盘清除数据的截止时期。随着 AHM 前进，Tuple Mover 合并过程会清除属于 AHM 之前时期的所有已删除数据。有关自动或手动清除的详细信息，请参阅清除删除的数据。

2 - 管理时期

时期存储在时期映射中，这是一个编录对象，其中包含从 Ancient History Mark (AHM) 时期开始到最新时期 (LE) 结束的封闭时期列表。时期映射越大，编录使用的内存越大。此外，AHM 用于确定从磁盘清除哪些数据。为了优化数据库性能，一定要监控数据库时期以验证它们是否正确前进。

监控时期

当 Vertica 使用默认 Vertica 设置正常运行时，Ancient History Mark、上一个完好的时期 (LGE) 和检查点时期（CPE，仅限企业模式）等于最新时期，或比当前时期小 1。这将确保不使用磁盘空间来存储符合清除条件的数据，从而保持对时期映射和编录大小的控制。SYSTEM 系统表存储当前时期、上一个完好的时期和 Ancient History Mark：

=> SELECT CURRENT_EPOCH, LAST_GOOD_EPOCH, AHM_EPOCH FROM SYSTEM;
 CURRENT_EPOCH | LAST_GOOD_EPOCH | AHM_EPOCH
---------------+-----------------+-----------
            88 |              87 |        87
(1 row)

Vertica 提供 GET_AHM_EPOCH、GET_AHM_TIME、GET_CURRENT_EPOCH 和 GET_LAST_GOOD_EPOCH 来单独检索这些时期。

在企业模式下，您可以使用 PROJECTION_CHECKPOINT_EPOCHS 表查询检查点时期，以返回群集中每个节点的检查点时期。以下查询返回用来存储 orders 投影的任何节点的 CPE：

=> SELECT checkpoint_epoch, node_name, projection_name
     FROM PROJECTION_CHECKPOINT_EPOCHS WHERE projection_name ILIKE 'orders_b%';
 checkpoint_epoch |    node_name     | projection_name
------------------+------------------+-----------------
               87 | v_vmart_node0001 | orders_b1
               87 | v_vmart_node0001 | orders_b0
               87 | v_vmart_node0003 | orders_b1
               87 | v_vmart_node0003 | orders_b0
               87 | v_vmart_node0002 | orders_b0
               87 | v_vmart_node0002 | orders_b1
(6 rows)

对 Ancient History Mark 进行故障排除

正常运行的 AHM 对于确定数据库利用磁盘空间和执行查询的优度至关重要。当您提交 DELETE 或 UPDATE（DELETE 和 INSERT 的组合）操作时，数据不会立即从磁盘中删除。相反，Vertica 会将数据标记为删除，因此您可以使用历史查询来检索它。删除的数据会占用磁盘空间并影响查询性能，因为 Vertica 在非历史查询期间必须读取删除的数据。

时期会随着您提交数据而前进，并且标记为删除的任何数据都会在其时期超越 AHM 时由 Tuple Mover 合并过程自动清除。您可以创建自动清除策略或手动清除在 AHM 之前的时期中提交的任何已删除数据。有关其他信息，请参阅设置清除策略。

默认情况下，AHM 每 180 秒前进一次，直到等于 LGE。监控 SYSTEM 系统表以确保 AHM 正在以正确方式前进：

=> SELECT CURRENT_EPOCH, LAST_GOOD_EPOCH, AHM_EPOCH FROM SYSTEM;
 CURRENT_EPOCH | LAST_GOOD_EPOCH | AHM_EPOCH
---------------+-----------------+-----------
            94 |              93 |        86
(1 row)

如果您注意到 AHM 未正确前进，可能是由于下面的一种或多种原因：

  • 您的数据库包含未刷新的投影。当您为已经包含数据的表创建投影时，便会发生这种情况。有关如何刷新投影的详细信息，请参阅刷新投影。

  • 节点处于 DOWN 状态。当节点处于 DOWN 状态时，AHM 不能前进。有关如何解决此问题的信息，请参阅在主机上重新启动 Vertica。

  • 确认 AHMBackupManagement 时期参数设置为 0。如果此参数设置为 1，则 AHM 不会超越最近的完整备份：

    => SELECT node_name, parameter_name, current_value FROM CONFIGURATION_PARAMETERS WHERE parameter_name='AHMBackupManagement';
 node_name |   parameter_name    | current_value
-----------+---------------------+---------------
 ALL       | AHMBackupManagement | 0
(1 row)

3 - 配置时期

时期配置会影响数据库如何从故障中恢复、处理历史数据以及从磁盘中清除数据。Vertica 为系统范围的时期配置提供时期管理参数。时期管理函数使您能够对时期值进行临时调整。

历史查询与恢复精度

当您执行历史查询时，Vertica 在由 EpochMapInterval 配置参数指定的时间内返回一个时期。例如，当您使用 AT TIME time 时期子句执行历史查询时，Vertica 在由该参数设置指定的时间内返回一个时期。默认情况下，EpochMapInterval 设置为 180 秒。您必须将 EpochMapInterval 设置为大于或等于 AdvanceAHMInterval 参数的值：

=> SELECT node_name, parameter_name, current_value FROM CONFIGURATION_PARAMETERS
     WHERE parameter_name='EpochMapInterval' OR parameter_name='AdvanceAHMInterval';
 node_name |   parameter_name   | current_value
-----------+--------------------+---------------
 ALL       | EpochMapInterval   | 180
 ALL       | AdvanceAHMInterval | 180
(2 rows)

在故障恢复期间，Vertica 使用 EpochMapInterval 设置来确定将哪个时期报告为上一个完好的时期 (LGE)。

历史记录保留和清除工作流

Vertica 建议您配置时期参数以创建清除策略，从而确定何时从磁盘清除已删除的数据。如果您经常使用历史查询，那么您需要在保存已删除的历史数据和从磁盘中清除历史数据之间找到一个平衡点。主动清除策略会提高磁盘利用率和查询性能，但也会限制您的恢复选项并缩小可用于历史查询的数据时段。

可通过以下两种战略来创建清除策略：

  • 设置 HistoryRetentionTime 以指定已删除数据作为历史参考保存的时间长度（以秒为单位）。

  • 设置 HistoryRetentionEpochs 以指定要保存的历史时期数。

有关配置每个工作流的详细信息，请参阅设置清除策略。

设置 HistoryRetentionTime 是创建清除策略的首选方法。默认情况下，Vertica 将此值设置为 0，因此当数据库正常运行时，AHM 比当前时期小 1。您无法针对 AHM 之前的时期执行历史查询，因此您可能需要调整此设置才能在当前时间和 AHM 之间保存更多数据。调整此参数的另一个原因是，如果您使用将数据库回退至上一个完好的时期 (Roll Back Database to Last Good Epoch) 选项进行手动回退。例如，以下命令将 HistoryRetentionTime 设置为 1 天（以秒为单位）以提供更广泛的时期回退选项：

=> ALTER DATABASE vmart SET HistoryRetentionTime = 86400;

Vertica 使用 AdvanceAHMInterval 设置检查您的保留设置的状态，并根据需要使 AHM 前进。在 AHM 前进后，Tuple Mover 合并过程会自动清除在早于 AHM 的时期中删除的所有数据。

如果要禁用任何清除策略并保留所有历史数据，请将 HistoryRetentionTime 和 HistoryRetentionEpochs 设置为 -1：

=> ALTER DABABASE vmart SET HistoryRetentionTime = -1;
=> ALTER DATABASE vmart SET HistoryRetentionEpochs = -1;

如果未设置清除策略，则可以使用时期管理函数来调整 AHM 以根据需要手动清除已删除的数据。如果您需要更新或删除错误上传的数据，手动清除非常有用。有关详细信息，请参阅手动清除数据。