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

故障恢复

1: 在主机上重新启动 Vertica
2: 重新启动数据库
3: 从备份中恢复群集
4: 恢复阶段
5: 时期

5.1: 时期生命周期
5.2: 管理时期
5.3: 配置时期

6: 灾难恢复最佳实践
7: 按表恢复

7.1: 确定表恢复的优先级
7.2: 查看表恢复状态

硬件或软件问题可能会迫使群集中的节点发生故障。在这种情况下，一个或多个节点离开数据库。您必须先恢复这些故障节点，然后它们才能重新联接群集并恢复正常操作。

节点故障对数据库的影响

数据库中出现故障节点会影响数据库的运行方式。如果企业模式数据库的 K-safety 为 0，则丢失任何节点都会导致数据库关闭。Eon 模式数据库的 K-safety 通常不为 0（请参阅 Eon 模式数据库中的数据完整性和高可用性）。

在 K-safety 为 1 或更大的任一模式下的数据库中，数据库在丢失节点后继续正常运行。但是，数据库的性能会受到影响：

在企业模式下，另一个节点使用故障节点的数据副本替代故障节点。此节点执行的工作量必须多达通常工作量的两倍。诸如查询之类的操作将花费更长的时间，因为群集的其余部分都在等待此节点完成。
在 Eon 模式下，另一个节点将替代故障节点。Eon 模式数据库中的节点不像企业模式数据库中的节点那样维护伙伴实例投影。替代故障节点的节点将从公共存储中检索故障节点的数据以处理查询。它不会将该数据存储在存储库中。如果必须从公共存储中检索所有数据，则除了节点必须执行更多工作之外，还会减慢查询的处理速度。故障节点的性能影响通常仅限于包含它的子群集。

由于这些性能影响，您应当尽快恢复故障节点。

如果过多的数据库节点发生故障，您的数据库将失去维护 K-safety 或仲裁的能力。在 Eon 模式数据库中，丢失主节点也可能导致丢失主分片覆盖率。在其中的任何情况下，数据库都会停止正常操作以防止数据损坏。数据库对 K-safety 或仲裁丢失采取的响应方式取决于它的模式：

在企业模式下，数据库将关闭，因为它无法访问它的所有数据。
在 Eon 模式下，数据库继续以只读模式运行。用来更改全局编录的操作（例如插入数据或更改表架构）将失败。但是，可以在仍然具有分片覆盖率的任何子群集上运行查询。请参阅只读模式。

要使数据库恢复正常运行，必须还原故障节点并恢复数据库。

恢复场景

当您重新启动故障节点或数据库时，Vertica 开始执行数据库恢复过程。K-safe 数据库的恢复模式取决于故障类型：

数据库中的一个或多个节点出现故障，但数据库继续正常运行。请参阅恢复故障节点。
在数据库丢失一个或多个节点后，数据库管理员正常关闭数据库。请参阅正常关闭后恢复
在仲裁或主分片覆盖率丢失后，Eon 模式数据库进入只读模式。请参阅恢复只读 Eon 模式数据库。
企业模式数据库由于仲裁或 K-safety 丢失而非正常关闭，或者任一模式下的数据库由于出现站点级别的故障而关闭。请参阅非正常关闭后恢复

在前三种情况下，节点会在您解决其故障后自动重新联接数据库；在第四种情况（非正常关闭）下，必须手动干预才能恢复数据库。以下几个部分更为详细地讨论了这些情况。

如果恢复操作会导致表或架构超出其磁盘配额，则恢复操作仍继续进行。然后，您必须减少磁盘使用量或增加配额，才能执行其他消耗磁盘空间的操作。有关详细信息，请参阅磁盘配额。

恢复故障节点

数据库中的一个或更多节点出现故障。但是，数据库维护了仲裁和 K-safety，因此它继续运行而不会中断。

通过使用以下方法在故障节点上重新启动 Vertica 进程来恢复这些节点：

admintools 在主机上重新启动 Vertica (Restart Vertica on Host) 选项。
管理控制台中 管理 > 子群集 (Manage > Subcluster) 页面上的上的“启动 (start)”或“重新启动 (restart)”按钮。请参阅在 MC 中启动、停止和重新启动节点。

当重新启动的节点从其他节点恢复它们的数据时，它们的状态被设置为 RECOVERING。除了最后的短暂时间以外，恢复阶段对数据库事务处理没有影响。完成恢复后，重新启动的节点状态更改为 UP。

