故障恢复

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

节点故障对数据库的影响

数据库中出现故障节点会影响数据库的运行方式。如果企业模式数据库的 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 进程来恢复这些节点：

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

正常关闭后恢复

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

  1. 解决所有导致节点主机关闭的硬件或系统问题。

  2. 重新启动数据库。请参阅启动数据库。

重新启动时，在关闭之前状态为 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。

本节内容