正常关闭后恢复

在节点丢失后，管理员正常关闭数据库。要进行恢复：

解决所有导致节点主机关闭的硬件或系统问题。
重新启动数据库。请参阅启动数据库。

重新启动时，在关闭之前状态为 UP 的所有节点将恢复 UP 状态。如果数据库在关闭时包含一个或多个故障节点，但它们现在可用，它们会按照上一部分中的说明开始恢复过程。

恢复只读 Eon 模式数据库

处于 Eon 模式的数据库丢失了足够多主节点，这使其进入只读模式。为了使数据库恢复正常操作，请重新启动故障节点。请参阅从只读模式恢复。

非正常关闭后恢复

如果非正常关闭，Vertica 无法完成正常关闭过程。非正常关闭的原因包括：

企业模式数据库中的关键节点出现故障，导致部分数据库数据不可用。数据库会立即关闭以防止潜在的数据损坏。
电源故障等站点范围内的事件导致所有节点重启。
由于软件或硬件故障而导致节点上的 Vertica 进程退出。

非正常关闭会使数据库处于不一致状态 — 例如在出现故障时，Vertica 可能正在将数据写入到磁盘，因此该过程会处于未完成状态。重新启动数据库时，Vertica 会确定无法正常启动，并使用上一个完好的时期确定数据上一次在所有节点上保持一致的时间。Vertica 会提示您接受使用建议的时期进行恢复。如果您接受，数据库将恢复并且所有在“上一个完好的时期”之后发生更改的数据都将丢失。如果您不接受，则数据库不会启动。

您也可以选择不接受建议的时期，而是从备份中恢复。您还可以通过管理工具的“高级菜单 (Advanced Menu)”选项“将数据库回退至上一个完好的时期 (Roll Back Database to Last Good Epoch)”选择一个早于“上一个完好的时期”的时期。在一些特殊情况下，这是非常有用的 — 例如在批量加载期间出现故障，这种情况下重新启动整个批次会更容易，即使必须重复完成部分工作。在大多数情况下，您应该接受建议的时期。

时期和节点恢复

当移动 ROS 容器时，会更新源投影和目标投影的检查点时期 (CPE)。所有存储容器（例如 ROS 容器）的开始和结束时期都改为提交时期。发生这种情况时，不具有实际数据文件重写功能的所有列的时期会将 CPE 前进到提交 MOVE_PARTITIONS_TO_TABLE 的时期。如果在分区移动操作期间有任何节点关闭，它们会检测到存在要恢复的存储。在重新联接群集时，重新启动的节点会从其他具有正确时期的节点中恢复。

有关 Vertica 如何使用时期的详细信息，请参阅时期。

手动恢复节点

在多达 K 个节点处于离线状态的情况下，可以手动恢复数据库 — 例如，这些节点通过物理方式移除以便修复或者在恢复时无法访问。还原缺失的节点时，它们会按照在恢复场景中所述的步骤恢复并重新联接群集。
如果要重新启动的节点可以提供所有分区分段，那么即使 K 个以上的节点在启动时仍然处于关闭状态，您也可以手动恢复数据库。这种情况下，您可以从剩余的群集节点中获取所有数据，因此数据库可以成功启动。
HistoryRetentionTime 配置参数的默认设置为 0，因此当节点处于关闭状态时，Vertica 仅保留历史数据。此设置将避免使用管理工具的“将数据库回退至上一个完好的时期 (Roll Back Database to Last Good Epoch)”选项，因为 AHM 仍然接近当前时期并且不允许回退到早于 AHM 的时期。如果您依赖于“回退 (Roll Back)”选项来移除最近加载的数据，请考虑设置一个单天时段用于移除加载的数据。例如：
```
=> ALTER DATABASE DEFAULT SET HistoryRetentionTime = 86400;
```
有关详细信息，请参阅时期管理参数。
若某个节点处于关闭状态并需要手动恢复，当系统尝试形成一个群集时，可能需要整整一分钟或更长时间使 Vertica 进程超时。等待大约一分钟，直到系统返回手动恢复提示。切勿在数据库启动期间按 CTRL-C。

1 - 在主机上重新启动 Vertica

当正在运行的数据库群集中的一个节点出现故障时，或者如果任一节点丢失编录或数据目录中的任何文件，可使用管理工具或管理控制台检查故障节点的状态。

使用管理工具在主机上重新启动 Vertica

运行管理工具。
从“主菜单 (Main Menu)”中选择在主机上重新启动 Vertica (Restart Vertica on Host)，然后单击确定 (OK)。
选择要恢复的数据库主机并单击确定 (OK)。

注意
您可能会在列表中看到其他节点，它们供管理工具在内部使用。您完全可以忽略这些节点。
通过从主菜单 (Main Menu) 中选择查看数据库群集状态 (View Database Cluster State) 来验证恢复状态。

数据库完全恢复后，可通过从管理工具 (Administration Tools) 主菜单 (Main Menu) 中选择查看数据库群集状态 (View Database Cluster State) 随时检查状态。

使用管理控制台在主机上重新启动 Vertica

连接到群集节点（或安装了 MC 的主机）。
打开浏览器并以 MC 管理员身份连接到 MC。
在 MC 的主页 (Home) 页面上，双击最近数据库 (Recent Databases) 部分下的运行中数据库。
在概览 (Overview) 页面内，查看“数据库 (Database)”子部分下的节点状态，并查看所有节点是否均正常运行。状态将指出正常运行、关键、出现故障、正在恢复等节点的数量。
如果节点出现故障，请单击页面底部的管理 (Manage) 并检查图形。故障节点将以红色显示。
单击故障节点将其选中，然后在“节点列表 (Node List)”中单击启动节点 (Start node) 按钮。

2 - 重新启动数据库

如果多个节点错过 Vertica 过程（例如，因断电），或者在未先正常关闭 Vertica 数据库的情况下关闭服务器，数据库群集则会在下次启动时指出其之前非正常关闭。

数据库自动检测群集上次处于一致状态的时间，管理员可在此时点重新启动数据库。

从管理工具的“主菜单 (Main Menu)”中：

验证已通过单击停止数据库 (Stop Database) 来停止数据库。

此时将显示一条消息：<dbadmin> 拥有的数据库均未运行 (No databases owned by are running)
通过从“主菜单 (Main Menu)”中选择启动数据库 (Start Database) 来启动数据库。
选择要重新启动的数据库并单击确定 (OK)。

如果您在数据库未正常关闭后将其启动，则会显示一条指示启动失败的消息。按返回 (RETURN) 可继续恢复过程。

时期表示两个特定时间点之间对数据库中所存储数据的已提交更改。启动数据库时，Vertica 将搜索上一个完好的时期。
确定上一个完好的时期时，系统将提示您确认要启动该完好时期所在日期的数据库。选择是 (Yes) 可继续恢复过程。

当心
如果您不想在上一个完好的时期启动，可改为从备份还原数据并尝试重新启动数据库。要使此操作有意义，备份必须比上一个完好的时期更新。

Vertica 继续初始化和恢复上一个完好的时期之前的所有数据。

如果恢复用时超过一分钟，则在出现“是否要继续等待? (Do you want to continue waiting?)”提示时，您需要回复 <是 (Yes)> 或 <否 (No)>。

当所有节点的状态均变为“正在恢复 (RECOVERING)”或“开启 (UP)”时，选择 <否 (No)> 可退出此屏幕并通过管理工具的“主菜单 (Main Menu)”监控进度。选择 <是 (Yes)> 可继续显示数据库恢复时段。

注意
请确保重新加载在所恢复到的上一个完好的时期所在日期之后添加的任何数据。

3 - 从备份中恢复群集

要从备份中恢复群集，请参考以下主题：

4 - 恢复阶段

无论您是按表恢复还是按节点恢复，Vertica 恢复的阶段都相同。如果是按表恢复，则在完成最后阶段后，各个表将分别变为可用。如果是按节点恢复，则数据库对象仅在整个节点完成恢复之后才可用。

在 Vertica 中执行恢复时，每个恢复的表都要完成以下阶段：

表完成最后一个阶段后，Vertica 认为它已完全恢复。此时，表可以参与 DDL 和 DML 操作。

5 - 时期

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

数据库恢复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)：包含历史查询可访问的数据的最旧时期。

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

5.1 - 时期生命周期

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

注意

根据您的配置，单个时期可以代表最新时期、上一个完好的时期、检查点时期和 Ancient History Mark。

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

当前时期 (CE)

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

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

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

查询 SYSTEM 系统表以返回当前时期：
```
=> SELECT CURRENT_EPOCH FROM SYSTEM;
 CURRENT_EPOCH
---------------
         71
(1 row)
```
当前时期是开放时期，这意味着它是您当前正在向其中写入数据的时期。

向 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)

提交数据，然后再次查询该表。提交的数据与时期 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)

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

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

检查点时期 (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 之前时期的所有已删除数据。有关自动或手动清除的详细信息，请参阅清除删除的数据。

5.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。

当心
您可以使用 MAKE_AHM_NOW、SET_AHM_EPOCH 或 SET_AHM_TIME 时期管理函数手动将 AHM 设置为特定时期。如果选择的时期晚于 DOWN 节点的 LGE，则节点必须在重启时从头开始恢复。

确认 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)

5.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 以根据需要手动清除已删除的数据。如果您需要更新或删除错误上传的数据，手动清除非常有用。有关详细信息，请参阅手动清除数据。

6 - 灾难恢复最佳实践

要防止数据库不受重大灾难引起的站点故障的影响，请保留数据库的异地副本备用。发生灾难时，可将数据库用户切换到备用数据库。发生灾难和故障转移到异地副本期间丢失的数据量取决于完整数据库备份的保存频率。

用于灾难恢复的解决方案取决于您必须为应用程序确定的两个因素：

恢复点目标 (RPO)：进行灾难恢复时，贵组织所容许的数据损失量是多少？
恢复时间目标 (RTO)： 灾难发生之后，您需要以多快的速度恢复数据库？

根据 RPO 和 RTO，Vertica 建议从以下解决方案中进行选择：

双负载： 在数据库的每个加载过程中，同时加载另一个数据库。可使用现成的 ETL 软件轻松实现此目的。
定期增量备份：使用将数据库复制到其他群集中描述的过程将数据定期复制到目标数据库。切记，脚本仅复制已发生更改的文件。
存储供应商提供的复制解决方案：尽管一些用户通过 SAN 存储取得了成功，但供应商的数量和可能的配置使 Vertica 无法为 SAN 提供支持。

下表汇总了 RPO、RTO 以及每个方法的优缺点：

7 - 按表恢复

Vertica 支持按表执行节点恢复。与基于节点的恢复不同，按表恢复可使表在恢复期间可用，无需等待节点自身完全还原。您可以优先恢复最重要的表，确保它们立即可用。恢复后的表可支持所有 DDL 和 DML 操作。

为了提高恢复速度，Vertica 会并行恢复多个表。一次可以恢复的最大表数由 RECOVERY 资源池中的 MAXCONCURRENCY 参数控制。

节点完全恢复后，它会启用完整 Vertica 功能。

7.1 - 确定表恢复的优先级

可以指定 Vertica 恢复表时所采用的顺序。此功能可确保最关键的表尽快处于可用状态。若要指定表的恢复顺序，请分配一个整数优先级值。首先恢复优先级值较高的表。例如，优先级为 1000 的表在优先级值为 500 的表之前恢复。表优先级的最大值为 64 位整数。

如果没有指定优先级，或多个表具有相同的优先级，则 Vertica 将按 OID 顺序还原表。使用查询分配优先级的方式如下：

=> SELECT set_table_recover_priority('avro_basic', '1000');
      set_table_recover_priority
---------------------------------------
 Table recovery priority has been set.
(1 row)

可使用以下格式通过一个查询查看所分配的优先级： SELECT table_name,recover_priority FROM v_catalog.tables; 下一个示例显示了 Vmart 示例数据库中已确定优先级的表。这种情况下，恢复优先级最高的表将列在最前面 (DESC)。shipping_dimension 表具有最高优先级，将最先恢复。（本示例为了便于显示，使用了硬式换行。）

=> SELECT table_name AS Name, recover_priority from v_catalog.tables WHERE recover_priority > 1
   ORDER BY recover_priority DESC;
        Name         | recover_priority
---------------------+------------------
 shipping_dimension  |            60000
 warehouse_dimension |            50000
 employee_dimension  |            40000
 vendor_dimension    |            30000
 date_dimension      |            20000
 promotion_dimension |            10000
 iris2               |             9999
 product_dimension   |               10
 customer_dimension  |               10
(9 rows)

7.2 - 查看表恢复状态

通过查询 V_MONITOR.TABLE_RECOVERY_STATUS 表，查看关于恢复操作的常规信息。通过查询 V_MONITOR.TABLE_RECOVERIES 表，您还可以查看关于正在还原表的恢复操作状态的详细信息。