运行管理工具 (Administration Tools)，选择高级菜单 (Advanced Menu)，然后单击确定 (OK)。
选择在主机上停止 Vertica (Stop Vertica on Host)，然后单击确定 (OK)。
选择要停止的主机，然后单击确定 (OK)。
返回主菜单，选择查看数据库群集状态 (View Database Cluster State)，然后单击确定 (OK)。您之前停止的主机应显示为 DOWN。
现在可执行维护工作。

有关在节点上重新启动 Vertica 的详细信息，请参阅在节点上重新启动 Vertica。

命令行

您可以使用命令行工具 stop_node 停止一个或多个节点上的 Vertica。stop_node 将一个或多个节点 IP 地址作为实参。例如，以下命令在两个节点上停止 Vertica：

$ admintools -t stop_node -s 192.0.2.1,192.0.2.2

1.2 - 在节点上重新启动 Vertica

在停止节点以执行维护任务（如升级硬件）之后，需要重新启动该节点才能重新连接数据库群集。

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

注意
此操作可能需要一些时间。
返回主菜单，选择查看数据库群集状态 (View Database Cluster State)，然后单击确定 (OK)。您重新启动的主机现在显示为 UP，如下图所示。

1.3 - 设置节点类型

创建节点时，Vertica 会自动将其类型设置为 PERMANENT。这使 Vertica 可以使用此节点来存储数据。您可以使用 ALTER NODE 将节点的类型更改为以下类型之一：

PERMANENT：（默认值）：存储数据的节点。
EPHEMERAL：从一种类型转换到另一种类型的节点——通常是从 PERMANENT 到 STANDBY 或 EXECUTE。
STANDBY：保留以在任何节点发生故障时替换该节点的节点。备用节点不存储段或数据，直到它被调用以替换故障节点。当用作替换节点时，Vertica 将其类型更改为 PERMANENT。有关详细信息，请参阅活动备用节点。
EXECUTE：该节点仅为计算目的而保留。执行节点不包含段或数据。

注意

仅 Enterprise 模式支持 STANDBY 和 EXECUTE 节点类型。

1.4 - 活动备用节点

活动备用节点是企业模式数据库中可用于替换任何故障节点的节点。与标准 Vertica 节点不同，备用节点不执行计算或包含数据。如果永久节点出现故障，那么在故障节点超过故障转移时间限制后，活动备用节点可以替换故障节点。替换故障节点后，活动备用节点包含投影并执行它所替换的节点的全部计算。

此部分内容

1.4.1 - 创建活动备用节点

可在创建数据库期间在企业模式数据库中创建活动备用节点，也可稍后创建此节点。

注意

创建活动备用节点时，请确保添加所有必需的存储位置。有关详细信息，请参考添加存储位置。

在新数据库中创建活动备用节点

创建数据库，包括要用作活动备用节点的节点。
使用 vsql 连接到一个并非您希望用作活动备用节点的节点。
使用 ALTER NODE 将此节点从永久节点转换为活动备用节点。例如：
```
=> ALTER NODE v_mart_node5 STANDBY;
```
在发出 ALTER NODE 语句后，受影响的节点会关闭并作为活动备用节点重新启动。

在现有数据库中创建活动备用节点

在创建要用作活动备用节点的节点时，应尽快将新节点更改为暂时状态，以防止群集将数据移动到新节点。

向数据库中添加节点。

重要
在此阶段不要重新平衡数据库。
使用 vsql 连接到任何其他节点。
使用 ALTER NODE 将新节点从永久节点转换为暂时节点。例如：
```
=> ALTER NODE v_mart_node5 EPHEMERAL;
```
重新平衡群集，以便移除暂时节点中的所有数据。
在暂时节点上使用 ALTER NODE 将该节点转换为活动备用节点。例如：
```
=> ALTER NODE v_mart_node5 STANDBY;
```

1.4.2 - 使用活动备用节点替换节点

企业模式数据库上的故障节点可以自动或手动替换为活动备用节点。

重要

节点必须处于关闭状态，之后才能使用活动备用节点替换它。尝试替换正常运行的节点会返回错误。

自动替换

您可以使用参数 FailoverToStandbyAfter 配置故障节点的自动替换。如果启用了此参数，它将指定活动备用节点等待多长时间后替换故障节点。如果可以，Vertica 将从故障节点所在的容错组中选择备用节点。否则，Vertica 将随机选择一个可用的活动备用节点。

手动替换

作为管理员，您可以使用 ALTER NODE 手动替换故障节点：

使用管理工具或 vsql 连接到数据库。
用 ALTER NODE...REPLACE 替换节点。REPLACE 选项可以指定备用节点。如果 REPLACE 未限定，则 Vertica 会从故障节点所在的容错组中选择一个备用节点（如果可用）；否则，它会随机选择一个可用的活动备用节点。

1.4.3 - 恢复活动备用节点

当企业模式数据库中的已关闭节点准备好重新激活时，您可以还原该节点，方法是将其替换节点恢复为备用状态。您可以使用 ALTER NODE 针对单个节点执行此操作，或使用 ALTER DATABASE 针对整个数据库执行此操作：

使用管理工具或通过 vsql 连接到数据库。
恢复备用节点。
- 使用 ALTER NODE 恢复单个节点：
```
ALTER NODE node‑name RESET;
```
- 使用 ALTER DATABASE 恢复整个数据库群集中的节点：
```
ALTER DATABASE DEFAULT RESET STANDBY;
```

如果关闭的节点无法恢复操作，Vertica 会忽略重置请求并将备用节点留在原地。

1.5 - 大型群集

Vertica 使用 Spread 服务在数据库节点之间广播控制消息。此服务可以限制 Vertica 数据库群集的增长。随着群集节点数量的增加，Spread 服务的负载也会随着更多参与者交换消息而增加。负载增加后会降低群集的整体性能。此外，网络寻址将 Spread 服务中参与者的最大数量限制为 120（通常要少得多）。在这种情况下，您可以使用大型群集来克服这些 Spread 限制。

启用大型群集后，名为控制节点的群集节点子集使用 Spread 服务交换消息。群集中的其他节点会分配给这些控制节点之一，并依赖它们进行群集范围的通信。每个控制节点将消息从 Spread 服务传递到它的依赖节点。当依赖节点需要向群集中的其他节点广播消息时，它将消息传递给其控制节点，控制节点又将消息发送到其他依赖节点以及 Spread 服务。

通过设置控制节点和其他节点之间的依赖关系，您可以增加数据库节点的总数，并使节点总数符合 Spread 限制（即 120 个节点）。

注意

从技术上讲，当禁用了大型群集时，群集中的所有节点都是控制节点。在这种情况下，所有节点都连接到 Spread 服务。启用大型群集后，一些节点将依赖于控制节点。

大型群集功能的一个缺点是，如果一个控制节点发生故障，它的依赖节点就会与数据库群集的其余部分断开。这些节点无法参与数据库活动，Vertica 也认为它们已关闭。当控制节点恢复时，它会在其依赖节点与数据库之间重新建立通信，因此所有节点都重新加入群集。

注意

Spread 服务守护进程在控制节点主机上作为独立进程运行。它不是 Vertica 进程的一部分。如果节点上的 Vertica 进程出现故障（例如，您使用 admintools 停止主机上的 Vertica 进程），Spread 服务将继续运行。只要 Spread 守护进程在控制节点上运行，该节点的依赖项就可以与数据库群集通信并参与数据库活动。通常，只有当控制节点的主机出现问题（例如，主机关闭、主机与网络断开连接或发生硬件故障）时，控制节点才会关闭。

大型群集和数据库增长

当您的数据库启用了大型群集时，Vertica 会决定是将新添加的节点设为控制节点还是依赖节点，如下所示：

在企业模式下，如果为数据库群集配置的控制节点数大于其包含的当前节点数，Vertica 会将新节点设为控制节点。在 Eon 模式下，在子群集级别设置控制节点的数量。如果为包含新节点的子群集设置的控制节点数小于此设置，Vertica 会将新节点设为控制节点。
如果企业模式群集或 Eon 模式子群集已达到其控制节点限制，则新节点将成为现有控制节点的依赖节点。

当新添加的节点为依赖节点时，Vertica 会自动将其分配给控制节点。Vertica 选择哪个控制节点由数据库模式引导：

企业模式数据库：Vertica 将新节点分配给具有最少依赖项的控制节点。如果您在数据库中创建了容错组，Vertica 会在与新节点相同的容错组中选择一个控制节点。此功能允许您使用容错组来组织控制节点及其依赖项，以反映底层主机硬件的物理布局。例如，您可能希望依赖节点与其控制节点位于同一机架中。否则，影响整个机架的故障（如电源故障）不仅会导致机架中的节点关闭，而且还会导致其他架构中其控制节点位于受影响机架中的节点关闭。有关详细信息，请参阅容错组。
Eon 模式数据库：Vertica 始终将新节点添加到子群集。Vertica 将新节点分配给该子群集中具有最少依赖节点的控制节点。启用了大型群集的 Eon 模式数据库中的每个子群集都至少有一个控制节点。将依赖节点与其控制节点保持在同一个子群集中可以保持子群集隔离。

重要

在 10.0.1 之前的 Vertica 版本中，对于启用了大型群集的 Eon 模式数据库中的节点，不一定会在其子群集中为其分配控制节点。如果您已从 10.0.1 之前的 Vertica 版本升级 Eon 模式数据库并启用了大型群集，请重新对齐数据库中的控制节点。此过程会重新分配依赖节点并修复任何跨子群集的控制节点依赖项。有关详细信息，请参阅重新对齐控制节点和重新加载 spread。

当将子群集添加到 Eon Mode 数据库时，Spread 服务的上限（120 名参与者）可能会导致错误。如果您的数据库群集有 120 个控制节点，则尝试创建子群集会失败并出现错误。每个子群集必须至少有一个控制节点。当您的群集有 120 个控制节点时，Vertica 无法为新的子群集创建控制节点。如果发生此错误，您必须在添加子群集之前减少数据库群集中的控制节点数量。

何时启用大型群集

Vertica 在以下两种情况下自动启用大型群集：

数据库群集包含 120 个或更多节点。对于企业模式和 Eon 模式都是如此。
您创建一个包含 16 个或更多初始节点的 Eon 模式子群集（主要子群集或一个辅助子群集）。

如果您通过向现有子群集添加节点来将其扩展到 16 个或更多节点，Vertica 不会自动启用大型群集。

注意
您可以通过将 control-set-size 参数设置为 -1 来防止 Vertica 在您创建具有 16 个或更多节点的子群集时自动启用大型群集。有关详细信息，请参阅创建子群集。

您可以选择在 Vertica 自动启用大型群集之前手动启用大型群集模式。您的最佳做法是在数据库群集大小达到阈值时启用大型群集：

对于基于云的数据库，当群集包含 16 个或更多节点时启用大型群集。在云环境中，您的数据库使用点对点网络通信。在点对点通信模式下，Spread 服务的缩放性很差。当数据库群集达到 16 个节点时启用大型群集有助于限制因 Spread 服务处于点对点模式而造成的影响。
对于内部部署数据库，当群集包含 50 到 80 个节点时启用大型群集。在内部部署环境中，Spread 服务的缩放性较好。但是，当群集达到 50 到 80 个节点时，Spread 服务可能会开始出现性能问题。

在云或内部部署环境中，如果您开始注意到与 Spread 相关的性能问题，请启用大型群集。Spread 性能问题的症状包括：

Spread 服务上的负载开始导致性能问题。因为 Vertica 将 Spread 服务用于群集范围的控制消息，所以 Spread 性能问题会对数据库性能产生不利影响。对于基于云的数据库尤其如此，由于云基础架构中网络广播的性质，Spread 性能问题很快成为瓶颈。在内部部署数据库中，广播消息通常不太受关注，因为消息通常保留在本地子网中。即便如此，在群集达到 120 个节点时，在 Vertica 自动启用大型群集之前，Spread 问题通常会成为瓶颈。
群集中地址的压缩列表太大，无法放入最大传输单元 (MTU) 数据包（1478 字节）。MTU 数据包必须包含参与 Spread 服务的节点的所有地址。在理想情况下（当节点的 IP 地址为 1.1.1.1、1.1.1.2 等时），此数据包中可以容纳 120 个地址。这就是为什么当数据库群集达到 120 个节点时，Vertica 会自动启用大型群集。实际上，IP 地址的压缩列表将在 50 到 80 个节点处达到 MTU 数据包大小限制。

1.5.1 - 计划大型群集

在计划将数据库群集扩展到需要使用大型群集的程度时，您应该考虑两个因素：

数据库群集应该有多少个控制节点？
这些控制节点应该如何分布？

确定控制节点的数量

当您手动启用大型群集或添加足够的节点触发 Vertica 自动启用大型群集时，一部分群集节点将成为控制节点。在少于 16 个节点的子群集中，所有节点都是控制节点。在许多情况下，可以将控制节点数设置为整个企业模式群集中或超过 16 个节点的 Eon 模式子群集中节点总数的平方根。但是，这个计算控制数量的公式不能保证总是能满足您的要求。

在选择数据库群集中控制节点的数量时，您必须平衡两个相互竞争的考虑因素：

如果控制节点发生故障或关闭，所有依赖于它的节点都将从数据库中断开。它们也会一直关闭到控制节点重新加入数据库。您可以通过增加群集中控制节点的数量来减少控制节点故障所带来的影响。
群集中的控制节点越多，spread 服务的负载就越大。在云环境中，网络环境广播越复杂，延迟时间越长。这种延迟可能会导致通过 spread 服务发送的消息需要更长的时间才能到达群集中的所有节点。

在云环境中，经验表明，16 个控制节点可以平衡可靠性和性能的需求。在 Eon 模式数据库中，每个子群集必须至少有一个控制节点。因此，如果您有 16 个以上子群集，则必须有 16 个以上控制节点。

在 Eon 模式数据库中，无论是内部部署数据库还是云中数据库，都要考虑向主子群集中添加比辅助子群集更多的控制节点。在 Eon 模式数据库中，只有主子群集中的节点才负责维护 K-Safety。因此，与辅助子群集中的控制节点故障相比，主子群集中的控制节点故障对数据库的影响可能更大。

在内部部署企业模式数据库中，在选择控制节点的数量时，请考虑运行数据库的主机的物理布局。如果您的主机分布在多个服务器机架上，则需要有足够的控制节点将它们分发到各个机架上。分发控制节点有助于确保在发生涉及整个机架的故障（如电源或网络交换机故障）时实现可靠性。您可以将数据库配置为没有节点依赖某个单独机架中的控制节点。将依赖性限制在机架内可防止在出现会影响整个机架的故障时，由于控制节点丢失而导致在机架外出现额外的节点丢失。

根据物理布局选择控制节点的数量还可以降低跨交换机的网络流量。通过将依赖节点放在与其控制节点相同的机架上，会使它们之间的通信保留在机架中，而不是通过网络交换机进行通信。

您可能需要增加控制节点的数量以将它们均匀地分布在各个机架上。例如，内部部署企业模式数据库共有 64 个节点，分布在三个机架上。对于此群集，对节点数求平方根将得到 8 个控制节点。但是，八个控制节点无法均匀地分布在三个机架中。相反，您可以有 9 个控制节点，并在每个机架上平均分布三个控制节点。

影响控制节点放置

在确定群集的节点数后，需要确定如何在群集节点之间分布它们。Vertica 选择哪些节点成为控制节点。您可以影响 Vertica 如何选择控制节点以及哪些节点成为其依赖项。您使用的确切过程取决于数据库的模式：

企业模式内部部署数据库：定义容错组以影响控制节点的放置。依赖节点始终与其控制节点位于同一容错组中。您通常定义容错组来反映运行数据库的主机的物理布局。例如，您通常为单机架服务器中的节点定义一个或多个容错组。当容错组反映物理布局时，Vertica 会以可限制机架故障所带来影响的方式放置控制节点及其依赖项。有关详细信息，请参阅容错组。
Eon 模式数据库：使用子群集对控制节点的放置进行控制。每个子群集必须至少有一个控制节点。依赖节点始终与其控制节点位于同一个子群集中。您可以设置每个子群集的控制节点数。这样做可以让您将更多控制节点分配给主子群集，在这些子群集中，将控制节点发生故障的影响降至最低至关重要。

Vertica 如何选择默认控制节点数

Vertica 可以自动选择整个群集（在企业模式下）或子群集（在 Eon 模式下）的控制节点数。它在以下情况下设置默认值：

当您将 default 关键字传递给 install_vertica 脚本的 --large-cluster 选项时（请参阅安装 Vertica 时启用大型群集）。
当数据库群集增长到 120 个或更多节点时，Vertica 会自动启用大型群集。
如果您创建超过 16 个节点的 Eon 模式子群集，Vertica 会自动启用大型群集。请注意，对于通过扩展超过 16 节点限制的子群集，Vertica 不会启用大型群集。它仅在一开始便超过 16 个节点时启用大型群集。

Vertica 选择的控制节点数取决于触发 Vertica 设置该值的原因。

如果您将 --large-cluster default 选项传递给 install_vertica 脚本，Vertica 会将控制节点数设置为初始群集中节点数的平方根。

如果数据库群集达到 120 个节点，Vertica 会通过将任何新添加的节点设为依赖项来启用大型群集。默认的控制节点数限值为 120。当达到此限制时，任何新添加的节点都将添加为依赖项。例如，假设您有一个包含 115 个节点的企业模式数据库群集，但您没有针对该群集手动启用大型群集。如果您向此群集中添加 10 个节点，Vertica 会添加 5 个节点作为控制节点（使您达到 120 个节点的限制），另外 5 个节点作为依赖项。

重要

您应该在数据库达到 120 个节点之前手动启用大型群集。

在 Eon 模式数据库中，每个子群集都有自己的控制节点数设置。Vertica 仅在您最初创建超过 16 个节点的子群集时自动设置控制节点的数量。在发生这种情况时，Vertica 会将子群集的控制节点数设置为子群集中节点数的平方根。

例如，假设您添加一个包含 25 个节点的新子群集。此子群集的节点数一开始便超过 16 个节点数限制，因此 Vertica 将此子群集的控制节点数设置为 5（即 25 的平方根）。其中五个节点被添加为控制节点，其余 20 个被添加为这五个节点的依赖项。

尽管每个子群集都有自己的控制节点数设置，但 Eon 模式数据库群集的控制节点总数仍然有 120 个节点的限制。

1.5.2 - 启用大型群集

在以下情况下，Vertica 自动启用大型群集功能：

数据库群集中的节点总数超过 120。
创建的 Eon 模式子群集包含 16 个以上节点。

在大多数情况下，您应该考虑在群集大小达到这些阈值中的任何一个之前手动启用大型群集。有关何时启用大型群集的指南，请参阅计划大型群集。

您可以针对新 Vertica 数据库或现有数据库启用大型群集。

安装 Vertica 时启用大型群集

您可以在将 Vertica 安装到新数据库群集时启用大型群集。如果您从一开始就知道大型群集会对您的数据库带来好处，则这种选择非常有用。

在安装过程中，install_vertica 脚本的 ‑‑large‑cluster 实参启用大型群集。它采用 1 到 120 之间的单个整数值，该值指定要在新数据库群集中创建的控制节点的数量。或者，此选项可以采用字面量实参 default。在这种情况下，Vertica 启用大型群集模式并将控制节点的数量设置为您在 ‑‑hosts 实参中提供的节点数的平方根。例如，如果 ‑‑hosts 指定 25 个主机并且 ‑‑large‑cluster 设置为 default，则安装脚本会创建一个具有 5 个控制节点的数据库群集.

‑‑large‑cluster 实参的作用略有不同，具体取决于您在创建数据库时选择的数据库模式：

企业模式： ‑‑large‑cluster 设置整个数据库群集的控制节点总数。
Eon 模式： ‑‑large‑cluster 设置初始默认子群集中的控制节点数。此设置对您稍后创建的子群集不起作用。

注意

您不能使用 ‑‑large‑cluster 将初始数据库中的控制节点数设置为高于您在 ‑‑hosts 实参中传递的主机数。安装程序将控制节点的数量设置为以下两个值中的较小值：传递给 ‑‑large‑cluster 选项的值或 ‑‑hosts 选项中的主机数。

您可以使用元函数 SET_CONTROL_SET_SIZE 将控制节点数设置为高于现有数据库中的当前节点数。在计划未来扩展时，您可以选择设置更大的数量来预分配控制节点。有关详细信息，请参阅更改控制节点的数量并重新对齐。

安装过程完成后，请使用管理工具或管理控制台创建数据库。有关详细信息，请参阅创建空数据库。

对于在企业模式下运行的内部部署数据库，通常需要定义可反映主机物理布局的容错组。它们让您可以定义哪些主机位于相同的服务器机架中，并且依赖于相同的基础架构（例如电源和网络交换机）。掌握了这些情况，Vertica 可以重新对齐控制节点，使您的数据库能够更好地应对硬件故障。有关详细信息，请参阅容错组。

创建数据库后，默认情况下，您添加的任何节点都是依赖节点。可以使用元函数 SET_CONTROL_SET_SIZE 更改数据库中的控制节点数。

在现有数据库中启用大型群集

您可以在现有数据库中手动启用大型群集。通常，您会选择在数据库达到 Vertica 自动启用大型群集的点之前手动启用大型群集。请参阅何时启用大型群集，了解何时应该考虑启用大型群集。

使用元函数 SET_CONTROL_SET_SIZE 启用大型群集并设置控制节点数。您向此函数传递一个整数值，该值设置整个企业模式群集或 Eon 模式子群集中的控制节点数。

1.5.3 - 更改控制节点的数量并重新对齐

在企业模式下，可以更改整个数据库群集中控制节点的数量，或者在 Eon 模式下可以更改子群集中控制节点的数量。您可以选择更改群集或子群集中控制节点的数量，以减少控制节点丢失对数据库的影响。请参阅计划大型群集了解有关何时应更改数据库中控制节点数量的详细信息。

可以通过调用元函数 SET_CONTROL_SET_SIZE 来更改控制节点的数量。如果在调用 SET_CONTROL_SET_SIZE 之前未启用大型群集，则该函数会在您的数据库中启用大型群集。有关详细信息，请参阅启用大型群集。

在企业模式数据库中调用 SET_CONTROL_SET_SIZE 时，它会设置整个数据库群集中控制节点的数量。在 Eon 模式数据库中，除了提供控制节点的数量之外，还必须为 SET_CONTROL_SET_SIZE 提供一个子群集的名称。该函数设置该子群集的控制节点数。数据库群集中的其他子群集不受此调用的影响。

在更改 Eon 模式子群集中的控制节点数量之前，请验证该子群集是否正在运行。如果在子群集关闭时更改其控制节点的数量，可能会导致配置问题，从而阻止子群集中的节点启动。

注意

您可以将控制节点数设置为高于群集或子群集中当前节点数的值。当控制节点数大于当前节点数时，新增节点成为控制节点，直到群集或子群集中的节点数达到您设置的控制节点数。

您可以选择将控制节点数设置为高于当前节点数，以计划未来的扩展。例如，假设您在 Eon 模式数据库中有一个 4 节点子群集，计划在将来扩展。您确定要将此群集中的控制节点数限制到 8 个，即使您将其扩展至超出该大小也是如此。在这种情况下，您现在可以选择将子群集的控制节点大小设置为 8。当您向该子群集添加新节点时，新节点将成为控制节点，直到子群集的大小达到 8 个。之后，Vertica 将新添加的节点分配为子群集中现有控制节点的依赖项。

重新对齐控制节点并重新加载 spread

调用 SET_CONTROL_SET_SIZE 函数后，必须执行多个其他步骤才能使新设置生效。

重要

如果您已从 10.0.1 之前的版本升级已启用大型群集的 Eon 模式数据库，请按照以下步骤操作。Vertica 的早期版本并未将控制节点分配限制在同一子群集内。在升级后重新对齐控制节点时，Vertica 会将每个子群集配置为至少具有一个控制节点，并将节点分配给它们自己子群集中的一个控制节点。

调用 REALIGN_CONTROL_NODES 函数。此函数告诉 Vertica 重新评估群集或子群集中控制节点及其依赖项的分配。在 Eon 模式数据库中调用此函数时，必须提供在其中更改控制节点设置的子群集的名称。
调用 RELOAD_SPREAD 函数。此函数更新配置文件中的控制节点分配信息，并触发 Spread 重新加载。
重新启动受控制节点变更影响的节点。在企业模式数据库中，必须重新启动整个数据库，才能确保所有节点都已更新配置信息。在 Eon 模式下，重新启动受变更影响的一个或多个子群集。如果您更改了关键子群集（例如唯一的主子群集），则必须重新启动整个 Eon 模式数据库。

注意
如果前面的步骤没有更改控制节点分配，则不需要重新启动节点。通常，只有当 Eon 模式子群集中的控制节点数设置为高于子群集的当前节点数并且子群集中的所有节点都已经是控制节点时，才会发生这种情况。在这种情况下，不会添加或移除任何控制节点，因此节点依赖项不会发生更改。因为依赖项没有发生更改，所以节点不需要重新加载 Spread 配置。
在企业模式数据库中，调用 START_REBALANCE_CLUSTER() 来重新平衡群集。此过程会转移伙伴实例投影分配以限制控制节点故障所带来的影响，从而提高数据库的容错能力。在 Eon 模式数据库中无需执行此步骤。

企业模式示例

以下示例将企业模式数据库中 8 个节点中的 4 个节点设置为控制节点。它查询 LARGE_CLUSTER_CONFIGURATION_STATUS 系统表，该表显示数据库中每个节点的控制节点分配情况。一开始，所有节点都是自己的控制节点。有关与大型群集关联的系统表的详细信息，请参阅监控大型群集。

=> SELECT * FROM V_CATALOG.LARGE_CLUSTER_CONFIGURATION_STATUS;
    node_name     | spread_host_name | control_node_name
------------------+------------------+-------------------
 v_vmart_node0001 | v_vmart_node0001 | v_vmart_node0001
 v_vmart_node0002 | v_vmart_node0002 | v_vmart_node0002
 v_vmart_node0003 | v_vmart_node0003 | v_vmart_node0003
 v_vmart_node0004 | v_vmart_node0004 | v_vmart_node0004
 v_vmart_node0005 | v_vmart_node0005 | v_vmart_node0005
 v_vmart_node0006 | v_vmart_node0006 | v_vmart_node0006
 v_vmart_node0007 | v_vmart_node0007 | v_vmart_node0007
 v_vmart_node0008 | v_vmart_node0008 | v_vmart_node0008
(8 rows)

=> SELECT SET_CONTROL_SET_SIZE(4);
 SET_CONTROL_SET_SIZE
----------------------
 Control size set
(1 row)

=> SELECT REALIGN_CONTROL_NODES();
                       REALIGN_CONTROL_NODES
---------------------------------------------------------------
 The new control node assignments can be viewed in vs_nodes.
 Check vs_cluster_layout to see the proposed new layout. Reboot
 all the nodes and call rebalance_cluster now

(1 row)

=> SELECT RELOAD_SPREAD(true);
 RELOAD_SPREAD
---------------
 Reloaded
(1 row)

=> SELECT SHUTDOWN();

重新启动数据库后，最后一步是重新平衡群集并查询 LARGE_CLUSTER_CONFIGURATION_STATUS 表以查看当前的控制节点分配情况：

=> SELECT START_REBALANCE_CLUSTER();
 START_REBALANCE_CLUSTER
-------------------------
 REBALANCING
(1 row)

=> SELECT * FROM V_CATALOG.LARGE_CLUSTER_CONFIGURATION_STATUS;
    node_name     | spread_host_name | control_node_name
------------------+------------------+-------------------
 v_vmart_node0001 | v_vmart_node0001 | v_vmart_node0001
 v_vmart_node0002 | v_vmart_node0002 | v_vmart_node0002
 v_vmart_node0003 | v_vmart_node0003 | v_vmart_node0003
 v_vmart_node0004 | v_vmart_node0004 | v_vmart_node0004
 v_vmart_node0005 | v_vmart_node0001 | v_vmart_node0001
 v_vmart_node0006 | v_vmart_node0002 | v_vmart_node0002
 v_vmart_node0007 | v_vmart_node0003 | v_vmart_node0003
 v_vmart_node0008 | v_vmart_node0004 | v_vmart_node0004
(8 rows)

Eon 模式示例

以下示例在名为 analytics 的 8 节点辅助子群集中配置 4 个控制节点。主子群集未发生更改。此示例与前面的企业模式示例的主要区别在于：调用 SET_CONTROL_SET_SIZE 时需要指定子群集，不必重新启动整个数据库，也不必调用 START_REBALANCE_CLUSTER。

=>  SELECT * FROM V_CATALOG.LARGE_CLUSTER_CONFIGURATION_STATUS;
      node_name       |   spread_host_name   |  control_node_name
----------------------+----------------------+----------------------
 v_verticadb_node0001 | v_verticadb_node0001 | v_verticadb_node0001
 v_verticadb_node0002 | v_verticadb_node0002 | v_verticadb_node0002
 v_verticadb_node0003 | v_verticadb_node0003 | v_verticadb_node0003
 v_verticadb_node0004 | v_verticadb_node0004 | v_verticadb_node0004
 v_verticadb_node0005 | v_verticadb_node0005 | v_verticadb_node0005
 v_verticadb_node0006 | v_verticadb_node0006 | v_verticadb_node0006
 v_verticadb_node0007 | v_verticadb_node0007 | v_verticadb_node0007
 v_verticadb_node0008 | v_verticadb_node0008 | v_verticadb_node0008
 v_verticadb_node0009 | v_verticadb_node0009 | v_verticadb_node0009
 v_verticadb_node0010 | v_verticadb_node0010 | v_verticadb_node0010
 v_verticadb_node0011 | v_verticadb_node0011 | v_verticadb_node0011
(11 rows)


=> SELECT subcluster_name,node_name,is_primary,control_set_size FROM
   V_CATALOG.SUBCLUSTERS;
  subcluster_name   |      node_name       | is_primary | control_set_size
--------------------+----------------------+------------+------------------
 default_subcluster | v_verticadb_node0001 | t          |               -1
 default_subcluster | v_verticadb_node0002 | t          |               -1
 default_subcluster | v_verticadb_node0003 | t          |               -1
 analytics          | v_verticadb_node0004 | f          |               -1
 analytics          | v_verticadb_node0005 | f          |               -1
 analytics          | v_verticadb_node0006 | f          |               -1
 analytics          | v_verticadb_node0007 | f          |               -1
 analytics          | v_verticadb_node0008 | f          |               -1
 analytics          | v_verticadb_node0009 | f          |               -1
 analytics          | v_verticadb_node0010 | f          |               -1
 analytics          | v_verticadb_node0011 | f          |               -1
(11 rows)

=> SELECT SET_CONTROL_SET_SIZE('analytics',4);
 SET_CONTROL_SET_SIZE
----------------------
 Control size set
(1 row)

=> SELECT REALIGN_CONTROL_NODES('analytics');
                      REALIGN_CONTROL_NODES
-----------------------------------------------------------------------------
 The new control node assignments can be viewed in vs_nodes. Call
reload_spread(true). If the subcluster is critical, restart the database.
Otherwise, restart the subcluster

(1 row)

=> SELECT RELOAD_SPREAD(true);
 RELOAD_SPREAD
---------------
 Reloaded
(1 row)

此时，需要重新启动 analytics 子群集。可通过几个选项重新启动它。有关详细信息，请参阅启动和停止子群集。以下示例使用 admintools 命令行停止和启动子群集。

$ admintools -t stop_subcluster -d verticadb -c analytics -p password
*** Forcing subcluster shutdown ***
Verifying subcluster 'analytics'
    Node 'v_verticadb_node0004' will shutdown
    Node 'v_verticadb_node0005' will shutdown
    Node 'v_verticadb_node0006' will shutdown
    Node 'v_verticadb_node0007' will shutdown
    Node 'v_verticadb_node0008' will shutdown
    Node 'v_verticadb_node0009' will shutdown
    Node 'v_verticadb_node0010' will shutdown
    Node 'v_verticadb_node0011' will shutdown
Shutdown subcluster command successfully sent to the database

$ admintools -t restart_subcluster -d verticadb -c analytics -p password
*** Restarting subcluster for database verticadb ***
    Restarting host [10.11.12.19] with catalog [v_verticadb_node0004_catalog]
    Restarting host [10.11.12.196] with catalog [v_verticadb_node0005_catalog]
    Restarting host [10.11.12.51] with catalog [v_verticadb_node0006_catalog]
    Restarting host [10.11.12.236] with catalog [v_verticadb_node0007_catalog]
    Restarting host [10.11.12.103] with catalog [v_verticadb_node0008_catalog]
    Restarting host [10.11.12.185] with catalog [v_verticadb_node0009_catalog]
    Restarting host [10.11.12.80] with catalog [v_verticadb_node0010_catalog]
    Restarting host [10.11.12.47] with catalog [v_verticadb_node0011_catalog]
    Issuing multi-node restart
    Starting nodes:
        v_verticadb_node0004 (10.11.12.19) [CONTROL]
        v_verticadb_node0005 (10.11.12.196) [CONTROL]
        v_verticadb_node0006 (10.11.12.51) [CONTROL]
        v_verticadb_node0007 (10.11.12.236) [CONTROL]
        v_verticadb_node0008 (10.11.12.103)
        v_verticadb_node0009 (10.11.12.185)
        v_verticadb_node0010 (10.11.12.80)
        v_verticadb_node0011 (10.11.12.47)
    Starting Vertica on all nodes. Please wait, databases with a large catalog may take a while to initialize.
    Node Status: v_verticadb_node0004: (DOWN) v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
                     v_verticadb_node0007: (DOWN) v_verticadb_node0008: (DOWN) v_verticadb_node0009: (DOWN)
                     v_verticadb_node0010: (DOWN) v_verticadb_node0011: (DOWN)
    Node Status: v_verticadb_node0004: (DOWN) v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
                     v_verticadb_node0007: (DOWN) v_verticadb_node0008: (DOWN) v_verticadb_node0009: (DOWN)
                     v_verticadb_node0010: (DOWN) v_verticadb_node0011: (DOWN)
    Node Status: v_verticadb_node0004: (INITIALIZING) v_verticadb_node0005: (INITIALIZING) v_verticadb_node0006:
                     (INITIALIZING) v_verticadb_node0007: (INITIALIZING) v_verticadb_node0008: (INITIALIZING)
                     v_verticadb_node0009: (INITIALIZING) v_verticadb_node0010: (INITIALIZING) v_verticadb_node0011: (INITIALIZING)
    Node Status: v_verticadb_node0004: (UP) v_verticadb_node0005: (UP) v_verticadb_node0006: (UP)
                     v_verticadb_node0007: (UP) v_verticadb_node0008: (UP) v_verticadb_node0009: (UP)
                     v_verticadb_node0010: (UP) v_verticadb_node0011: (UP)
Syncing catalog on verticadb with 2000 attempts.

子群集重新启动后，可以查询系统表以查看控制节点配置：

=>  SELECT * FROM V_CATALOG.LARGE_CLUSTER_CONFIGURATION_STATUS;
      node_name       |   spread_host_name   |  control_node_name
----------------------+----------------------+----------------------
 v_verticadb_node0001 | v_verticadb_node0001 | v_verticadb_node0001
 v_verticadb_node0002 | v_verticadb_node0002 | v_verticadb_node0002
 v_verticadb_node0003 | v_verticadb_node0003 | v_verticadb_node0003
 v_verticadb_node0004 | v_verticadb_node0004 | v_verticadb_node0004
 v_verticadb_node0005 | v_verticadb_node0005 | v_verticadb_node0005
 v_verticadb_node0006 | v_verticadb_node0006 | v_verticadb_node0006
 v_verticadb_node0007 | v_verticadb_node0007 | v_verticadb_node0007
 v_verticadb_node0008 | v_verticadb_node0004 | v_verticadb_node0004
 v_verticadb_node0009 | v_verticadb_node0005 | v_verticadb_node0005
 v_verticadb_node0010 | v_verticadb_node0006 | v_verticadb_node0006
 v_verticadb_node0011 | v_verticadb_node0007 | v_verticadb_node0007
(11 rows)

=> SELECT subcluster_name,node_name,is_primary,control_set_size FROM subclusters;
  subcluster_name   |      node_name       | is_primary | control_set_size
--------------------+----------------------+------------+------------------
 default_subcluster | v_verticadb_node0001 | t          |               -1
 default_subcluster | v_verticadb_node0002 | t          |               -1
 default_subcluster | v_verticadb_node0003 | t          |               -1
 analytics          | v_verticadb_node0004 | f          |                4
 analytics          | v_verticadb_node0005 | f          |                4
 analytics          | v_verticadb_node0006 | f          |                4
 analytics          | v_verticadb_node0007 | f          |                4
 analytics          | v_verticadb_node0008 | f          |                4
 analytics          | v_verticadb_node0009 | f          |                4
 analytics          | v_verticadb_node0010 | f          |                4
 analytics          | v_verticadb_node0011 | f          |                4
(11 rows)

禁用大型群集

要禁用大型群集，请调用值为 -1 的 SET_CONTROL_SET_SIZE。该值是非大型群集数据库的默认值。它通知 Vertica 将所有节点设为控制节点。

在 Eon 模式数据库中，为了完全禁用大型群集，必须在每个具有设定控制节点数的子群集中将控制节点数设置为 -1。可以通过查询 V_CATALOG.SUBCLUSTERS 系统表的 CONTROL_SET_SIZE 列来查看哪些子群集具有设定数量的控制节点。

以下示例重置在前面的 Eon 模式示例中设置的控制节点数。

=> SELECT subcluster_name,node_name,is_primary,control_set_size FROM subclusters;
  subcluster_name   |      node_name       | is_primary | control_set_size
--------------------+----------------------+------------+------------------
 default_subcluster | v_verticadb_node0001 | t          |               -1
 default_subcluster | v_verticadb_node0002 | t          |               -1
 default_subcluster | v_verticadb_node0003 | t          |               -1
 analytics          | v_verticadb_node0004 | f          |                4
 analytics          | v_verticadb_node0005 | f          |                4
 analytics          | v_verticadb_node0006 | f          |                4
 analytics          | v_verticadb_node0007 | f          |                4
 analytics          | v_verticadb_node0008 | f          |                4
 analytics          | v_verticadb_node0009 | f          |                4
 analytics          | v_verticadb_node0010 | f          |                4
 analytics          | v_verticadb_node0011 | f          |                4
(11 rows)



=> SELECT SET_CONTROL_SET_SIZE('analytics',-1);
 SET_CONTROL_SET_SIZE
----------------------
 Control size set
(1 row)

=> SELECT REALIGN_CONTROL_NODES('analytics');
                       REALIGN_CONTROL_NODES
---------------------------------------------------------------------------------------
 The new control node assignments can be viewed in vs_nodes. Call reload_spread(true).
 If the subcluster is critical, restart the database. Otherwise, restart the subcluster

(1 row)

=> SELECT RELOAD_SPREAD(true);
 RELOAD_SPREAD
---------------
 Reloaded
(1 row)

-- After restarting the analytics subcluster...

=> SELECT * FROM V_CATALOG.LARGE_CLUSTER_CONFIGURATION_STATUS;
      node_name       |   spread_host_name   |  control_node_name
----------------------+----------------------+----------------------
 v_verticadb_node0001 | v_verticadb_node0001 | v_verticadb_node0001
 v_verticadb_node0002 | v_verticadb_node0002 | v_verticadb_node0002
 v_verticadb_node0003 | v_verticadb_node0003 | v_verticadb_node0003
 v_verticadb_node0004 | v_verticadb_node0004 | v_verticadb_node0004
 v_verticadb_node0005 | v_verticadb_node0005 | v_verticadb_node0005
 v_verticadb_node0006 | v_verticadb_node0006 | v_verticadb_node0006
 v_verticadb_node0007 | v_verticadb_node0007 | v_verticadb_node0007
 v_verticadb_node0008 | v_verticadb_node0008 | v_verticadb_node0008
 v_verticadb_node0009 | v_verticadb_node0009 | v_verticadb_node0009
 v_verticadb_node0010 | v_verticadb_node0010 | v_verticadb_node0010
 v_verticadb_node0011 | v_verticadb_node0011 | v_verticadb_node0011
(11 rows)

=> SELECT subcluster_name,node_name,is_primary,control_set_size FROM subclusters;
  subcluster_name   |      node_name       | is_primary | control_set_size
--------------------+----------------------+------------+------------------
 default_subcluster | v_verticadb_node0001 | t          |               -1
 default_subcluster | v_verticadb_node0002 | t          |               -1
 default_subcluster | v_verticadb_node0003 | t          |               -1
 analytics          | v_verticadb_node0004 | f          |               -1
 analytics          | v_verticadb_node0005 | f          |               -1
 analytics          | v_verticadb_node0006 | f          |               -1
 analytics          | v_verticadb_node0007 | f          |               -1
 analytics          | v_verticadb_node0008 | f          |               -1
 analytics          | v_verticadb_node0009 | f          |               -1
 analytics          | v_verticadb_node0010 | f          |               -1
 analytics          | v_verticadb_node0011 | f          |               -1
(11 rows)

1.5.4 - 监控大型群集

通过查询以下系统表来监控大型群集的特征：

V_CATALOG.LARGE_CLUSTER_CONFIGURATION_STATUS — 显示编录中的当前 spread 主机和控制目标，以便查看它们是否匹配。
V_MONITOR.CRITICAL_HOSTS — 列出故障可能会导致数据库不安全并强制关机的主机。

提示
对于大型群集排列，CRITICAL_HOSTS 视图尤其有用。对于非大型群集，请查询 CRITICAL_NODES 表。
在 Eon 模式数据库中，V_CATALOG.SUBCLUSTERS 系统表的 CONTROL_SET_SIZE 列显示为每个子群集设置的控制节点数。

您可能还要查询以下系统表：

V_CATALOG.FAULT_GROUPS — 显示容错组及其在群集中的层次结构。
V_CATALOG.CLUSTER_LAYOUT — 显示参与数据库群集的节点和影响这些节点的容错组的实际排列的相对位置。

1.6 - 容错组

注意

您不能为 Eon 模式数据库创建容错组。相反，Vertica 会自动在大型 Eon 群集数据库上创建容错组；这些容错组围绕每个子群集的控制节点及其依赖项进行配置。这些容错组由 Vertica 内部管理，无法供用户访问。

容错组允许您为物理群集布局配置企业模式数据库。共享您的群集拓扑让您可以使用 Terrace 路由来减少大型查询的缓冲区要求。它还有助于最大限度地降低环境中固有的相关故障所带来的风险，这些故障通常由共享资源引起。

Vertica 将在大型群集排列中的控制节点（运行 spread 的服务器）周围自动创建容错组，将共享控制节点的节点放在同一容错组中。自动容错组和用户定义的容错组不包括暂时节点，因为类似的节点不容纳数据。

如果要执行以下操作，请考虑定义您自己的特定于群集物理布局的容错组：

使用 Terrace 路由来减少大型查询的缓冲区要求。
降低相关故障的风险。例如，通过定义机架布局，Vertica 对故障的容忍度更高。
影响控制节点在群集中的放置。

Vertica 支持使用具有不同形状和大小的复杂、层次结构容错组。数据库平台提供容错组脚本（DDL 生成器）、SQL 语句、系统表和其他监控工具。

有关包含群集拓扑示例的容错组的概述，请参阅使用容错组的高可用性。

1.6.1 - 关于容错组脚本

为了帮助您定义群集的容错组，Vertica 在 /opt/vertica/scripts 目录中提供了一个名为 fault_group_ddl_generator.py 的脚本。您需要利用此脚本生成的 SQL 语句来创建容错组。

fault_group_ddl_generator.py 脚本不会为您创建容错组，但您可以将输出复制到文件中。然后，当您运行帮助脚本时，可以使用 \i或 vsql–f 命令来将群集拓扑传递到 Vertica。

容错组脚本采用以下实参：

数据库名称
容错组输入文件名

例如：

$ python /opt/vertica/scripts/fault_group_ddl_generator.py VMartdb fault_grp_input.out

另请参阅

1.6.2 - 创建容错组输入文件

使用文本编辑器，为目标群集创建容错组输入文件。

以下示例显示如何为具有 8 个机架且每个机架上有 8 个节点的群集创建容错组输入文件，群集中总共有 64 个节点。

在文件的第一行，列出父（顶级）容错组，以空格分隔。
```
rack1 rack2 rack3 rack4 rack5 rack6 rack7 rack8
```

在随后的行中，列出父容错组，后跟等号 (=)。在等号之后，列出以空格分隔的节点或容错组。

<parent> = <child_1> <child_2> <child_n...>

如：

rack1 = v_vmart_node0001 v_vmart_node0002 v_vmart_node0003 v_vmart_node0004
rack2 = v_vmart_node0005 v_vmart_node0006 v_vmart_node0007 v_vmart_node0008
rack3 = v_vmart_node0009 v_vmart_node0010 v_vmart_node0011 v_vmart_node0012
rack4 = v_vmart_node0013 v_vmart_node0014 v_vmart_node0015 v_vmart_node0016
rack5 = v_vmart_node0017 v_vmart_node0018 v_vmart_node0019 v_vmart_node0020
rack6 = v_vmart_node0021 v_vmart_node0022 v_vmart_node0023 v_vmart_node0024
rack7 = v_vmart_node0025 v_vmart_node0026 v_vmart_node0027 v_vmart_node0028
rack8 = v_vmart_node0029 v_vmart_node0030 v_vmart_node0031 v_vmart_node0032

在父容错组的第一行之后，编写容错组描述的顺序并不重要。您在此文件中定义的所有容错组都必须引用父容错组。您可以直接指示父组，也可以通过指定作为父容错组子级的容错组的子级来指示。

如：

rack1 rack2 rack3 rack4 rack5 rack6 rack7 rack8
rack1 = v_vmart_node0001 v_vmart_node0002 v_vmart_node0003 v_vmart_node0004
rack2 = v_vmart_node0005 v_vmart_node0006 v_vmart_node0007 v_vmart_node0008
rack3 = v_vmart_node0009 v_vmart_node0010 v_vmart_node0011 v_vmart_node0012
rack4 = v_vmart_node0013 v_vmart_node0014 v_vmart_node0015 v_vmart_node0016
rack5 = v_vmart_node0017 v_vmart_node0018 v_vmart_node0019 v_vmart_node0020
rack6 = v_vmart_node0021 v_vmart_node0022 v_vmart_node0023 v_vmart_node0024
rack7 = v_vmart_node0025 v_vmart_node0026 v_vmart_node0027 v_vmart_node0028
rack8 = v_vmart_node0029 v_vmart_node0030 v_vmart_node0031 v_vmart_node0032

创建容错组输入文件后，即可运行 fault_group_ddl_generator.py。您需要利用此脚本生成的 DDL 语句来在 Vertica 中创建容错组。

如果您的 Vertica 数据库共置于一个 Hadoop 群集上，并且该群集使用多个机架，您可以使用容错组来提高性能。请参阅配置机架位置。

另请参阅

创建容错组

1.6.3 - 创建容错组

在定义容错组时，Vertica 会将数据段分发到整个群集中。这使得群集能够了解群集拓扑，以便它可以容忍环境中固有的相关故障，例如机架故障。有关概览，请参阅容错组的高可用性。

重要

定义容错组需要进行认真、彻底的网络规划，以及对网络拓扑的深入了解。

先决条件

要定义容错组，您必须具有：

超级用户权限
容错组输入文件
现有数据库

运行容错组脚本

以数据库管理员身份运行 fault_group_ddl_generator.py 脚本：
```
python /opt/vertica/scripts/fault_group_ddl_generator.py databasename fault-group-inputfile > sql‑filename
```
例如，以下命令将 Python 脚本输出写入 SQL 文件 fault_group_ddl.sql 中。
```
$ python /opt/vertica/scripts/fault_group_ddl_generator.py
    VMart fault_groups_VMart.out > fault_group_ddl.sql
```
在脚本返回后，可以运行 SQL 文件，而不是单独运行多个 DDL 语句。

提示
请考虑保存输入文件，以便稍后可以修改容错组，例如在扩展群集或更改控制节点的分布之后。
使用 vsql，运行 fault_group_ddl.sql 中的 DDL 语句或使用 vsql 执行该文件中的命令。
```
=> \i fault_group_ddl.sql
```
如果启用了大型群集，请使用 REALIGN_CONTROL_NODES 重新对齐控制节点。否则，跳过此步骤。
```
=> SELECT REALIGN_CONTROL_NODES();
```
通过调用 RELOAD_SPREAD 将群集更改保存到 Spread 配置文件：
```
=> SELECT RELOAD_SPREAD(true);
```
使用管理工具 (Administration Tools) 重新启动数据库。
通过调用 REBALANCE_CLUSTER 将更改保存到群集的数据布局：
```
=> SELECT REBALANCE_CLUSTER();
```

另请参阅

1.6.4 - 监控容错组

您可以通过查询 Vertica 系统表或登录到管理控制台界面监控容错组。

使用系统表监控容错组

使用以下系统表查看与容错组和群集缺陷有关的信息，例如在不关闭数据库的情况下群集无法丢失的节点：

V_CATALOG.FAULT_GROUPS：查看群集中所有容错组的层次结构。
V_CATALOG.CLUSTER_LAYOUT：观察参与数据业务的节点的排列以及影响这些节点的容错组。临时节点不显示在群集布局环中，因为它们没有任何数据。

使用管理控制台监控容错组

MC 管理员可以通过以下步骤监控和突出显示感兴趣的容错组：

单击要监控的正在运行的数据库，然后在任务栏中单击管理 (Manage)。
打开容错组视图 (Fault Group View) 菜单，然后选择要查看的容错组。
（可选）隐藏不在选定容错组中的节点以关注感兴趣的容错组。

分配给容错组的节点每个都在节点图标左上角有一个彩色气泡。每个容错组都有一个独特的颜色。如果容错组的数量超过可用的颜色数量，MC 将循环使用先前使用的颜色。

由于 Vertica 支持不同形状和大小的复杂分层容错组，因此 MC 将多个容错组的参与显示为一堆不同颜色的气泡。气泡越高，代表容错组的层次越低，这意味着气泡更接近父容错组（而不是子容错组或孙容错组）。

有关容错组层次结构的详细信息，请参阅容错组的高可用性。

1.6.5 - 删除容错组

从群集中移除容错组时，请注意删除操作会移除指定的容错组及其子容错组。Vertica 将所有节点都放在删除的容错组的父代下面。要查看群集中的当前容错组层次结构，请查询 FAULT_GROUPS 系统表。

删除容错组

使用 DROP FAULT GROUP 语句从群集中移除容错组。以下示例显示了如何删除 group2 容错组：

=> DROP FAULT GROUP group2;
DROP FAULT GROUP

删除所有的容错组

使用 ALTER DATABASE 语句从指定数据库群集中删除所有容错组以及任何子容错组。

以下命令将从当前数据库中删除所有容错组。

=> ALTER DATABASE DEFAULT DROP ALL FAULT GROUP;
ALTER DATABASE

将节点重新添加到容错组中

要将节点重新添加到容错组中，必须手动将其重新分配到新容错组或现有容错组。要执行此操作，请使用 CREATE FAULT GROUP 和 ALTER FAULT GROUP..ADD NODE 语句。

另请参阅

1.7 - Terrace 路由

重要

在将 Terrace 路由应用到数据库之前，请确保您熟悉大型群集和容错组。

Terrace 路由可以显著减少大型群集数据库上的消息缓冲。以下几部分介绍 Vertica 如何在企业模式数据库和 Eon 模式数据库上实现 Terrace 路由。

企业模式下的 Terrace 路由

企业模式数据库上的 Terrace 路由是通过用来定义基于机架的拓扑的容错组实现的。在禁用 Terrace 路由的大型群集中，Vertica 群集中的节点形成一个完全互连的网络，其中每个非依赖（控制）节点通过与所有其他非依赖节点（无论是在其自己的机架/容错组内部还是外部）的连接在数据库群集中发送消息：

在这种情况下，大型 Vertica 群集可能需要每个节点上有许多连接，其中每个连接都会产生自己的网络缓冲要求。每个节点所需的缓冲区总数按如下公式计算：

(numRacks * numRackNodes) - 1

在如上所示每个机架 4 个节点的双机架群集中，求解结果为每个节点 7 个缓冲区。

启用 Terrace 路由后，可以显著减少大型群集网络缓冲。机架/容错组中的每第 n 个节点与所有其他容错组的相应第 n 个节点配对。例如，在启用 Terrace 路由时，同一个双机架群集中的消息传递现在按如下方式实现：

因此，来自机架 A (A2) 上节点 2 的消息将发送到机架 A 上的所有其他节点；然后，每个机架 A 节点将消息传送到机架 B 上的相应节点 — A1 到 B1，A2 到 B2，依此类推。

在启用 Terrace 路由时，给定机架的每个节点都避免了为所有其他节点维护消息缓冲区的开销。相反，每个节点只负责维护与以下节点的连接：

同一机架的所有其他节点 ( numRackNodes - 1)
每个其他机架上的一个节点 ( numRacks - 1)

因此，每个节点所需的消息缓冲区总数按如下公式计算：

(numRackNodes-1) + (numRacks-1)

在如上所示具有 4 个节点的双机架群集中，求解结果为每个节点 4 个缓冲区。

Terrace 路由以时间（机架内跃点数）换取空间（网络消息缓冲区数）。通过向群集中添加额外的机架和节点来扩展群集时，支持这种权衡的论点变得越来越有说服力：

在这个每个机架 4 个节点的三机架群集中，如果没有 Terrace 路由，每个节点所需的缓冲区数量为 11。如果有 Terrace 路由，每个节点的缓冲区数量为 5。通过向群集中添加机架和向每个机架中添加节点来扩展群集时，缓冲区要求之间的差异也会扩大。例如，给定一个每个机架 16 个节点的六机架群集，如果没有 Terrace 路由，每个节点所需的缓冲区数量为 95；如果有 Terrace 路由，则为 20。

启用 Terrace 路由

Terrace 路由取决于容错组定义，这些定义描述围绕机架及其成员节点组织的群集网络拓扑。如前所述，启用 Terrace 路由时，Vertica 首先在机架/容错组内分发数据；然后使用第 n 个节点到第n 个节点的映射将此数据转发到数据库群集中的所有其他机架。

您可以通过 TerraceRoutingFactor 配置参数为任何实现基于机架的容错组的企业模式大型群集启用（或禁用）Terrace 路由。要启用 Terrace 路由，请按如下方式设置此参数：

其中：

numRackNodes：机架中的节点数
numRacks：群集中的机架数

例如：

默认情况下，TerraceRoutingFactor 设置为 2，这通常可以确保为任何实现基于机架的容错组的企业模式大型群集启用 Terrace 路由。当群集包含 64 个或更多节点时，或者如果查询需要过多的缓冲空间，Vertica 建议启用 Terrace 路由。

要禁用 Terrace 路由，请将 TerraceRoutingFactor 设置为一个大整数，例如 1000：

=> ALTER DATABASE DEFAULT SET TerraceRoutingFactor = 1000;

Eon 模式下的 Terrace 路由

与企业模式一样，Terrace 路由在 Eon 模式数据库上默认处于启用状态，并通过容错组实现。但是，您不会为 Eon 模式数据库创建容错组。相反，Vertica 会自动在大型群集数据库上创建容错组；这些容错组围绕每个子群集的控制节点及其依赖项进行配置。这些容错组由 Vertica 内部管理，无法供用户访问。

1.8 - 弹性群集

注意

弹性群集是仅限企业模式的功能。要在 Eon 模式下伸缩数据库，请参阅扩展 Eon 模式数据库。

您可以根据数据库需要，扩大或缩减群集。最常见的情况是向数据库群集添加节点以容纳更多数据，并提供更好的查询性能。但是，如果发现群集过度配置或需要将硬件用于其他用途，您也可以缩减群集。

您可以通过添加或移除节点来对群集进行扩展或缩减。添加或移除节点时无需关闭或重新启动数据库。添加节点后或移除节点前，Vertica 会开始重新平衡过程，即在群集中移动数据，以填充新节点或将数据从要从数据库移除的节点中移出。在此过程中，数据也可能在未在添加或移除的节点之间交换，以此来维持强大的智能 K-safety。如果 Vertica 确定由于磁盘空间不足，数据不能在一次迭代中重新平衡，则会在多次迭代中完成重新平衡。

为确保在扩展或缩减群集时更高效地实现数据重新平衡，Vertica 会在每个节点本地对数据存储进行分段，以便它能够轻松移动到群集中的其他节点。将新节点添加到群集时，群集中的现有节点会放弃某些数据段以填充新节点并交换数据段，从而将任何一个节点所依赖的节点数量保持为最低。此策略会将节点出现故障时成为关键节点的节点数量保持为最低（请参阅关键节点/企业模式数据库中的 K-safety）。从群集中移除节点时，该节点的所有存储容器都会移动到群集中的其他节点（这时也会重新迁移数据段来最大限度减少节点出现故障时成为关键节点的节点数量）。这种将数据拆分为便于迁移的数据段的方式称为弹性群集，因为它有利于轻松扩展或缩减群集。

弹性群集的替代方案是对投影中的所有数据进行重新分段，并在添加或移除节点时将这些数据均匀分布到数据库中的所有节点。此方法需要处理的工作量更多，占用的磁盘空间也更多，因为它实质上需要转储并重新加载所有投影中的所有数据。

弹性群集伸缩系数

在新安装中，每个节点都有一个指定本地数据段数量的伸缩系数（请参阅伸缩系数）。重新平衡可以通过重新迁移本地数据段来高效地重新分布数据，前提是在添加或移除节点后，群集中具有足够的本地数据段来均匀地重新分布数据（由 MAXIMUM_SKEW_PERCENT 确定）。例如，如果伸缩系数 = 8，并且最初有 5 个节点，那么整个群集中总共有 40 个本地数据段。

如果添加两个额外的节点（7 个节点），Vertica 会在 2 个节点上重新定位 5 个本地分段，在 5 个节点上重新定位 6 个此类分段，从而导致大约 16.7% 的偏差。只有当得到的偏差率低于允许的阈值（这由 MAXIMUM_SKEW_PERCENT 确定）时，重新平衡机制才重新定位本地分段。否则，重新平衡机制会在这 7 个节点上均匀分布分段空间（进而均匀分布数据，如果数据在此空间中均匀分布的话），并为每个节点划定新的本地数据段边界，确保每个节点再次拥有 8 个本地数据段。

注意

默认情况下，只有当 Vertica 重新平衡数据库时，伸缩系数才会发挥作用。重新平衡时，每个节点都会将它包含的投影分段拆分到存储容器中，然后根据需要将存储容器移动至其他节点。重新平衡后，数据会重新合并到

ROS 容器中。让 Vertica 始终将数据分组到存储容器中是有可能实现的。有关详细信息，请参阅局部数据分段。

启用弹性群集

使用 ENABLE_ELASTIC_CLUSTER 启用弹性群集。查询 ELASTIC_CLUSTER 系统表来验证弹性群集是否已启用：

=> SELECT is_enabled FROM ELASTIC_CLUSTER;
 is_enabled
------------
 t
(1 row)

1.8.1 - 伸缩系数

为避免 ROS 容器数量增加，请不要启用局部分段，也不要更改伸缩系数。

1.8.2 - 查看伸缩系数设置

要查看伸缩系数，请查询 ELASTIC_CLUSTER 表：

=> SELECT scaling_factor FROM ELASTIC_CLUSTER;
scaling_factor
---------------
            4
(1 row)

=> SELECT SET_SCALING_FACTOR(6);
 SET_SCALING_FACTOR
--------------------
 SET
(1 row)

=> SELECT scaling_factor FROM ELASTIC_CLUSTER;
 scaling_factor
---------------
             6
(1 row)

1.8.3 - 设置伸缩系数

比例因子决定了在启用局部分段时，Vertica 在重新平衡期间用于跨数据库存储每个投影的存储容器的数量。在设置比例因子时，请遵循以下准则：

存储容器的数量应大于或等于分区数量与本地分段数量的积：

num‑storage‑containers >= ( num‑partitions * num‑local‑segments )
若将比例因子设置得足够高，以便重新平衡可以传输本地分段以满足偏移阈值，但将值设置得很小，以便存储容器数量将不会产生过多的 ROS 容器，并导致 ROS 推回）。ROS 容器的最大数量（默认为 1024）由配置参数 ContainersPerProjectionLimit 设置。

使用 SET_SCALING_FACTOR 函数可以更改数据库的伸缩系数。伸缩系数可以为 1 到 32 之间的整数。

=> SELECT SET_SCALING_FACTOR(12);
SET_SCALING_FACTOR
--------------------
 SET
(1 row)

1.8.4 - 局部数据分段

默认情况下，只有当 Vertica 重新平衡数据库时，伸缩系数才会发挥作用。在重新平衡期间，节点会将其包含的投影分段分解到多个存储容器中，以便它们能够快速移动到其他节点。

与对整个投影进行重新分段相比，此过程更加高效（特别是，它需要更少的可用磁盘空间），但是仍然需要较大开销，因为必须将存储容器分离到多个局部分段中，然后将其中一些局部分段传输到其他节点。如果您很少从数据库中添加或移除节点，此开销并不算是一个问题。

但是，如果您的数据库增长快速并且持续处于繁忙状态，则可能会发现添加节点的过程将变得具有破坏性。这种情况下，您可以启用局部分段，这会告诉 Vertica 始终根据伸缩系数对其数据进行分段，因此始终将数据分解到多个易于移动的容器中。通过这种方式对数据进行分段会显著提高添加或删除节点的速度，因为数据始终处于一种可以快速重新定位到另一个节点的状态。Vertica 在添加或移除节点后执行的重新平衡过程只需要决定要重新定位的存储容器即可，无须首先将数据分解到存储容器中。

局部数据分段会增加存储在每个节点上的存储容器数量。除非表包含许多分区，否则这算不上一个问题。（例如，如果表按天进行分区并包含一个或多个年份。）如果启用局部数据分段，则会将其中每个表分区分解到多个局部存储分段中，这可能会生成大量文件，进而可能导致 ROS“推回”。请先考虑表分区以及启用局部数据分段可能造成的影响，然后再启用此功能。

1.8.4.1 - 启用和禁用局部分段

要启用局部分段，请使用 ENABLE_LOCAL_SEGMENTS 函数。要禁用局部分段，请使用 DISABLE_LOCAL_SEGMENTATION 函数：

=> SELECT ENABLE_LOCAL_SEGMENTS();
ENABLE_LOCAL_SEGMENTS
-----------------------
 ENABLED
(1 row)


=> SELECT is_local_segment_enabled FROM elastic_cluster;
 is_enabled
------------
 t
(1 row)

=> SELECT DISABLE_LOCAL_SEGMENTS();
 DISABLE_LOCAL_SEGMENTS
------------------------
 DISABLED
(1 row)

=> SELECT is_local_segment_enabled FROM ELASTIC_CLUSTER;
 is_enabled
------------
 f
(1 row)

1.8.5 - 弹性群集最佳实践

下面是一些关于局部分段的最佳实践。

注意

您应始终在执行本主题讨论的任何操作之前和之后执行数据库备份。在更改任何弹性群集或局部分段设置之前需要进行备份，以防止可导致重新平衡过程，使数据库处于不可用状态的硬件故障。在重新平衡过程之后，应执行数据库完整备份，以避免在从备份还原时需要再次重新平衡数据库。

何时启用局部数据分段

局部数据分段可以显著加快调整群集大小的过程。在以下情况下，应当启用局部数据分段：

数据库不包含具有数百个分区的表。
数据库群集中的节点数为 2 的幂次方。
计划扩大或缩小群集大小。

局部分段可能会导致具有数百个分区的表或节点数不是 2 的幂次方的群集的存储容器数量过多。如果您的数据库具有这两个特征，在启用局部分段时请小心。

1.9 - 添加节点

在 Vertica 安装中添加一个或多个节点的原因有许多：

**提高系统性能。**在查询负载很高或加载延迟时添加额外的节点，或者在不向现有节点添加存储位置的情况下增加磁盘空间。

注意

数据库响应时间取决于多个因素，例如，应用程序查询的类型和规模、数据库设计、存储的数据大小和数据类型、可用的计算能力及网络带宽。如果要将节点添加到数据库群集，不必改善每个查询的系统响应时间，尤其是在响应时间已经很短（例如，小于 10 秒，或响应时间不受硬件约束）时。

将数据库设置为 K-safe ( K-safety=1) 或将 K-safety 增加至 2。有关详细信息，请参阅故障恢复。
**交换节点进行维护。**使用备用计算机临时接管需要维护的现有节点的活动。需要维护的节点是事先已知的，因此将此节点从服务中暂时删除时，群集并不会轻易受到其他节点故障的影响。
**替换节点。**永久性添加节点，以移除过时或有故障的硬件。

重要

如果将 Vertica 安装在单个节点上但没有指定 IP 地址或主机名（或者使用了 localhost），则无法扩展群集。必须重新安装 Vertica 并指定 IP 地址或主机名（非 localhost/127.0.0.1）。

添加节点时，包括以下常规任务：

备份数据库。

Vertica 强烈建议在执行这项重大操作前先备份数据库，因为在操作过程中需要创建新投影，刷新投影，然后删除旧投影。有关详细信息，请参阅备份和还原数据库。

迁移投影设计以包括其他节点的过程可能需要一些时间；但在此期间，数据库上的所有用户活动都可以使用旧投影正常进行。
配置要添加至群集的主机。

请参阅在安装 Vertica 之前。此外，还需要编辑群集中所有现有节点上的主机配置文件，以确保这些节点可以解析新的主机。
向群集添加一个或多个主机。
将已添加至群集的主机添加到数据库中（第 3 步）。

注意

“主机”添加到数据库后即变为一个“节点”。可使用

管理工具或

管理控制台将节点添加到数据库（请参阅使用 MC 进行监控）。

也可以使用 admintools 命令行添加节点，这样可以保留所添加节点的特定顺序。

向数据库中添加节点之后，Vertica 会自动将更新后的配置文件分布到群集中的其余节点，并启动在群集中重新平衡数据的过程。有关详细信息，请参阅在节点之间重新平衡数据。

1.9.1 - 向群集中添加主机

备份数据库并配置要添加到群集的主机后，此时可以使用 update_vertica 脚本将主机添加到群集。

您不能使用 MC 向内部部署环境中的群集中添加主机。但是，在向群集中添加主机后，MC 确实允许您将主机作为节点添加到数据库中。

先决条件和限制

如果将 Vertica 安装在一个节点上，但没有指定 IP 地址或主机名（使用了 localhost），则无法扩展群集。您必须重新安装 Vertica，并指定 IP 地址或主机名。

添加主机的步骤

在一个现有群集主机中，运行至少带有 \--add-hosts host(s) 参数（其中 host(s) 是要添加到群集的系统的主机名或 IP 地址）和 --rpm 或 --deb 参数的 update_vertica 脚本。

# /opt/vertica/sbin/update_vertica --add-hosts host(s) --rpm package

注意

有关参数的完整列表，请参阅使用安装脚本安装 Vertica。您还必须提供最初安装群集时所使用的相同选项。

update_vertica* * 脚本使用与 install_vertica 相同的所有选项，并执行以下操作：

在新主机中，安装 Vertica RPM。
执行安装后检查，包括 RPM 版本和 N 向网络连接检查。
将 spread 更改为包含更大的群集。
配置管理工具以处理更大的群集。

重要提示：

节点达到或超过 50 个时，请考虑使用 --large-cluster。
使用要添加到群集的系统的主机名或 IP 地址可以指定主机。但是，在内部，Vertica 将所有主机地址都存储为 IP 地址。
如果指定了一个以上的主机，请勿在随 --add-hosts 提供的主机名/IP 地址列表中使用空格。
如果使用 --rpm/--deb 指定包，并且此包比当前在现有群集中安装的包要新，则 Vertica 会在安装新添加的主机之前，首先将新包安装在现有群集主机中。
参照最初安装群集时使用的参数，为数据库管理员用户名、密码和目录路径使用相同的命令行参数。或者，您可以创建一个属性文件保存安装期间的参数，然后在后续安装和更新时重复使用该属性文件。请参阅静默安装 Vertica。
如果使用 sudo 安装，数据库管理员用户 (dbadmin) 必须已存在于要添加的主机中，并且必须配置与现有主机相同的密码和主目录路径。如有必要，Vertica 会从现有主机建立与新主机的免密码 SSH。
如果最初使用 --point-to-point 选项将 spread 配置为在子网中节点之间使用直接点对点通信，则无论何时运行 install_vertica 或 update_vertica，均应使用 --point-to-point 选项。否则，群集的配置将恢复为默认设置 (broadcast)，这会影响将来的数据库。
点对点通信和广播流量支持的 spread 守护程序的最大数量为 80 个。使用大型群集模式时，节点数量可能会超过 80 个，这时将无法在每个节点上安装一个 spread 守护程序。

示例

--add-hosts host01 --rpm
--add-hosts 192.168.233.101
--add-hosts host02,host03

1.9.2 - 向数据库中添加节点

向群集中添加一个或多个主机后，可以使用以下选项之一将它们作为节点添加到数据库：

admintools 命令行，以确保按特定顺序添加节点
管理工具
管理控制台

命令行

使用 admintools db_add_node 工具，可以控制将节点添加到数据库群集的顺序。它使用 ‑s 或 ‑‑hosts 选项指定新节点的主机，这些选项采用逗号分隔的实参列表。Vertica 按列表指定的顺序添加新节点。例如，以下命令添加三个节点：

$ admintools ‑t db_add_node \
      -d VMart \
      -p 'password' \
      -s 192.0.2.1,192.0.2.2,192.0.2.3

提示

向 Eon 模式数据库中添加节点时，还可以指定新节点应属于的子群集。有关详细信息，请参阅在子群集中添加和移除节点。

管理工具

您可以按如下方式，使用管理工具向数据库中添加节点：

打开管理工具。
在主菜单 (Main Menu) 上，选择查看数据库群集状态 (View Database Cluster State) 以验证数据库是否正在运行。如果未运行，请将其启动。
从主菜单 (Main Menu) 中，选择高级菜单 (Advanced Menu)，然后单击确定 (OK)。
在高级菜单 (Advanced Menu) 中，选择群集管理 (Cluster Management)，然后单击确定 (OK)。
在群集管理 (Cluster Management) 菜单中，选择添加主机 (Add Host(s))，然后单击 确定 (OK)。
选择要将一个或多个主机添加到的数据库，然后选择确定 (OK)。

此时会显示未使用主机列表。
选择要添加到数据库的主机，然后单击确定 (OK)。
显示提示时，单击是 (Yes) 以确认要添加的主机。
显示提示时，输入数据库的密码，然后选择确定 (OK)。
显示主机已成功添加的提示时，选择确定 (OK)。
此时，Vertica 自动启动重新平衡过程，以便为新节点填充数据。显示提示时，输入 Database Designer 可用于重新平衡数据库中数据的临时目录的路径，然后选择确定 (OK)。
按 Enter 接受默认的 K-Safety 值，或为数据库输入更大的值，然后选择确定 (OK)。
选择是立即重新平衡数据库还是稍后重新平衡。在这两种情况下，Vertica 都会创建一个脚本，您可以随时使用它来重新平衡。

查看重新平衡过程的摘要，并选择继续 (Proceed)。

如果选择自动重新平衡，则会运行重新平衡过程。如果选择创建脚本，则会生成和保存脚本。无论哪种情况，您都会看到一个成功屏幕。
选择确定 (OK) 以完成“添加节点”过程。

管理控制台

要使用 MC 向 Eon 模式数据库中添加节点，请参阅将节点添加到云上正在运行的群集。

要使用 MC 向企业模式数据库中添加节点，请参阅向群集中添加主机

1.10 - 移除节点

永久删除节点虽然不像添加节点那样常见，但如果主机系统过时或过度配置，它将非常有用。

重要

在从群集中移除节点之前，请检查群集是否具有符合 K-safety 所需的最少节点数。如有必要，请暂时降低数据库的 K‑safety 级别。

1.10.1 - 自动逐出运行状况不佳的节点

为了管理群集中节点的运行状况，Vertica 通过发送和接收检测信号来定期执行运行状况检查。在运行状况检查期间，群集中的每个节点都会验证对其编录、编录磁盘和本地存储位置（'TEMP、DATA'、TEMP、DATA 和 DEPOT）的读写访问权限。验证后，节点发送检测信号。如果一个节点在五个间隔后未能发送检测信号（五次运行状况检查失败），则会将该节点从群集中逐出。

您可以使用 DatabaseHeartBeatInterval 参数控制相邻两次运行状况检查之间的时间。默认情况下，DatabaseHeartBeatInterval 设置为 120，即允许在无检测信号的情况下经过五个 120 秒的间隔。

逐出前允许的时间长度为：

TOT = DHBI * 5

其中，TOT 是在逐出之前所允许的无检测信号总时间（以秒为单位），DHBI 等于 DatabaseHeartBeatInterval 的值。

如果您设置的 DatabaseHeartBeatInterval 值过低，则可能导致节点在出现短暂的运行状况问题时被逐出。有时，此类过早逐出会降低 Vertica 数据库的可用性和性能。

另请参阅

常规参数中的 DatabaseHeartbeatInterval 常规参数

1.10.2 - 降低 K‑Safety 以启用节点移除

K-safety 级别为 1 的数据库至少需要三个节点才能运行，K-safety 级别为 2 的数据库至少需要 5 个节点才能运行。您可以按照如下方式检查群集的当前 K-safety 级别：

=> SELECT current_fault_tolerance FROM system;
 current_fault_tolerance
-------------------------
                       1
(1 row)

要从具有 K-safety 所要求的最少节点数的群集中移除节点，请首先使用 MARK_DESIGN_KSAFE 降低 K-safety 级别。

当心

将数据库的 K-safety 级别降低到 0 会消除 Vertica 的容错功能。如果必须将 K-safety 降为 0，请首先备份数据库。

使用管理工具或 vsql 连接到数据库。
调用 MARK_DESIGN_KSAFE 函数：
```
SELECT MARK_DESIGN_KSAFE(n);
```
其中 n 是数据库的新 K-safety 级别。

1.10.3 - 从数据库中移除节点

注意

在 Eon 模式数据库中，可从包含节点的子群集（而非数据库）中移除节点。有关详细信息，请参阅移除节点。

只要有足够的剩余节点来满足 K-Safety 要求，便可以从数据库中移除节点。不能删除对 K-safety 至关重要的节点。请参阅降低 K‑Safety 以启用节点移除。

可使用以下方法之一从数据库中移除节点：

管理控制台界面
管理工具

先决条件
在从数据库中移除节点之前，请验证数据库是否符合以下要求：

它正在运行。
它已备份。
该数据库具有符合 K-safety 所需的最少节点数。如有必要，请暂时降低数据库的 K‑safety 级别。
数据库中的所有节点都必须处于正常运行状态或处于活动备用状态。如果您在数据库节点关闭时尝试移除节点，Vertica 会报告错误“所有节点都必须处于 UP 或 STANDBY 才能删除节点 (All nodes must be UP or STANDBY before dropping a node)”。即使尝试移除处于关闭状态的节点，也会收到此错误。

管理控制台

使用管理控制台将节点从其管理页面中移除：

按照如下方式移除数据库节点：

选择要移除的节点。
在节点列表中单击移除节点 (Remove node)。

存在以下限制：

只能移除属于数据库群集的节点。
不能移除处于 DOWN 状态的节点。

移除节点时，它的状态会更改为 STANDBY。可稍后将处于 STANDBY 状态的节点添加回数据库。

管理工具

要使用管理工具从数据库中移除未使用的主机：

打开管理工具。有关访问管理工具的信息，请参阅使用管理工具。
在“主菜单 (Main Menu)”上，选择“查看数据库群集状态 (View Database Cluster State)”以验证数据库是否正在运行。如果数据库未在运行，请启动该数据库。
从“主菜单 (Main Menu)”中，选择“高级菜单 (Advanced Menu)”，然后选择“确定 (OK)”。
在“高级菜单 (Advanced Menu)”中，选择“群集管理 (Cluster Management)”，然后选择“确定 (OK)”。
在“群集管理 (Cluster Management)”菜单中，选择“从数据库中移除主机 (Remove Host(s) from Database)”，然后选择“确定 (OK)”。
当出现警告，提示您必须重新设计数据库并创建不包括待删除主机的投影时，选择“是 (Yes)”。
选择要从中移除主机的数据库，然后选择“确定 (OK)”。

此时将出现当前处于活动状态的主机列表。
选择要从数据库中移除的主机，然后选择“确定 (OK)”。
出现提示时，选择“确定 (OK)”以确认您希望移除这些主机。
收到主机已成功移除的通知时，选择“确定 (OK)”。
如果从大型群集 (Large Cluster) 配置中移除了某个主机，则打开 vsql 会话并运行 realign_control_nodes：
```
SELECT realign_control_nodes();
```
有关更多详细信息，请参阅 REALIGN_CONTROL_NODES。
如果该主机未被群集中的任何其他数据库使用，您可以从群集中移除该主机。请参阅从群集中移除主机。

1.10.4 - 从群集中移除主机

如果从数据库中移除的某个主机未被任何其他数据库使用，您可以使用 update_vertica 将该主机从群集中移除。在此操作期间，可让数据库一直运行。

当您使用 update_vertica 减小群集的大小时，它还会执行以下任务：

将 spread 修改为匹配小型群集。
将管理工具配置为处理小型群集。

注意

您可以使用管理控制台从数据库中移除主机，但不能从群集中移除这些主机。

在其中一台 Vertica 群集主机上，运行带 –-remove-hosts 开关的 update_vertica。此开关采用要从群集中移除的主机的逗号分隔列表。您可以按名称或 IP 地址引用主机。例如，可以按如下方式移除主机 host01、host02 和 host03：

 # /opt/vertica/sbin/update_vertica --remove-hosts host01,host02,host03 \
            --rpm /tmp/vertica-10.1.1-0.x86_64.RHEL6.rpm \
            --dba-user mydba

如果 --rpm 指定新的 RPM，则 Vertica 会先将其安装在现有群集主机上，然后再继续。

update_vertica 使用与 install_vertica.相同的选项。有关所有选项，请参阅使用安装脚本安装 Vertica。

要求

如果 -remove-hosts 指定了包含多个主机的列表，则在该列表中的主机之间不能嵌入任何空格。
使用与原始安装相同的命令行选项。如果您针对数据库管理员用户名、密码或目录路径使用非默认值，请在移除主机时提供相同的信息；否则，此过程将失败。考虑将原始安装选项保存在属性文件中，以便在后续安装和更新操作中重新使用这些选项。请参阅静默安装 Vertica。

1.11 - 替换节点

如果您具有 K-safe 数据库，则可根据需要替换节点，而且不会降低系统性能。例如，您可以希望在以下情况下替换现有节点：

需要修复不再正常运行的现有主机系统并将其恢复为群集
要将现有主机系统换成更加强大的另一系统

注意

Vertica 不支持在 K-safe 等于 0 的数据库上替换节点。请改用添加和删除节点的过程。

用于替换节点的过程取决于您是否正在将节点替换为：

使用相同名称和 IP 地址的主机
使用不同名称和 IP 地址的主机
活动的备用节点

先决条件

配置 Vertica 的替换主机。请参阅在安装 Vertica 之前。
请仔细阅读向群集中添加主机和从群集中移除主机下的重要提示****部分。
确保新主机上存在数据库管理员用户且其配置方式与现有主机相同。Vertica 将根据需要设置免密码 ssh。
确保将编录路径、数据路径和任何存储位置的目录在创建数据库时已添加到数据库中，并且/或者这些目录已正确安装到新主机上，而且数据库管理员用户具有读写访问权限。另请确保有足够的磁盘空间。
按照下面的最佳实践步骤将故障硬件重新引入群集中，从而避免虚假完整节点重建。

按照下述过程进行操作可防止 Vertica 将磁盘缺失或挂载错误的情况错误地诊断为数据损坏，进而避免发生耗时的全节点恢复。

如果服务器因硬件问题（例如磁盘错误或控制器故障）而发生故障，请在修复硬件时：

将计算机重启至运行级别 1，这是仅适用于控制台的 root 模式。

运行级别 1 可禁止网络连接并阻止 Vertica 尝试重新连接到群集。
在运行级别 1 中，验证硬件是否已得到修复，控制器是否处于联机状态，以及是否可以继续执行任何 RAID 恢复操作。

注意
在运行级别 1 中，无需初始化 RAID 恢复；只需验证其是否可以恢复。
只有在确认硬件一致之后才能重启至运行级别 3 或更高级别。

此时将激活网络，同时 Vertica 会重新加入群集并自动恢复任何缺失的数据。请注意，在单节点数据库中，如果与投影关联的任何文件被删除或损坏，Vertica 将删除与该投影关联的所有文件，这可能会导致数据丢失。

1.11.1 - 使用相同的名称和 IP 地址替换主机

如果已移除现有 Vertica 数据库的主机，您可以在该数据库正在运行时替换此主机。

注意

请记住，Vertica 中的主机由 Vertica 软件所在的硬件和操作系统以及相同的网络配置组成。

您可以将此主机替换为与旧主机具有以下相同特征的新主机：

名称
IP 地址
操作系统
操作系统管理员用户
目录位置

在数据库正在运行时替换主机可防止系统停机。在替换主机之前，请首先备份您的数据库。有关详细信息，请参阅备份和还原数据库。

按照如下方式替换为具有以下相同特征的主机：

使用 --rpm 或 --deb 参数从正常运行的主机运行 install_vertica：
```
$ /opt/vertica/sbin/install_vertica --rpm rpm_package
```
有关详细信息，请参阅使用命令行安装。
使用现有节点中的管理工具重新启动新主机。请参阅在节点上重新启动 Vertica。

节点即会自动加入数据库，并通过查询数据库中的其他节点恢复其数据。随后它会过渡为 UP 状态。

1.11.2 - 使用具有不同 IP 地址的节点替换故障节点

使用 IP 地址与原始地址不同的主机系统替换故障节点包含以下步骤：

备份数据库。

Vertica 建议您在执行这项重大操作前先备份数据库，因为在操作过程中需要执行创建新投影、删除旧投影和重新加载数据的操作。
将新主机添加到群集中。请参阅向群集中添加主机。
如果 Vertica 仍在将被替换节点中运行，请使用管理工具在将被替换的主机上停止主机上的 Vertica。
使用管理工具将原始主机替换为新主机。如果使用多个数据库，请替换使用原始主机的所有数据库中的原始主机。请参阅替换主机。
使用向新主机分发配置文件将元数据传输到新主机。
从群集中删除主机。
使用管理工具在主机上重新启动 Vertica。在主菜单 (Main Menu) 上，选择在主机上重新启动 Vertica (Restart Vertica on Host)，然后单击确定 (OK)。有关详细信息，请参阅启动数据库。

完成此过程后，替换节点将查询数据库内的其他节点，从而自动恢复存储在原始节点中的数据。

1.11.3 - 使用不同的名称和 IP 地址替换正常运行的节点

使用 IP 地址和主机名与原始值不同的主机系统替换节点包含以下常规步骤：

备份数据库。

Vertica 建议您在执行这项重大操作前先备份数据库，因为在操作过程中需要执行创建新投影、删除旧投影和重新加载数据的操作。
将替换主机添加到群集中。

此时，您要删除的原始主机和新替换主机均为群集成员。
使用管理工具在将被替换的主机上停止主机上的 Vertica。
使用管理工具将原始主机替换为新主机。如果使用多个数据库，请替换使用原始主机的所有数据库中的原始主机。请参阅替换主机。
从群集中删除主机。
重新启动主机上的 Vertica。

完成此过程后，替换节点将查询数据库内的其他节点，从而自动恢复存储在原始节点中的数据。随后它会过渡为 UP 状态。

注意

如果您不从群集中删除原始主机且尝试重新启动数据库，则该主机不会被邀请加入数据库，因为其节点地址与存储在数据库编录中的新地址不匹配。因此，它仍保持 INITIALIZING 状态。

1.11.4 - 使用管理工具替换节点

如果要将一个节点替换为一个具有不同名称和 IP 地址的节点，可使用管理工具将原始主机替换为新主机。或者，也可以使用管理控制台替换节点。

使用管理工具将原始主机替换为新主机

要使用管理工具将原始主机替换为新主机：

备份数据库。请参阅备份和还原数据库。
在一个正常运行且不会被替换的节点上打开管理工具。
在主菜单 (Main Menu) 上，选择查看数据库群集状态 (View Database Cluster State) 以验证数据库是否正在运行。如果数据库未在运行，请使用“主菜单 (Main Menu)”上的“启动数据库 (Start Database)”命令重新启动数据库。
在主菜单 (Main Menu) 上，选择高级菜单 (Advanced Menu)。
在高级菜单 (Advanced Menu) 上，选择在主机上停止 Vertica (Stop Vertica on Host)。
选择要替换的主机，然后单击确定 (OK) 停止该节点。
当系统提示您是否要停止主机时，选择是 (Yes)。
在高级菜单 (Advanced Menu) 上，选择群集管理 (Cluster Management)，然后单击确定 (OK)。
在群集管理 (Cluster Management) 菜单上，选择替换主机 (Replace Host)，然后单击确定 (OK)。
选择包含要替换的主机的数据库，然后单击确定 (OK)。

随即将显示当前正在使用的所有主机的列表。
选择要替换的主机，然后单击确定 (OK)。
选择要作为替换主机的主机，然后单击确定 (OK)。
出现提示时，输入数据库的密码，然后单击确定 (OK)。
出现提示时，单击是 (Yes) 确认您想要替换主机。
当系统提示主机已成功替换时，单击确定 (OK)。
在主菜单 (Main Menu) 上，选择查看数据库群集状态（View Database Cluster State) 验证是否所有主机都在运行。您可能需要在刚刚替换的主机上启动 Vertica。使用在主机上重新启动 Vertica (Restart Vertica on Host)。

节点进入“正在恢复 (RECOVERING)”状态。

当心

如果您正在使用

K-Safe 数据库，请牢记：恢复节点相当于关闭一个节点，尽管该节点可能尚不包含完整的数据副本。这表示如果您具有一个 K safety=1 的数据库，则数据库的当前容错能力处于关键级别。如果您又失去一个节点，则数据库将关闭。确保您未停止任何其他节点。

1.12 - 在节点之间重新平衡数据

当您添加或移除节点时，Vertica 可以重新平衡您的数据库。作为超级用户，您可以使用管理工具 (Administration Tools)、SQL 函数或管理控制台手动触发重新平衡。

重新平衡操作可能需要一些时间，具体取决于群集大小、投影数量以及投影中包含的数据量。您不得中断此过程，而是允许其正常完成。如果必须取消此操作，请调用 CANCEL_REBALANCE_CLUSTER 函数。

为什么要重新平衡？

在执行以下操作之一后，重新平衡很有用甚至是必要的：

通过添加或移除节点来更改群集的大小。
在准备从群集移除一个或多个节点时，将其标记为临时节点。
更改弹性群集的比例因子，该比例因子可确定用于跨数据库存储投影的存储容器的数目。
设置控制节点大小或重新对齐大型群集布局上的控制节点。
在初始 Vertica 群集配置中指定 120 个以上的节点。
通过添加或移除节点来修改容错组。

常规重新平衡任务

当您重新平衡数据库群集时，Vertica 对所有投影（无论是分段的还是未分段的）执行以下任务：

基于下列内容分配数据：
- 用户定义的容错组（如果已指定）
- 大型群集自动容错组
忽略投影定义中特定于节点的分布规范。在重新平衡节点时始终会将数据分布在所有节点上。
重新平衡完成后，将 Ancient History Mark 设置为允许的最大时期（现在）。

Vertica 对于分段和未分段的投影采用不同的重新平衡方式，如下所述。

重新平衡分段投影

对于每个分段投影，Vertica 执行以下任务：

复制和重命名投影同伴并将它们均匀地分布在所有节点上。重命名的投影共享同一投影基本名。
刷新为新的投影。
删除原始投影。

重新平衡未分段的投影

对于每个未分段的投影，Vertica 执行以下任务：

如果添加节点：

会在节点上创建投影同伴。
会将新投影映射到它们在数据库编录中的共享名称。

如果删除节点：会从节点中删除其投影同伴。

K-safety 和重新平衡

在重新平衡完成之前，Vertica 会使用现有 K-safe 值进行操作。重新平衡完成后，Vertica 将使用在重新平衡操作期间指定的 K-safe 值进行操作。新的 K-safe 值必须等于或高于当前的 K-safety。Vertica 不支持 K-safety 降级，如果您尝试减小其当前值，则会返回一条警告。有关详细信息，请参阅降低 K‑Safety 以启用节点移除。

重新平衡故障和投影

如果在重新平衡数据库时发生故障，您可以再次执行重新平衡操作。解决故障原因后，重新平衡操作会从发生故障之处继续进行。但是，数据重新平衡故障会导致投影变为过时。

要查找过期的投影，请查询系统表 PROJECTIONS，如下所示：

=> SELECT projection_name, anchor_table_name, is_up_to_date FROM projections
   WHERE is_up_to_date = false;

要移除过时的投影，请使用 DROP PROJECTION。

临时表

节点重新平衡对临时表的投影没有影响。

有关重新平衡的详细信息

请参阅知识库文章：

1.12.1 - 使用管理工具 UI 重新平衡数据

要重新平衡数据库中的数据：

打开管理工具。（请参阅使用管理工具。）
在主菜单 (Main Menu) 上，选择查看数据库群集状态 (View Database Cluster State) 以验证数据库是否正在运行。如果未运行，请将其启动。
从主菜单 (Main Menu) 中，选择高级菜单 (Advanced Menu)，然后单击确定 (OK)。
在高级菜单 (Advanced Menu) 中，选择群集管理 (Cluster Management)，然后单击确定 (OK)。
在群集管理 (Cluster Management) 菜单中，选择重新平衡数据 (Re-balance Data)，然后单击确定 (OK)。
选择要重新平衡的数据库，然后选择确定 (OK)。
输入 Database Designer 输出目录（例如 /tmp)），然后单击确定 (OK)。
接受建议的 K-safety 值或提供新值。有效值为 0 到 2。
查看消息，然后单击继续 (Proceed) 开始重新平衡数据。

Database Designer 将修改现有投影，以在具有您提供的 K-safety 的所有数据库节点之间重新平衡数据。此外，还会生成一个用于重新平衡数据的脚本，该脚本位于指定的路径中（例如 /tmp/extend_catalog_rebalance.sql），您可在以后手动运行它。

重要
重新平衡数据可能需要一些时间，具体取决于投影数量及其包含的数据量。Vertica 建议等待此过程完成。如果您必须取消此操作，请使用 Ctrl+C。

当重新平衡操作完成时，终端窗口会通知您。
按 Enter 返回管理工具。

1.12.2 - 使用 SQL 函数重新平衡数据

Vertica 具有三个用于启动和停止群集重新平衡的 SQL 函数。您可以从在非高峰时段运行的脚本调用这些函数，而不是通过管理工具手动触发重新平衡。

REBALANCE_CLUSTER 作为会话前台任务同步重新平衡数据库群集。
START_REBALANCE_CLUSTER()作为后台任务异步重新平衡数据库群集。
CANCEL_REBALANCE_CLUSTER停止任何正在进行中或正在等待执行的重新平衡任务。

1.13 - 向节点重新分发配置文件

添加和移除节点过程会自动重新分发 Vertica 配置文件。您很少需要重新分发配置文件来帮助解决配置问题。

要向主机分发配置文件：

登录到包含这些文件的主机，然后启动管理工具。
在“管理工具 (Administration Tools)”的主菜单 (Main Menu) 中，单击配置菜单 (Configuration Menu)，然后单击确定 (OK)。
在配置菜单 (Configuration Menu) 上，选择分发配置文件 (Distribute Config Files)，然后单击确定 (OK)。
选择数据库配置 (Database Configuration)。
选择要分发文件的数据库，然后单击确定 (OK)。

Vertica 配置文件会分发到所有其他数据库主机上。如果这些文件已经存在于某个主机上，则会被覆盖。
在配置菜单 (Configuration Menu) 上，选择分发配置文件 (Distribute Config Files)，然后单击确定 (OK)。
选择 SSL 密钥 (SSL Keys)。

配置和密钥会分发到所有其他数据库主机上。如果它们已经存在于某个主机上，则会被覆盖。
在配置菜单 (Configuration Menu) 上，选择分发配置文件 (Distribute Config Files)，然后单击确定 (OK)。

选择 AdminTools 元数据 (AdminTools Meta-Data)。

管理工具元数据会分发到群集中的每个主机上。
重新启动数据库。

注意

要通过命令行或脚本分发配置文件 admintools.conf，请使用 admintools 选项 distribute_config_files：

$ admintools -t distribute_config_files

1.14 - 在 MC 上停止和启动节点

您可以在管理 (Manage) 页面单击特定节点以选择它，然后单击“节点列表 (Node List)”中的“启动 (Start)”或“停止 (Stop)”按钮，以此来启动或停止一个或多个数据库节点。

注意

工具栏中的“启动 (Start)”或“停止 (Stop)”按钮启动和停止的是数据库，而不是单个节点。

在数据库和群集 (Databases and Clusters) 页面，您必须首先单击选择数据库。要在该数据库中停止或启动节点，请单击查看 (View) 按钮。您将转到“概览 (Overview)”页面。单击页面底部小程序面板中的管理 (Manage)，随后您将转到数据库节点视图。

“启动 (Start)”和“停止 (Stop)”数据库按钮始终处于活动状态，但是只有当选择的一个或多个节点处于相同状态时，节点“启动 (Start)”或“停止 (Stop)”按钮才会处于活动状态；例如，所有节点都是 UP 或 DOWN。

单击“启动 (Start)”或“停止 (Stop)”按钮后，管理控制台会为您正在启动或停止的节点或数据库更新状态和消息图标。

1.15 - 映射新 IP 地址

有时，运行的现有 Vertica 数据库群集的节点需要采用新 IP 地址。群集节点可能还需要基于不同的 IP 协议运行，例如，将协议从广播更改为点对点时。

注意

尽管可以更改群集中主机的 IP 地址，但不能从一个地址族（IPv4 相对于 IPv6）更改为另一个族。例如，假设数据库群集中的主机由 IPv4 网络地址标识，那么，您只能将主机的地址更改为另一个 IPv4 地址，而不能将它们更改为 IPv6 地址。

要更改数据库群集中主机的 IP 地址，请使用 re_ip 函数更改 IP 地址并将旧地址映射到新地址：

$ admintools -t re_ip -f mapfile

mapfile 引用您创建的文件，其中包含新旧 IP 地址。

在下列任一情况下，可以使用此函数更改 IP 地址：

如果您的 Vertica 数据库群集具有相同的数据和控制消息地址，请执行以下操作之一：
- 更改所有数据库群集节点的 IP 地址。
- 仅更改一个或部分数据库群集节点的 IP 地址。
```
$ admintools -t re_ip -f mapfile
```
将 Vertica 数据库群集的 IP 地址从广播模式更改为点对点（单播）模式：
```
$ admintools -t re_ip -d dbname -T
```
将 Vertica 数据库群集的 IP 地址从点对点（单播）模式更改为广播模式：
```
$ admintools -t re_ip -d dbname -U
```
注意
有关更改通信协议的信息，请参阅使用安装脚本安装 Vertica下的 -U 和 -T 选项。
更改数据库群集的控制 IP 地址。在这种情况下，映射文件必须包含控制消息 IP 地址和相关的广播地址。
```
$ admintools -t re_ip -f mapfile
```
仅更改一个数据库的 IP 地址，而不更改 admintools 配置。请参阅仅映射数据库上的 IP 地址。

注意

仅更改数据库的 IP 地址对错误的恢复很有用。节点名称和 IP 地址必须与 admintools.conf 中的节点信息相同。也可以运行 SELECT * from vs_nodes order by name 显示节点信息。

有关上述命令中所用选项的详细信息，请参阅Re-IP 命令行选项。

更改 IP 地址和导出 IP 地址

默认情况下，节点 IP 地址和导出 IP 地址配置为相同的 IP 地址。导出地址是网络上可以访问其他 DBMS 系统的节点的 IP 地址。使用导出地址可以从 DBMS 系统导入和导出数据。您可以使用此处的说明手动更改导出地址。

如果更改导出地址并运行 re-ip 命令，则导出地址保持不变。

示例

运行以下命令：

=> SELECT node_name, node_address, export_address FROM nodes;
    node_name      | node_address    | export_address
------------------------------------------------------
v_VMartDB_node0001 | 192.168.100.101 | 192.168.100.101
v_VMartDB_node0002 | 192.168.100.102 | 192.168.100.101
v_VMartDB_node0003 | 192.168.100.103 | 192.168.100.101
v_VMartDB_node0004 | 192.168.100.104 | 192.168.100.101
(4 rows)

在上面的示例中，export_address 是默认值。在这种情况下，当您运行 re-ip 命令时，export_address 会更改为新的 node_address。

如果您手动将导出地址更改为此处描述的地址，可能会出现以下情况：

=> SELECT node_name, node_address, export_address FROM nodes;
    node_name      | node_address    | export_address
------------------------------------------------------
v_VMartDB_node0001 | 192.168.100.101 | 10.10.10.1
v_VMartDB_node0002 | 192.168.100.102 | 10.10.10.2
v_VMartDB_node0003 | 192.168.100.103 | 10.10.10.3
v_VMartDB_node0004 | 192.168.100.104 | 10.10.10.4
(4 rows)

在这种情况下，当您运行 re-ip 命令时，export_address 不会发生更改。

查找 IP 地址

主机和节点的 IP 地址存储在 opt/vertica/config/admintools.conf 中：

[Cluster]
hosts = 203.0.113.111, 203.0.113.112, 203.0.113.113

[Nodes]
node0001 = 203.0.113.111/home/dbadmin,/home/dbadmin
node0002 = 203.0.113.112/home/dbadmin,/home/dbadmin
node0003 = 203.0.113.113/home/dbadmin,/home/dbadmin

还可以使用以下命令显示 IP 地址列表：

$ admintools -t list_allnodes
Node             | Host          | State | Version        | DB
-----------------+---------------+-------+----------------+-----------
v_vmart_node0001 | 203.0.113.111 | UP    | vertica-10.1.1 | VMart
v_vmart_node0002 | 203.0.113.112 | UP    | vertica-10.1.1 | VMart
v_vmart_node0003 | 203.0.113.113 | UP    | vertica-10.1.1 | VMart

提示

运行 list_allnodes 工具可帮助确定在访问 Vertica 时可能遇到的任何问题。例如，如果主机不互相通信，则 Version 列将会显示 Unavailable。

1.15.1 - 使用映射文件更改 IP 地址

映射新 IP 地址包括：

创建将旧 IP 地址映射到新 IP 地址的映射文件。
使用映射文件更新配置文件和数据库编录。

如果使用控制消息在主机之间进行通信，您可能还需要使用新的 controlAddress 和 controlBroadcast IP 地址更新 IP 地址。

重要

更改 IP 地址的过程不会更改导出地址和依赖它们的任何功能。在运行 re_ip 之前，请检查是否需要更新子网、网络接口、负载均衡组和负载均衡规则，使其与新的 IP 相匹配。如果不匹配，可能会导致负载均衡或导入/导出失败。

创建映射文件

按如下方式创建映射文件：

获取新 IP 地址并将它们保存在一个文本文件中。

获取旧 IP 地址，使用 list_allnodes:

$ admintools -t list_allnodes
Node             | Host          | State | Version        | DB
-----------------+---------------+-------+----------------+-----------
v_vmart_node0001 | 192.0.2.254   | UP    | vertica-10.1.1 | VMart
v_vmart_node0002 | 192.0.2.255   | UP    | vertica-10.1.1 | VMart
v_vmart_node0003 | 192.0.2.256   | UP    | vertica-10.1.1 | VMart

按以下格式将 Host 列的内容复制到新 IP 地址所保存到的文本文件中：

oldIPaddress newIPaddress

例如：

192.0.2.254 198.51.100.255
192.0.2.255 198.51.100.256
192.0.2.256 198.51.100.257

使用该文本文件创建可用于执行下列任务之一的映射文件：

将 IP 地址从旧 IP 地址更改为新 IP 地址

创建采用如下格式的映射文件：

oldIPaddress newIPaddress[, controlAddress, controlBroadcast]

例如：

192.0.2.254 198.51.100.255, 198.51.100.255, 203.0.113.255
192.0.2.255 198.51.100.256, 198.51.100.256, 203.0.113.255
192.0.2.256 198.51.100.257, 198.51.100.257, 203.0.113.255

controlAddress 和 controlBroadcast 是可选项。如果省略：

controlAddress 将默认为 newIPaddress。
controlBroadcast 将默认为 newIPaddress 的广播 IP 地址的主机。

按如下方式运行 re_ip：
```
$ admintools -t re_ip -f mapfile
```

将 IP 地址从旧 IP 地址更改为新 IP 地址并更改控制消息模式

创建采用如下格式的映射文件：

oldIPaddress newIPaddress, controlAddress, controlBroadcast

例如：

192.0.2.254 198.51.100.255, 203.0.113.255, 203.0.113.258
192.0.2.255 198.51.100.256, 203.0.113.256, 203.0.113.258
192.0.2.256 198.51.100.257, 203.0.113.257, 203.0.113.258

运行 re_ip 并按如下方式更改控制消息传递模式：
- 将控制消息传递模式更改为点对点：
```
$ admintools -t re_ip -d db name -T
```
- 将控制消息传递模式更改为广播：
```
$ admintools -t re_ip -d db name -U
```
  当您使用 -U 选项时，嵌入式消息子系统基于 controlAddress 和 controlBroadcast IP 运行。

仅更改数据库的节点控制 IP 地址

创建采用如下格式的映射文件：

nodeName nodeIPaddress, controlAddress, controlBroadcast

例如：

v_vmart_node0001 192.0.2.254, 203.0.113.255, 203.0.113.258
v_vmart_node0002 192.0.2.255, 203.0.113.256, 203.0.113.258
v_vmart_node0003 192.0.2.256, 203.0.113.257, 203.0.113.258

按如下方式运行 re_ip：

$ admintools -t re_ip -f mapfile -O -d database

有关详细信息，请参阅下面的映射数据库上的 IP 地址。

更改 IP 地址

创建映射文件后，可以更改新 IP 地址。更改 IP 地址过程会自动备份 admintools.conf，以便在必要时恢复原始设置。

停止数据库。

运行 re-ip 以将旧 IP 地址映射到新 IP 地址：

$ admintools -t re_ip -f mapfile

注意

此示例使用的是将 IP 地址从旧 IP 地址更改为新 IP 地址的命令。

如果出现以下情况，则会出现警告：

任何 IP 地址的格式不正确
文件中的旧 IP 地址或新 IP 地址重复 — 例如，192.0.2.256 在旧 IP 地址集中出现了两次。

如果语法正确，则在开始映射时，re_ip 将执行以下任务：

对映射文件中列出的 IP 地址进行重新映射。
除非使用 -i 选项，否则会提示您确认对数据库的更新。
使用新 IP 地址更新要求的本地配置文件。
将更新后的配置文件分发到使用新 IP 地址的主机。

使用以下提示跟踪这些步骤：

Parsing mapfile...
New settings for Host 192.0.2.254 are:

address: 198.51.100.255

New settings for Host 192.0.2.255 are:

address: 198.51.100.256

New settings for Host 192.0.2.254 are:

address: 198.51.100.257

The following databases would be affected by this tool: Vmart

Checking DB status ...
Enter "yes" to write new settings or "no" to exit > yes
Backing up local admintools.conf ...
Writing new settings to local admintools.conf ...

Writing new settings to the catalogs of database Vmart ...
The change was applied to all nodes.
Success. Change committed on a quorum of nodes.

Initiating admintools.conf distribution ...
Success. Local admintools.conf sent to all hosts in the cluster.

重新启动数据库。

映射数据库上的 IP 地址

您只能映射数据库的 IP 地址。此任务涉及将数据库中的节点名称映射到新 IP 地址。这对于错误恢复很有用，因为 admintools.conf 不会更新。Vertica 仅更新 spread.conf 和包含更改的编录。

还可以仅映射数据库上的 IP 地址，以便在单个数据库上设置 controlAddress 和 controlBroadcast。此任务允许同一主机上的节点拥有不同的数据和 controlAddress。

停止数据库。

创建具有如下格式的映射文件：

nodeName IPaddress, controlAddres, controlBroadcast

例如：

vertica_node001 192.0.2.254, 203.0.113.255, 203.0.113.258
vertica_node002 192.0.2.255, 203.0.113.256, 203.0.113.258
vertica_node003 192.0.2.256, 203.0.113.257, 203.0.113.258

运行以下命令以映射新 IP 地址：

$ admintools -t re_ip -f mapfile -O -d database

重新启动数据库。

1.15.2 - Re-IP 命令行选项

re_ip 支持以下选项：

-h \--help

显示 re_ip 的联机帮助。

-f mapfile \--file=mapfile

映射文本文件的名称。文件内容取决于 re-IP 操作的类型。请参阅。

-O \--dba-only

用于进行错误恢复，更新和替换数据库群集编录和控制消息传递系统上的数据。如果映射文本文件失败，Vertica 会在您重新运行该命令时自动重新创建映射文本文件。映射文本文件的格式为：

NodeName AssociatedNodeIPAddress, new ControlAddress, new ControlBroadcast

NodeName 和 AssociatedNodeIPAddress 必须与 admintools.conf 中相同。

此选项一次只更新一个数据库，因此它需要使用 -d 选项：

$ admintools -t re_ip -f mapfile -O -d database

-i \--noprompts

指定系统在执行更改 IP 地址操作之前不提示验证新设置。默认情况下，提示功能处于打开状态。

-T \--point-to-point

将控制消息传递设置为点对点（单播）协议。此选项一次只更新一个数据库，因此它需要使用 -d 选项：此选项不需要映射文本文件。

-U \--broadcast

将控制消息传递设置为广播协议。此选项一次只更新一个数据库，因此必须使用 -d 选项：对于此选项，不需要映射文本文件。

-d database name \--database=database name

数据库名称，对于以下 re-IP 选项是必需项：

-O
-T
-U

1.15.3 - 重新启动具有新主机 IP 的节点

仅限 Kubernetes

注意

有关在非 Kubernetes 数据库上重新映射节点 IP 地址的信息，请参阅映射新 IP 地址。

Kubernetes 上 Eon 模式数据库的节点 IP 地址偶尔必定会更新 — 例如，pod 失败、添加到群集中或进行重新调度。发生这种情况时，必须使用受影响节点的新 IP 地址更新 Vertica 编录并重新启动节点。

注意

不能将现有的数据库群集从一个地址族切换到另一个地址族。例如，不能将数据库中节点的 IP 地址从 IPv4 更改为 IPv6。

Vertica 的 restart_node 工具通过其 --new-host-ips 选项（该选项允许您更改在 Kubernetes 上运行的 Eon 模式数据库的节点 IP 地址）满足这些要求，并重新启动已更新的节点。与在其他（非 Kubernetes）数据库上重新映射节点 IP 地址不同，您可以在正运行的数据库中的各个节点上执行此任务：

admintools -t restart_node \
  {-d db-name |--database=db-name} [-p password | --password=password] \
  {{-s nodes-list | --hosts=nodes-list} --new-host-ips=ip-address-list}

nodes-list 是要重新启动的节点的逗号分隔列表。列表中的所有节点都必须处于关闭状态，否则 admintools 会返回错误。
ip-address-list 是分配给指定节点的新 IP 地址或主机名的逗号分隔列表。

注意
由于主机名解析为 IP 地址，因此 Vertica 建议使用 IP 地址来消除不必要的复杂性。

以下要求适用于 nodes-list 和 ip-address-list：

节点主机数和 IP 地址或主机名必须相同。
列表不得包含任何嵌入空格。

例如，可以使用新 IP 地址重新启动节点 v_k8s_node0003：

$ admintools -t list_allnodes
  Node           | Host       | State    | Version        | DB
 ----------------+------------+----------+----------------+-----
  v_k8s_node0001 | 172.28.1.4 | UP       | vertica-10.1.1 | K8s
  v_k8s_node0002 | 172.28.1.5 | UP       | vertica-10.1.1 | K8s
  v_k8s_node0003 | 172.28.1.6 | DOWN     | vertica-10.1.1 | K8s

$ admintools -t restart_node -s v_k8s_node0003 --new-host-ips 172.28.1.7 -d K8s
 Info: no password specified, using none
*** Updating IP addresses for nodes of database K8s ***
        Start update IP addresses for nodes
         Updating node IP addresses
         Generating new configuration information and reloading spread
*** Restarting nodes for database K8s ***
         Restarting host [172.28.1.7] with catalog [v_k8s_node0003_catalog]
         Issuing multi-node restart
         Starting nodes:
                 v_k8s_node0003 (172.28.1.7)
         Starting Vertica on all nodes. Please wait, databases with a large catalog may take a while to initialize.
         Node Status: v_k8s_node0003: (DOWN)
         Node Status: v_k8s_node0003: (DOWN)
         Node Status: v_k8s_node0003: (DOWN)
         Node Status: v_k8s_node0003: (DOWN)
         Node Status: v_k8s_node0003: (RECOVERING)
         Node Status: v_k8s_node0003: (UP)
$ admintools -t list_allnodes
  Node           | Host       | State | Version        | DB
 ----------------+------------+-------+----------------+-----
  v_k8s_node0001 | 172.28.1.4 | UP    | vertica-10.1.1 | K8s
  v_k8s_node0002 | 172.28.1.5 | UP    | vertica-10.1.1 | K8s
  v_k8s_node0003 | 172.28.1.7 | UP    | vertica-10.1.1 | K8s

2 - 管理磁盘空间

Vertica 检测并在日志文件中报告磁盘空间不足的情况，这样，您就可以先解决该问题，以防发生严重问题。它还会通过 SNMP 陷阱（如果已启用）检测和报告磁盘空间不足的情况。

关键磁盘空间问题的报告速度比其他问题快。例如，编录空间不足属于严重情况；因此，Vertica 报告该情况将早于不那么关键的情况。要在磁盘空间低于特定阈值时避免数据库发生损坏，Vertica 将开始拒绝更新编录或数据的事务。

当心

磁盘空间不足报告指示一个或多个主机正在磁盘空间不足的状态下运行，或者存在故障磁盘。必须尽快添加更多磁盘空间（或更换故障磁盘）。

当 Vertica 报告磁盘空间不足的情况时，请使用 DISK_RESOURCE_REJECTIONS 系统表确定将拒绝的磁盘空间请求的类型和将拒绝请求的主机。

要添加磁盘空间，请参阅为节点添加磁盘空间。要更换故障磁盘，请参阅更换故障磁盘。

监控磁盘空间使用情况

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

2.1 - 为节点添加磁盘空间

此过程介绍如何为 Vertica 群集中的节点添加磁盘空间。

注意

如果为群集中的多个节点添加磁盘空间，可将以下过程用于每个节点（一次一个节点）。

要为节点添加磁盘空间：

如果您必须关闭正向其中添加磁盘空间的硬件，则首先在添加磁盘空间的主机上关闭 Vertica。
根据硬件环境的要求为系统添加新磁盘。启动硬件（如果硬件已关闭）
根据硬件环境的需求对新磁盘进行分区、格式化和挂载。
在新卷上创建数据目录路径。

例如：
```
mkdir –p /myNewPath/myDB/host01_data2/
```
如果您关闭硬件，请在主机上重新启动 Vertica。
打开与 Vertica 的数据库连接，然后添加一个存储位置，以添加新数据目录路径。在 CREATE LOCATION 中指定节点，否则 Vertica 会认为您在所有节点上创建存储位置。

请参阅本指南中的创建存储位置，以及《SQL 参考手册》中的 CREATE LOCATION 语句。

2.2 - 更换故障磁盘

如果数据或编录目录所在的磁盘出现故障，导致完全或部分磁盘数据丢失，请执行以下步骤：

更换磁盘并重新创建数据或编录目录。
将配置文件 ( vertica.conf) 分配到新主机。有关详细信息，请参阅将配置文件分配到新主机。
如在主机上重新启动 Vertica 中所述，在主机上重新启动 Vertica。

有关查找 DATABASE_HOME_DIR 的信息，请参阅编录和数据文件。

2.3 - 编录和数据文件

为使恢复过程成功完成，编录和数据文件必须位于正确的目录中。

在 Vertica 中，编录是一个文件集，其中包含数据库中的对象（例如，节点、表、约束和投影）的相关信息（元数据）。编录文件会在群集中的所有节点上进行复制，而数据文件对于每个节点都是唯一的。这些文件默认安装在以下目录中：

/DATABASE_HOME_DIR/DATABASE_NAME/v_db_nodexxxx_catalog/ /DATABASE_HOME_DIR/DATABASE_NAME/v_db_nodexxxx_catalog/

注意

DATABASE_HOME_DIR 是管理工具中显示的路径。有关使用该界面的详细信息，请参阅《管理员指南》中的使用管理工具。

要查看数据库路径：

运行管理工具。
```
$ /opt/vertica/bin/admintools
```
从主菜单中，选择配置菜单 (Configuration Menu)，然后单击确定 (OK)。
选择查看数据库 (View Database)，然后单击确定 (OK)。
选择要查看的数据库，然后单击确定 (OK) 以查看数据库配置文件。

有关编录目录的内容解释，请参阅了解编录目录。

2.4 - 了解编录目录

编录目录用于存储数据库的元数据和支持文件。此目录中的一些文件可帮助您解决数据加载问题或其他数据库问题。有关查找数据库编录目录的说明，请参阅编录和数据文件。默认情况下，编录目录位于数据库目录中。例如，如果您在数据库管理员帐户中创建了 Vmart 数据库，则编录目录的路径为：

/home/dbadmin/VMart/v_vmart_nodennnn_catalog

其中 nodennnn 是您所登录的节点的名称。每个节点的编录目录名称是唯一的，但每个节点的大部分编录目录内容都是相同的。

下表说明了编录目录中可能显示的文件和目录。

注意

请勿更改或删除编录目录中的任何文件，除非 Vertica 支持人员要求您这样做。

2.5 - 从已删除的表数据中回收磁盘空间

您可以通过多种方式从已删除的表数据中回收磁盘空间：

3 - 内存使用报告

Vertica 定期轮询自己的内存使用情况，以确定它是否低于由配置参数 MemoryPollerReportThreshold 设置的阈值。轮询按照配置参数 MemoryPollerIntervalSec 的设置定期发生（默认情况下每 2 秒轮询一次）。

内存轮询器将 MemoryPollerReportThreshold 与以下表达式进行比较：

RSS / available‑memory

当此表达式的计算结果大于 MemoryPollerReportThreshold（默认设置为 0.93）时，内存轮询器会将报告写入 Vertica 工作目录中的 MemoryReport.log。此报告包括有关 Vertica 内存池、单个查询和会话消耗的内存量等信息。内存轮询器还将报告作为事件记录在系统表 MEMORY_EVENTS 中，并设置 EVENT_TYPE 为 MEMORY_REPORT。

内存轮询器还会检查由 glibc 分配的可用内存是否过多（glibc 内存膨胀）。有关详细信息，请参阅内存修剪。

4 - 内存修剪

在某些工作负载下，glibc 会累积其分配区域中的大量可用内存。该内存消耗由常驻集大小 (RSS) 指示的物理内存，glibc 并不总是将物理内存返回给操作系统。glibc 对物理内存的高保留（glibc 内存膨胀）会对其他进程产生不利影响，并且在高工作负载下，有时会导致 Vertica 内存不足。

Vertica 提供了两个配置参数，让您可以控制 Vertica 检测和合并由 glibc 分配的大量可用内存的频率，然后将其返回给操作系统：

MemoryPollerTrimThreshold：设置内存轮询器开始检查是否修剪 glibc 所分配内存的阈值。
内存轮询器将 MemoryPollerTrimThreshold（默认设置为 0.83）与以下表达式进行比较：
```
RSS / available‑memory
```
如果此表达式的计算结果大于 MemoryPollerTrimThreshold，则内存轮询器开始检查下一个阈值（在 MemoryPollerMallocBloatThreshold 中设置）是否存在 glibc 内存膨胀。

注意
在存在非典型的超高 Vertica RSS 值的高内存计算机上，请考虑为 MemoryPollerTrimThreshold 设置更高的设置。要关闭自动修剪，请将此参数设置为 0。
MemoryPollerMallocBloatThreshold：设置 glibc 内存膨胀的阈值。
内存轮询器将调用 glibc 函数 malloc_info()，以获取 malloc 中的空闲内存量。然后它将 MemoryPollerMallocBloatThreshold（默认设置为 0.3）与以下表达式进行比较：
```
free‑memory‑in‑malloc / RSS
```
如果此表达式的计算结果大于 MemoryPollerMallocBloatThreshold，内存轮询器将调用 glibc 函数 malloc_trim()。此函数从 malloc 中回收空闲内存，并将其返回给操作系统。调用 malloc_trim() 的详细信息将写入系统表 MEMORY_EVENTS。

例如，当满足以下条件时，内存轮询器调用 malloc_trim()：
- MemoryPollerMallocBloatThreshold 设置为 0.5。
- malloc_info() 返回 malloc 中的 15GB 可用内存。
- RSS 为 30GB。
注意
如果 MemoryPollerTrimThreshold 设置为 0（禁用），则忽略此参数。

手动修剪内存

如果禁用自动修剪，您可以通过调用 Vertica 函数 MEMORY_TRIM 手动减少由 glibc 分配的内存。此函数调用 malloc_trim()。

5 - Tuple mover

Tuple Mover 管理 ROS 数据存储。在合并时，它会将较小的 ROS 容器合并到较大的 ROS 容器中并清除已删除的数据。Tuple Mover 在后台自动执行这些任务。

数据库模式会影响哪些节点执行 Tuple Mover 操作：

在企业模式数据库中，所有节点都运行 Tuple Mover 以对它们存储的数据执行合并操作。
在 Eon 模式下，每个分片的主订户都针对该分片中的 ROS 容器计划 Tuple Mover 合并操作。它可以将此计划的执行权委托给群集中的另一个节点。

Tuple Mover 操作通常不需要干预。但是，Vertica 提供了多种调整 Tuple Mover 行为的方法。有关详细信息，请参阅管理 Tuple Mover。

Eon 模式数据库中的 Tuple Mover

在 Eon 模式中，Tuple Mover 的操作分为两部分：合并计划和合并执行。合并计划总是由参与合并的分片的主订户执行。这些主订户是同一主子群集的一部分。作为合并计划的一部分，主订户选择一个节点来执行合并计划。它使用两个标准来决定哪个节点应该执行合并：

只有为其 TM 资源池分配了内存的节点才有资格执行合并。主订户忽略其 TM 池的 MEMORYSIZE 和 MAXMEMORYSIZE 的设置为 0 的子群集中的所有节点。
从能够执行合并的节点组中，主订户选择其存储库中包含最多 ROS 容器的节点，这些容器参与合并。

限制哪些子群集执行合并任务

可以通过将辅助子群集的 TM 池的 MEMORYSIZE 和 MAXMEMORYSIZE 设置更改为 0 来禁止为辅助子群集分配合并任务。这些设置阻止主订户将合并任务分配给子群集中的节点。

重要

主子群集必须始终能够执行合并任务。仅在辅助子群集上更改这些设置。

例如，此语句禁止名为 dashboard 的子群集运行合并任务。

=> ALTER RESOURCE POOL TM FOR SUBCLUSTER dashboard MEMORYSIZE '0%'
   MAXMEMORYSIZE '0%';

5.1 - 合并

“合并”是用于合并 ROS 容器并清除已删除记录的Tuple Mover 进程。 DML 活动（例如 COPY 和数据分区）会生成新的 ROS 容器，这些容器通常需要整合，而删除数据和对数据重新分区则需要重组现有容器。Tuple Mover 持续监控这些活动，并根据需要执行合并以整合和重组容器。这样做，Tuple Mover 为的是避免两个问题：

当列数据分散在多个 ROS 容器中时，性能会下降。
当给定投影的 ROS 容器的增长速度超过 Tuple Mover 的处理速度时，存在 ROS 推回的风险。一个投影最多可以有 1024 个 ROS 容器；当达到该限制时，Vertica 开始在所有的投影查询尝试中返回 ROS 推回错误。

5.1.1 - 合并请求类型和优先级

Tuple Mover 持续监控所有生成新 ROS 容器的活动。这样做时，它会创建合并请求并根据类型对它们进行排队。这些类型如下所示，按优先级降序排列：

RECOMPUTE_LIMITS：设置 Tuple Mover 用于确定何时对投影的新合并请求进行排队的标准。此请求类型在以下两种情况下排队：
- 创建投影时。
- 当现有投影发生更改时（例如添加或删除列），或者影响该投影的 ROS 存储的配置参数（如 ActivePartitionCount）发生更改时。
MERGEOUT：整合新容器。这些容器通常包含来自最近加载活动或表分区的数据。
DVMERGEOUT：整合具有删除标记（或删除向量）的数据。
PURGE：从容器中清除过期的删除向量。

Tuple Mover 还监控为每个投影创建容器的频率，以确定哪些投影可能面临 ROS 推回的风险。投影上的密集 DML 活动通常会导致容器创建速率很高。Tuple Mover 监控 MERGEOUT 和 DVMERGEOUT 请求，并在每个集合中根据请求的投影活动级别确定请求的优先级。对具有最高容器创建速率的投影的合并请求将获得立即执行的优先级。

注意

Tuple Mover 经常推迟对具有较低加载活动级别的投影的合并。这些投影的合并可能会保持暂停状态，直到投影达到排队合并请求的内部阈值，

5.1.2 - 计划的合并

Tuple Mover 定期检查合并队列中是否有待定请求，检查间隔由配置参数 MergeOutInterval 设置：

如果队列包含合并请求，则 Tuple Mover 不执行任何操作并重新进入睡眠状态。
如果队列为空，Tuple Mover：
- 处理待处理的存储位置移动请求。
- 检查新的未排队清除请求并将它们添加到队列中。
然后它重新进入睡眠状态。

默认情况下，此参数设置为 600（秒）。

重要

计划的合并独立于 Tuple Mover 服务，该服务持续监控合并请求并根据需要执行它们。

5.1.3 - 用户调用的合并

您可以随时通过调用 Vertica 元函数 DO_TM_TASK 来对一个或多个投影调用合并操作：

DO_TM_TASK('mergeout'[, '[[database.]schema.]{table | projection} ]')

该函数扫描指定范围内的数据库编录以确定待定的合并任务。如果未指定表或投影，则 DO_TM_TASK 扫描整个编录。与在 TM 资源池中运行的连续 TM 服务不同，DO_TM_TASK 在 GENERAL 池中运行。如果 DO_TM_TASK 执行合并请求队列中待定的合并任务，TM 服务会从队列中移除这些任务而不采取任何操作。

5.1.4 - 分区合并

Vertica 将来自不同表分区或分区组的数据在磁盘上分开保存。Tuple Mover 在整合 ROS 容器时遵循此分离策略。首次创建某个分区时，它通常会频繁加载数据，而且需要 Tuple Mover 的定期活动。随着分区的老化，它通常会转变为一个基本上只读的工作负载，并且需要的活动要少得多。

Tuple Mover 有两个不同的策略，用于管理这些不同的分区工作负载：

活动分区是最近创建的分区。Tuple Mover 使用基于层的算法，旨在最大限度减少各个元组进行合并的次数。表的活动分区计数确定该表有多少个处于活动状态的分区。
非活动分区是指那些不是最近创建的分区。Tuple Mover 将 ROS 容器整合至极小集，同时避免合并大小超过 MaxMrgOutROSSizeMB 的容器。

注意

如果您使用 Vertica 元函数 DO_TM_TASK 调用合并，所有分区（包括活动分区）都合并到尽可能少的容器中。

有关 Tuple Mover 如何确定活动分区的详细信息，请参阅活动和非活动分区。

分区合并线程分配

TM 资源池使用其 MAXCONCURRENCY 参数设置可用于合并的线程数。默认情况下，此参数设置为 7。Vertica 将一半线程分配给活动分区，其余一半分配给活动和非活动分区。如果 MAXCONCURRENCY 设置为奇整数，Vertica 会向上舍入以支持处于活动状态的分区。

例如，如果 MAXCONCURRENCY 设置为 7，则 Vertica 会将四个线程专门分配给活动分区，并根据需要将其余的三个线程分配给活动和非活动分区。如果需要额外的线程来避免 ROS 推回，请使用 ALTER RESOURCE POOL 增加 MAXCONCURRENCY。

5.1.5 - 删除标记合并

当您从数据库中删除数据时，Vertica 并未移除该数据，而是将其标记为已删除。如果使用许多 DELETE 语句标记少数几行（相对于表大小而言），则会导致创建许多小型容器（删除向量）来保存具有删除标记的数据。每一个删除向量容器都会消耗资源，因此这样的容器如果很多，则会对性能产生不利影响，尤其是在恢复期间。

在 Tuple Mover 执行合并后，它会查找包含少量条目的删除标记容器。如果存在这样的容器，Tuple Mover 会将它们合并到一个更大的容器中。此过程会释放多个容器所使用的资源，从而有助于降低跟踪已删除数据所需的开销。Tuple Mover 并不清除已删除的数据，也不对已删除的数据产生任何影响，只是整合删除向量以提高效率。

提示

查询系统表 DELETE_VECTORS 可以查看用来存储已删除数据的容器的数量和大小。

5.1.6 - 针对特定表禁用合并

默认情况下，对所有表及其投影启用合并。可以使用 ALTER TABLE 在表上禁用合并。例如：

=> ALTER TABLE public.store_orders_temp SET MERGEOUT 0;
ALTER TABLE

通常，对于为临时目的（例如，用于对旧分区数据进行存档或在表之间交换分区的临时表）而创建的表禁用合并很有用，在任务完成后，很快就会删除这些表。这样做，便可以避免与合并相关的表开销。

您可以查询系统表 TABLES 以确定已禁用合并的表：


=> SELECT table_schema, table_name, is_mergeout_enabled FROM v_catalog.tables WHERE is_mergeout_enabled= 0;
 table_schema |    table_name     | is_mergeout_enabled
--------------+-------------------+---------------------
 public       | store_orders_temp | f
(1 row)

5.1.7 - 清除 ROS 容器

Vertica 定期检查 ROS 存储容器以确定删除向量是否符合清除条件，如下所示：

计算每个容器中过期删除向量的个数，即等于或早于 Ancient History Mark (AHM) 时期的删除向量。
计算过期删除向量相对于同一 ROS 容器中记录总数的百分比。
如果此百分比超过由配置参数 PurgeMergeoutPercent 设置的阈值（默认为 20%），Vertica 会自动对 ROS 容器执行合并，从而永久移除所有过期的删除向量。Vertica 使用 TM 资源池的 MAXCONCURRENCY 设置来确定可用于合并操作的线程数。

还可以使用两个 Vertica 元函数从 ROS 容器中手动清除所有过期的删除向量：

这两个函数都从 ROS 容器中移除所有过期的删除向量，而与给定容器中有多少删除向量无关。

5.1.8 - 合并分层算法

合并操作使用基于层的算法来验证每个元组是否都经历少量恒定次数的合并操作，而不考虑用来加载数据的过程。合并操作使用此算法来选择要为非分区表和分区表中处于活动状态的分区合并哪些 ROS 容器。

Vertica 为每个处于活动状态的分区和锚定到非分区表的投影构建层。层数、每个层的大小和层中的最大 ROS 容器数根据磁盘大小、内存和投影中的列数计算得出。

先合并小 ROS 容器后合并大 ROS 容器可以在合并过程中获得最大的好处。该算法从第 0 层开始并向上移动。它检查层中的 ROS 容器数是否已达到等于或大于每个层允许的最大 ROS 容器数的值。默认值为 32。如果算法发现一个层已满，它会将投影和该层标记为满足合并条件。

5.2 - 管理 Tuple Mover

Tuple Mover 已预先配置为处理典型的工作负载。但是，某些情况可能需要您调整 Tuple Mover 行为。您可以通过多种方式执行此操作：

[配置 TM 资源池](#Configur)。
管理处于活动状态的数据分区。

配置 TM 资源池

Tuple Mover 使用内置的 TM 资源池来处理其工作负载。可以调整此资源池的几个设置以方便处理大量负载：

MEMORYSIZE
MAXMEMORYSIZE
MAXCONCURRENCY
PLANNEDCONCURRENCY

MEMORYSIZE

指定为每个节点的 TM 池保留多少内存。TM 池可以通过从 GENERAL 池中借用内存而超过这个下限。默认情况下，此参数设置为可用内存的 5%。如果 GENERAL 资源池的 MEMORYSIZE 也设置为一定的百分比，则 TM 池会与 GENERAL 池争用内存。此值必须始终小于或等于 MAXMEMORYSIZE 设置。

当心

将 MEMORYSIZE 增加到很大的百分比可能会导致在 GENERAL 池中运行的内存敏感型查询出现回归。

MAXMEMORYSIZE

设置可分配给 TM 池的内存上限。TM 池可以通过从 GENERAL 池中借用内存而超过由 MEMORYSIZE 设置的值。此值必须始终等于或大于 MEMORYSIZE 设置。

在 Eon 模式数据库中，如果在子群集级别将此值设置为 0，则 Tuple Mover 在子群集上处于禁用状态。

重要

切勿在

主子群集上将 TM 池的 MAXMEMORYSIZE 设置为 0。主子群集必须始终运行 Tuple Mover。

MAXCONCURRENCY

在所有节点上设置 TM 池可用的最大并发执行槽数。在 Vertica ≥9.3 版本中创建的数据库中，默认值为 7。在早期版本中创建的数据库中，默认值为 3。此设置指定可以在多个线程上同时发生的最大合并数。

PLANNEDCONCURRENCY

指定要在资源池中跨所有节点并发执行的查询的首选数量，默认设置为 6。资源管理器使用 PLANNEDCONCURRENCY 来计算对于给定查询可用的目标内存：

TM-memory-size / PLANNEDCONCURRENCY

对于 TM 池，PLANNEDCONCURRENCY 设置必须与 RAM、CPU 和存储子系统的大小成比例。根据存储类型的不同，如果增加 Tuple Mover 线程的 PLANNEDCONCURRENCY，可能会产生存储 I/O 瓶颈。监控存储子系统；如果其充满长 I/O 队列、多于 2 个 I/O 队列以及读写延迟时间长，请调整 PLANNEDCONCURRENCY 参数以使存储子系统资源保持在饱和级别以下。

管理处于活动状态的数据分区

Tuple Mover 假定分区表的所有加载和更新都是针对一个或多个标识为活动的分区。通常，具有最大分区键的分区（通常是最近创建的分区）均视为活动分区。随着分区的老化，其工作负载通常会缩小，并大多变为只读状态。

您可以按优先级的升序指定两个级别的分区表的活动分区数：

配置参数 ActivePartitionCount 将确定数据库中分区表的活动分区数。默认情况下，ActivePartitionCount 设置为 1。Tuple Mover 会将此设置应用于自身未设置活动分区计数的所有表。
通过使用 CREATE TABLE 和 ALTER TABLE 设置各个表自身的活动分区计数，可以取代各个表的 ActivePartitionCount。

有关详细信息，请参阅活动和非活动分区。

另请参阅

工作负载资源管理最佳实践

6 - 管理工作负载

Vertica 的资源管理架构支持在数据库中高效地运行不同的并发工作负载。对于基本操作，Vertica 会根据 RAM 和计算机内核数预配置内置 GENERAL 池。可以自定义 GENERAL 池，以便处理特定的并发要求。

也可以定义新的资源池并对其进行配置，以限制内存使用量、并发和查询优先级。之后，您可以视情况指定每个数据库用户使用特定资源池，以便控制其请求所占用的内存资源。

如果不同类别的工作负载之间存在资源争用需求，则用户定义的池很有用。示例场景如下：

一个大型批处理作业占用了所有服务器资源，导致更新网页的小型作业资源不足。这会降低用户体验。

在此场景中，可创建一个资源池来处理网页请求并确保用户获得所需的资源。也可以为批处理作业创建一个受限的资源池，以使该作业不能用尽所有系统资源。
某个应用程序的优先级低于其他应用程序，且您要限制低优先级应用程序的内存使用量和并发用户数。

在此场景中，可创建一个设有查询内存上限的资源池并将该池与低优先级应用程序的用户关联起来。

还可以使用资源池管理分配给正在运行的查询的资源。可以为资源池分配运行时优先级以及一个阈值，为持续时间不同的查询分配不同的优先级。有关详细信息，请参阅在查询运行时管理资源。

Enterprise 模式和 Eon 模式

在企业模式下，整个数据库有一组全局资源池。在 Eon 模式下，您可以在全局或按子群集分配资源。有关详细信息，请参阅管理 Eon 模式数据库中的工作负载资源。

6.1 - 资源管理器

在单用户环境中，系统可以将所有资源用于单个查询，使该查询得到最有效率的执行。您的环境更有可能需要同时运行几个查询，因此难以做到为每个查询提供最大数量的资源（运行时间最快），同时又能以合理运行时间同时为多个查询提供服务。

Vertica 资源管理器可以解决此矛盾，同时确保每个查询最终得到服务，实际系统限制始终被顾及。

例如，在系统面临资源压力时，资源管理器可能会对查询进行排队，直到资源可用或达到超时值。另外，在配置各个资源管理器设置时，您可以根据针对系统运行的并发查询的预期数量来优化每个查询的目标内存。

资源管理器对执行查询的影响

资源管理器以各种方式影响单个查询的执行。将查询提交到数据库时，会发生以下一系列事件：

对查询进行解析、通过优化查询确定执行计划，然后将查询分发到参与节点。
在每个节点上调用资源管理器，以评估运行查询所需的资源并与当前使用的资源进行比较。将发生下列情况之一：
- 如果查询本身所需的内存超过计算机的物理内存，则会拒绝查询，即查询可能无法运行。除了配置明显不足的节点外，这种情况几乎不会出现。
- 如果当前无法满足资源要求，查询则会排队等候。查询将保留在队列中，直到有足够的资源释放出来后才会运行；若超时，查询则会被拒绝。
- 其他情况下允许查询运行。
当所有参与节点都允许查询运行时，查询即会开始运行。

注意

查询运行后，资源管理器将使用 RUNTIMEPRIORITY 和 RUNTIMEPRIORITYTHRESHOLD 参数进一步管理资源池的资源分配。有关详细信息.，请参阅在查询运行时管理资源。

特定查询的资源分配和允许运行的最大查询数量取决于资源池配置。请参阅资源池架构。

在每个节点上，不会为处于队列中的查询保留或保存任何资源。但是，在某些节点上排队的多节点查询将持有其他节点上的资源。在这种情况下，Vertica 会竭力避免发生死锁。

6.2 - 资源池架构

资源管理器将资源处理为一个或多个资源池，这些池是使用关联队列预先分配的系统资源子集。

在企业模式下，有一组全局资源池适用于整个数据库中的所有子群集。在 Eon 模式下，您可以在全局或按子群集分配资源。全局级资源池适用于所有子群集。子群集级别的资源池允许您针对子群集执行的工作负载类型微调资源。如果您同时具有全局和子群集级别的资源池设置，则可以覆盖该子群集的任何与内存相关的全局设置。全局设置适用于没有子群集级别资源池设置的子群集。有关微调每个子群集的资源池的详细信息，请参阅管理 Eon 模式数据库中的工作负载资源。

Vertica 预配置了一组内置池，这些池将资源分配给不同请求类型，其中的 GENERAL 池根据计算机中的 RAM 和内核允许某种并发级别。

修改和创建资源池

可以根据实际的并发要求和性能要求配置内置的 GENERAL 池，如内置池中所述。也可以创建自定义池以处理各种类别的工作负载并可选择将用户请求限制在自定义池范围内。

您可以使用 CREATE RESOURCE POOL 创建用户定义的资源池，使用 ALTER RESOURCE POOL 修改用户定义的资源池。您可以针对内存使用、并发性和队列优先级配置这些资源池。您还可以将数据库用户或用户会话限制为使用特定的资源池。这样做可以让您控制内存、CPU 和其他资源的分配方式。

下图说明了在哪个资源池中执行了哪些数据库操作。仅显示了三个内置池。

6.2.1 - 定义辅助资源池

您可以定义正在运行的查询在超出初始资源池的 RUNTIMECAP 时可以级联到的辅助资源池。

确定辅助池

通过定义辅助资源池，您可以指定一个位置，超出正在运行查询的资源池的 RUNTIMECAP 的查询可以在该位置执行。这样，如果某个查询超出池的 RUNTIMECAP，该查询可级联至具有更大 RUNTIMECAP 的池，而不会导致错误。当查询级联到另一个池时，原始池将重新获得此查询使用的内存。

因为不考虑在辅助池上授予权限，所以您可以使用此功能为用户查询指定辅助资源池而无需为用户提供在该池上运行查询的明确权限。

您还可使用辅助池来存储长时间运行的查询，以便日后使用。使用 PRIORITY HOLD 选项，您可以指定一个对队列重新排队的辅助池，直至达到 QUEUETIMEOUT 或者池的优先级更改为非保留值。

在 Eon 模式下，为特定于子群集的资源池定义辅助资源池时，需遵循以下限制：

全局资源池只能级联到其他全局资源池。

特定于子群集的资源池可以级联到全局资源池，或级联到属于同一子群集的另一个特定于子群集的资源池。如果子群集特定资源池级联到全局和子群集级别中均具有的用户定义资源池，则优先子群集级别资源池。例如：

=> CREATE RESOURCE POOL billing1;
=> CREATE RESOURCE POOL billing1 FOR CURRENT SUBCLUSTER;
=> CREATE RESOURCE POOL billing2 FOR CURRENT SUBCLUSTER CASCADE TO billing1;
WARNING 9613:  Resource pool billing1 both exists at both subcluster level and global level, assuming subcluster level
CREATE RESOURCE POOL

查询级联路径

当达到初始池上的 RUNTIMECAP 时，Vertica 会将查询路由到辅助池。然后，Vertica 检查辅助池的 RUNTIMECAP 值。如果辅助池的 RUNTIMECAP 大于初始池的值，查询将在辅助池上执行。如果辅助池的 RUNTIMECAP 小于或等于初始池的值，Vertica 将在链中的下一个池上重新尝试查询，直至找到一个 RUNTIMECAP 大于初始池值的池。如果此时辅助池没有足够的可用资源来执行查询，SELECT 查询可能会在该池上重新排队、重新计划和中止。其他类型的查询会因为资源不足而失败。如果查询不存在合适的辅助池，查询将出现错误。

下图演示了执行查询时采用的路径。

查询执行时间分配

在 Vertica 找到用于运行查询的相应池之后，它会继续不间断地执行该查询。现在，查询在用于完成查询的两个池的 RUNTIMECAP 限制方面存在一些差异：

query execution time allocation = rp2 RUNTIMECAP - rp1 RUNTIMECAP

使用 CASCADE TO 参数

作为超级用户，您可以使用 CREATE RESOURCE POOL 或 ALTER RESOURCE POOL 语句中的 CASCADE TO 参数来识别辅助池。辅助池必须已作为用户定义的池或 GENERAL 池存在。使用 CASCADE TO 时，不能创建资源池循环。

此示例说明了一个场景，其中管理员希望 user1 的查询在 user_0 资源池上启动，但在查询过长时级联到 userOverflow 池。


=> CREATE RESOURCE POOL userOverflow RUNTIMECAP '5 minutes';
=> CREATE RESOURCE POOL user_0 RUNTIMECAP '1 minutes' CASCADE TO userOverflow;
=> CREATE USER "user1" RESOURCE POOL user_0;

在此场景中，user1 无法在 userOverflow 资源池上启动他或她的查询，但由于不考虑为辅助池授予权限，因此如果辅助池超出 user_0 池的 RUNTIMECAP，user1 的查询可以级联到 userOverflow 池。使用辅助池会释放主要池中的空间，因此可以运行简短的查询。

此示例显示了一个场景，即管理员想要长时间运行的查询在辅助池上保持排队状态。

=> CREATE RESOURCE POOL rp2 PRIORITY HOLD;
=> CREATE RESOURCE POOL rp1 RUNTIMECAP '2 minutes' CASCADE TO rp2;
=> SET SESSION RESOURCE_POOL = rp1;

在此场景中，在 rp1 上运行超过 2 分钟的查询将在 rp2 上排队，直至达到 QUEUETIMEOUT，此时查询将被拒绝。

如果您尝试删除的资源池是另一个资源池的辅助池，则 Vertica 会返回一个错误。该错误会列出与您尝试删除的辅助池有关的资源池。要删除辅助资源池，首先在主要资源池上将 CASCADE TO 参数设置为 DEFAULT，然后再删除辅助池。

例如，可以删除资源池 rp2，它是 rp1 的辅助池，如下：

=> ALTER RESOURCE POOL rp1 CASCADE TO DEFAULT;
=> DROP RESOURCE POOL rp2;

参数注意事项

当查询进入辅助池时，该池的 CPUAFFINITYSET 和 CPUAFFINITYMODE 会应用于该查询。

查询会根据以下情况在不同时间采用辅助池的 RUNTIMEPRIORITY：

如果当查询在主要池中运行时未启动 RUNTIMEPRIORITYTHRESHOLD 计时器，查询会在级联时采用辅助池的 RUNTIMEPRIORITY。当未设置主要池的 RUNTIMEPRIORITYTHRESHOLD 时或者将主要池的 RUNTIMEPRIORITY 设置为 HIGH 时，即会发生上述情况。
如果达到主要池的 RUNTIMEPRIORITYTHRESHOLD，查询会在级联时采用辅助池的 RUNTIMEPRIORITY。
如果未达到主要池的 RUNTIMEPRIORITYTHRESHOLD 并且辅助池没有阈值，查询会在级联时采用新池的 RUNTIMEPRIORITY。
如果未达到主要池的 RUNTIMEPRIORITYTHRESHOLD 并且辅助池设置了一个阈值：
- 如果主要池的RUNTIMEPRIORITYTHRESHOLD 大于或等于辅助池的 RUNTIMEPRIORITYTHRESHOLD，查询在达到主要池的 RUNTIMEPRIORITYTHRESHOLD 之后会采用辅助池的 RUNTIMEPRIORITY。
  
  例如： RUNTIMECAP （主要池）为 5 秒
  RUNTIMEPRIORITYTHRESHOLD （主要池）为 8 秒
  RUNTIMTPRIORITYTHRESHOLD （辅助池）为 7 秒
  
  在这种情况下，查询会在主要池上运行 5 秒，然后级联到次要池。再过去 3 秒（总共 8 秒）后，查询会采用次要池的 RUNTIMEPRIORITY。
- 如果主要池的 RUNTIMEPRIORITYTHRESHOLD 小于辅助池的 RUNTIMEPRIORITYTHRESHOLD，查询在达到辅助池的 RUNTIMEPRIORITYTHRESHOLD 之后将采用辅助池的 RUNTIMEPRIORITY。
  
  例如，主要池的
  RUNTIMECAP = 5 秒
  RUNTIMEPRIORITYTHRESHOLD （主要池）为 8 秒
  RUNTIMTPRIORITYTHRESHOLD （辅助池）为 12 秒
  
  在这种情况下，查询会在主要池上运行 5 秒，然后级联到次要池。再过去 7 秒（总共 12 秒）后，查询会采用次要池的 RUNTIMEPRIORITY。

6.2.2 - 查询资源池设置

您可以使用以下内容来获取有关资源池的信息：

RESOURCE_POOLS 从 Vertica 数据库编录中返回由 CREATE RESOURCE POOL 和 ALTER RESOURCE POOL 设置的资源池设置。
SUBCLUSTER_RESOURCE_POOL_OVERRIDES 显示全局资源池设置的所有子群集级别覆盖。

有关资源池的运行时信息，请参阅监控资源池。

查询资源池设置

以下示例查询两个内部资源池 GENERAL 和 TM 的各种设置：

=> SELECT name, subcluster_oid, subcluster_name, maxmemorysize, memorysize, runtimepriority, runtimeprioritythreshold, queuetimeout
   FROM RESOURCE_POOLS WHERE name IN('general', 'tm');
  name   | subcluster_oid | subcluster_name | maxmemorysize | memorysize | runtimepriority | runtimeprioritythreshold | queuetimeout
---------+----------------+-----------------+---------------+------------+-----------------+--------------------------+--------------
 general |              0 |                 | Special: 95%  |            | MEDIUM          |                        2 | 00:05
 tm      |              0 |                 |               | 3G         | MEDIUM          |                       60 | 00:05
(2 rows)

查看对全局资源池的覆盖

在 Eon 模式下，您可以在系统表中查询 SUBCLUSTER_RESOURCE_POOL_OVERRIDES 以查看对各个子群集的全局资源池的任何覆盖。以下查询显示了一个覆盖在 analytics_1 子群集中将内置资源池 TM 的 MEMORYSIZE 和 MAXMEMORYSIZE 设置为 0% 的覆盖。这些设置阻止子群集执行 Tuple Mover 合并任务。

=> SELECT * FROM SUBCLUSTER_RESOURCE_POOL_OVERRIDES;
     pool_oid      | name |  subcluster_oid   | subcluster_name | memorysize | maxmemorysize | maxquerymemorysize
-------------------+------+-------------------+-----------------+------------+---------------+--------------------
 45035996273705058 | tm   | 45035996273843504 | analytics_1     | 0%         | 0%            |
(1 row)

6.2.3 - 用户配置文件

用户配置文件是与某个用户相关联的属性，用于控制该用户对多个系统资源的访问权限。这些资源包括：

分配给用户的资源池 (RESOURCE POOL)
用户会话可以使用的最大内存量 (MEMORYCAP)
用户会话可以使用的最大临时文件存储量 (TEMPSPACECAP)
用户查询可以运行的最长时间 (RUNTIMECAP)

可使用 CREATE USER 语句设置这些属性，之后可以使用 ALTER USER 修改这些属性。

可使用两种策略来限制用户对资源的访问权限：直接为用户设置属性来控制资源使用，或将用户分配到一个资源池。第一种方法允许您对单个用户进行微调，而第二种方法可以轻松将许多用户分到一组，然后设置他们的共同资源使用量。

如果要通过资源池分配来统一限制用户资源，请考虑以下事项：

除非用户拥有 GENERAL 池的权限或者已分配给默认资源池，否则他们无法登录 Vertica。
如果删除了用户的默认资源池，则用户的查询将使用 GENERAL 池。
如果用户没有 GENERAL 池的权限，则在您尝试删除为他们分配的资源池时，DROP 操作将失败。

在 Eon 模式数据库中，您可以将用户的默认资源池设置为特定于子群集的资源池。如果是这种情况，Vertica 将使用以下方法之一来确定在用户连接到子群集时使用哪个资源池进行查询：

如果子群集使用为用户分配的默认资源池，那么用户的查询将使用为用户分配的资源池。
如果子群集不使用用户分配的默认资源池，但用户有权访问 GENERAL 池，则用户的查询使用 GENERAL 池。
如果子群集不使用为用户分配的资源池，并且用户对于 GENERAL 池没有权限，则用户无法从该子群集的任何节点进行查询。

以下示例说明了何设置用户的资源池属性。有关其他示例，请参阅将用户定义的池和用户配置文件用于工作负载管理中描述的场景。

示例

设置用户的 RESOURCE POOL 属性以将该用户分配到一个资源池。若要创建一个名为 user1 的用户，并且该用户具有对资源池 my_pool 的访问权限，请使用以下命令：

=> CREATE USER user1 RESOURCE POOL my_pool;

若要不通过指定池的方式来限制用户的内存量，可将该用户的 MEMORYCAP 设置为一个特定单位或占总可用内存的百分比。例如，若要创建一个名为 user2 的用户，并且将其会话限制为每个会话使用 200 MB 内存，请使用以下命令：

=> CREATE USER user2 MEMORYCAP '200M';

若要限制允许用户查询运行的时间，可设置 RUNTIMECAP 属性。若要阻止 user2 的查询运行超过五分钟，可使用以下命令：

=> ALTER USER user2 RUNTIMECAP '5 minutes';

若要限制用户会话可以使用的临时磁盘空间量，可将 TEMPSPACECAP 设置为一个特定大小或占可用临时磁盘空间的百分比。例如，下一个语句将创建 user3，并将其限制为使用 1 GB 的临时空间：

=> CREATE USER user3 TEMPSPACECAP '1G';

可以将不同属性组合到一个命令中：例如，若要为 user3 限制 MEMORYCAP 和 RUNTIMECAP，可将这两个属性包含在一个 ALTER USER 语句中：

=> ALTER USER user3 MEMORYCAP '750M' RUNTIMECAP '10 minutes';
ALTER USER
=> \x
Expanded display is on.
=> SELECT * FROM USERS;
-[ RECORD 1 ]-----+------------------
user_id           | 45035996273704962
user_name         | release
is_super_user     | t
resource_pool     | general
memory_cap_kb     | unlimited
temp_space_cap_kb | unlimited
run_time_cap      | unlimited
-[ RECORD 2 ]-----+------------------
user_id           | 45035996273964824
user_name         | user1
is_super_user     | f
resource_pool     | my_pool
memory_cap_kb     | unlimited
temp_space_cap_kb | unlimited
run_time_cap      | unlimited
-[ RECORD 3 ]-----+------------------
user_id           | 45035996273964832
user_name         | user2
is_super_user     | f
resource_pool     | general
memory_cap_kb     | 204800
temp_space_cap_kb | unlimited
run_time_cap      | 00:05
-[ RECORD 4 ]-----+------------------
user_id           | 45035996273970230
user_name         | user3
is_super_user     | f
resource_pool     | general
memory_cap_kb     | 768000
temp_space_cap_kb | 1048576
run_time_cap      | 00:10

另请参阅

6.2.4 - 查询预算

在执行查询之前，Vertica 会设计一个查询计划，并将其发送到将参与执行查询的每个节点。资源管理器评估每个节点上的计划，并估算节点执行其查询部分需要的内存量和并发程度。这是查询预算，Vertica 将其存储在系统表 V_MONITOR.RESOURCE_POOL_STATUS 的 query_budget_kb 列中。

查询预算基于查询将执行的资源池的几个参数设置：

MEMORYSIZE
MAXMEMORYSIZE
PLANNEDCONCURRENCY

您可以使用 ALTER RESOURCE POOL 修改 GENERAL 资源池的 MAXMEMORYSIZE 和 PLANNEDCONCURRENCY。此资源池通常执行未分配给用户定义资源池的查询。您可以在使用 CREATE RESOURCE POOL 或者稍后使用 ALTER RESOURCE POOL 创建任何由用户定义的资源池时设置所有三个参数。

重要

您还可以通过在该池上设置 MAXQUERYMEMORYSIZE 参数来限制池在运行时可以为其查询分配的内存量。有关详细信息，请参阅 CREATE RESOURCE POOL。

计算 GENERAL 池查询预算

Vertica 使用以下公式计算 GENERAL 池中的查询预算：

queryBudget = queuingThresholdPool / PLANNEDCONCURRENCY

注意

Vertica 将 GENERAL 池的排队阈值计算为其 MAXMEMORYSIZE 设置的 95%。

计算用户定义的资源池的查询预算

对于用户定义的资源池，Vertica 使用以下算法：

如果 MEMORYSIZE 设置为 0 并且 MAXMEMORYSIZE 未设置：

queryBudget = queuingThresholdGeneralPool / PLANNEDCONCURRENCY

如果 MEMORYSIZE 设置为 0 并且 MAXMEMORYSIZE 设置为非默认值：
```
query-budget = queuingThreshold / PLANNEDCONCURRENCY
```
注意
Vertica 将用户定义的池的排队阈值计算为其 MAXMEMORYSIZE 设置的 95%。

如果 MEMORYSIZE 设置为非默认值：

queryBudget = MEMORYSIZE / PLANNEDCONCURRENCY

通过仔细调整资源池的 MEMORYSIZE 和 PLANNEDCONCURRENCY 参数，可以控制能够为查询预算多少内存。

当心

查询预算通常不需要调整，但是，如果由于其他目的需要内存而减少 MAXMEMORYSIZE，请注意这样做也会减少查询预算。减少查询预算会对查询性能产生负面影响，尤其是在查询很复杂的情况下。

为了保持资源池的原始查询预算，一定要一起减小参数 MAXMEMORYSIZE 和 PLANNEDCONCURRENCY。

另请参阅

您是否需要在预算范围内查询？在 Vertica 用户社区中。

6.3 - 在查询运行时管理资源

资源管理器估算运行查询所需的资源，然后确定查询的优先级。您可以通过多种方式控制资源管理器如何确定查询执行的优先级：

6.3.1 - 为资源池设置运行时优先级

对于每个资源池，可以管理分配给正在运行的查询的资源。您可以为每个资源池分配 HIGH、MEDIUM 或 LOW 运行时优先级。这些设置确定了运行查询时资源池中为其分配的运行时资源量（如 CPU 数量和 I/O 带宽）。优先级为 HIGH 的资源池中的查询获得的运行时资源比运行时优先级为 MEDIUM 或 LOW 的资源池中的查询要多。

确定资源池中查询的优先级

虽然运行时优先级有助于管理资源池的资源，但有些情况下，您可能希望资源池内具有一定灵活性。例如，您可能希望确保每个短小查询都以高优先级运行，同时确保所有其他查询以中等或低优先级运行。

资源管理器可以为资源池设置运行时优先级阈值，从而提供这种灵活性。使用此阈值，您可以指定一个时间限制（以秒为单位），查询必须在该时间限制内完成，否则会被分配资源池的运行时优先级。所有查询在开始运行时优先级均为 HIGH；当查询的持续时间超过运行时优先级阈值中指定的时间限制后，将为其分配资源池的运行时优先级。

设置运行时优先级和运行时优先级阈值

通过使用 CREATE RESOURCE POOL 或 ALTER RESOURCE POOL 设置两个资源池参数，指定运行时优先级和运行时优先级阈值：

RUNTIMEPRIORITY
RUNTIMEPRIORITYTHRESHOLD

6.3.2 - 更改正在运行的查询的运行时优先级

CHANGE_CURRENT_STATEMENT_RUNTIME_PRIORITY 允许您更改查询的运行时优先级。您可以更改已在执行的查询的运行时优先级。

此函数具有两个实参：

查询的事务 ID（从系统表中获取） SESSIONS
所需的优先级，以下字符串值之一：HIGH、MEDIUM 或 LOW

限制

超级用户可以将任何查询的运行时优先级更改为任何优先级。对于其他用户，以下限制适用：

他们只能更改其各自查询的运行时优先级。
他们不能将查询的运行时优先级提高至高于资源池的优先级。

过程

更改查询的运行时优先级涉及到一个两步过程：

通过查询系统表 SESSIONS 来获取查询的事务 ID。例如，以下语句返回有关所有正在运行的查询的信息：
```
=> SELECT transaction_id, runtime_priority, transaction_description from SESSIONS;
```
运行 `CHANGE_CURRENT_STATEMENT_RUNTIME_PRIORITY```，指定查询的事务 ID 和所需的运行时优先级：
```
=> SELECT CHANGE_CURRENT_STATEMENT_RUNTIME_PRIORITY(45035996273705748, 'low')
```

6.3.3 - 手动将查询移至不同的资源池

数据库管理员可以使用 MOVE_STATEMENT_TO_RESOURCE_POOL 元函数将查询移至另一个执行当中的资源池。

如果某一个查询正在使用大量资源，您可能希望利用这一功能，以防止执行较小的查询。

当查询移至另一个资源池时会发生什么情况

将查询从一个资源池移至另一个资源池时，如果目标池具有足以容纳传入查询的资源，该查询便会继续执行。如果在目标池中无法至少在一个节点上分配足够的资源，则 Vertica 会取消该查询并尝试重新计划查询。如果 Vertica 无法重新计划查询，则该查询将被无限期地取消。

当您成功将查询移至目标资源池后，该查询的资源将由目标池提供，而在第一个池中占用的资源将被释放。

如果将查询移至具有 PRIORITY HOLD 的资源池，Vertica 会取消该查询并将其排入目标池的队列中。在您更改 PRIORITY 或将查询移至另一个没有 PRIORITY HOLD 的资源池之前，该取消状态将一直有效。如果要存储长时间运行的查询以便日后使用，可使用此选项。

若要确定目标池能否容纳要移动的查询，可查看 RESOURCE_ACQUISITIONS 或 RESOURCE_POOL_STATUS 系统表。请注意，当您查询系统表时以及调用 MOVE_STATEMENT_TO_RESOURCE_POOL 元函数时，这些表可能发生变化。

当查询从一个资源池成功移至另一个执行当中的资源池时，该查询会一直执行，直至达到现有 RUNTIMECAP 和新 RUNTIMECAP 之间的较大者为止。例如，如果初始池的 RUNTIMECAP 大于目标池，则查询可在达到初始 RUNTIMECAP 之前一直执行。当查询从一个资源池成功移至另一个执行当中的资源池时，CPU 关联性将改变。

使用 MOVE_STATEMENT_TO_RESOURCE_POOL 函数

若要手动将查询从其当前资源池移至另一资源池，请使用 MOVE_STATEMENT_TO_RESOURCE_POOL 元函数。如下所示提供会话 ID、事务 ID、语句 ID 和目标资源池名称：

=> SELECT MOVE_STATEMENT_TO_RESOURCE_POOL ('v_vmart_node0001.example.-31427:0x82fbm', 45035996273711993, 1, 'my_target_pool');

另请参阅：

6.4 - 还原资源管理器默认设置

系统表 RESOURCE_POOL_DEFAULTS 存储所有内置和用户定义的资源池的所有参数的默认值。

如果更改了任何资源池中任何参数的值并想要将其还原为默认值，只需更改表并将参数设置为 DEFAULT 即可。例如，以下语句可将资源池 sysquery 的 RUNTIMEPRIORITY 重新设置为默认值：

=> ALTER RESOURCE POOL sysquery RUNTIMEPRIORITY DEFAULT;

6.5 - 工作负载资源管理最佳实践

本部分提供如何针对各种常见情景设置和优化资源池的一般指导原则和最佳实践。

注意

资源池参数的具体设置主要取决于查询组合、数据大小、硬件配置和并发要求。Vertica 建议您亲自实验确定系统的最佳配置。

6.5.1 - 可扩展性和并发优化的基本原则

Vertica 数据库在一组商用硬件上运行。对数据库运行的所有加载和查询均需占用 CPU、内存、磁盘 I/O 带宽、文件句柄等系统资源。给定查询的性能（运行时间）取决于为其分配的资源量。

在系统中同时运行多个查询时，这些查询会共享资源；因此，每个查询的运行时间可能比其单独运行时要长。在可扩展的高效系统中，如果某个查询占用计算机的所有资源且运行时间为 X，则运行两个此类查询可能会使每个查询的运行时间增加一倍。如果查询的运行时间超过 2X，则说明系统并非可线性扩展；如果查询的运行时间小于 2X，则说明单个查询在资源使用方面存在浪费情况。请注意，只要查询获得其运行所需的最少资源且受 CPU 周期限制，就会发生上述情况。相反，如果因系统瓶颈导致查询无法获得运行所需的足够特定资源，则说明系统已达到极限。在这种情况下，为了提高并发性，必须通过另外添加此资源来扩展系统。

实际上，Vertica 应在达到系统资源限制之前，通过提高并发性而在运行时间方面实现近乎线性的可扩展性。如果达到足够的并发性且未引发任何瓶颈，便可认为系统大小非常适合工作负载。

注意

通常，分段表的 Vertica 查询将在群集的多个（可能是全部）节点上运行。添加更多节点通常会近乎线性地改善查询的运行时间。

6.5.2 - 为查询设置运行时限制

可以为允许查询运行的时间长度设置限制。您可以将此限制设置为三个级别，按优先级降序排列：

要将用户分配到的资源池。
具有 RUNTIMECAP（由 CREATE USER/ALTER USER 配置）的用户配置文件 ALTER USER
会话查询（由 SET SESSION RUNTIMECAP 设置） SET SESSION RUNTIMECAP

在所有情况下，您都可以使用不超过一年的 interval 值设置运行时限制。在多个级别设置运行时限制时，Vertica 始终使用最短的值。如果为非超级用户设置了运行时限制，则该用户无法将任何会话设置为更长的运行时限制。超级用户可以将其他用户和他们自己的会话的运行时限制设置为不超过一年（包含）的任意值。

示例

user1 被分配至 ad_hoc_queries 资源库：

=> CREATE USER user1 RESOURCE POOL ad_hoc_queries;

user1 的 RUNTIMECAP 设置为 1 小时。

=> ALTER USER user1 RUNTIMECAP '60 minutes';

ad_hoc_queries 资源池的 RUNTIMECAP 设置为 30 分钟。

=> ALTER RESOURCE POOL ad_hoc_queries RUNTIMECAP '30 minutes';

在本例中，如果 user1 的查询超过 30 分钟，Vertica 会终止这些查询。尽管 user1 的运行时间限制设置为一小时，但运行查询的池（具有 30 分钟的运行时间限制）具有优先权。

注意

如果使用 CASCADE TO 函数为 ad_hoc_queries 池指定了一个辅助池，则当查询超过 ad_hoc_queries 池上的 RUNTIMECAP 时，就会在该辅助池上执行查询。

另请参阅

6.5.3 - 处理会话套接字阻止

针对给定查询等待客户端输入或输出时，会话套接字可能会被阻止。会话套接字通常因多种原因而被阻止 — 例如，当 Vertica 执行引擎将数据传输到客户端时，或 COPY LOCAL 操作等待从客户端加载数据时。

在极少数情况下，会话套接字可能会无限期地保持被阻止状态。例如，客户端上的查询超时，这会尝试强制取消查询或者依赖会话 RUNTIMECAP 设置来终止查询。在任何一种情况下，如果查询在等待消息或数据时结束，则套接字可能会保持阻止状态，会话将挂起，直到它被强制关闭。

配置宽限期

您可以为系统配置一个宽限期，在此期间滞后的客户端或服务器可以跟上并传递待定的响应。如果套接字保持被阻止状态的连续期间超过宽限期设置，服务器将关闭套接字并引发致命错误。随后，会话终止。如果没有设置宽限期，查询会使套接字无限期地保持被阻止状态。

您应该将会话宽限期设置为高到足以覆盖可接受的延迟范围并避免会话过早关闭 — 例如，为了对服务器进行响应而设置正常的客户端延迟。超大负载操作可能会要求您根据需要调整会话宽限期。

您可以将宽限期设置为四个级别，按优先级降序排列：

会话（最高）
用户
节点
数据库

为数据库和节点设置宽限期

在数据库和节点级别，可以通过 BlockedSocketGracePeriod 配置参数将宽限期设置为不超过 20 天的任意间隔：

ALTER DATABASE db-name SET BlockedSocketGracePeriod = 'interval';
ALTER NODE node-name SET BlockedSocketGracePeriod = 'interval';

默认情况下，这两个级别的宽限期都设置为空字符串，允许无限期阻止。

为用户和会话设置宽限期

您可以为单个用户和给定会话设置宽限期，如下所示：

{ CREATE | ALTER USER } user-name GRACEPERIOD {'interval' | NONE };
SET SESSION GRACEPERIOD { 'interval' | = DEFAULT | NONE };

用户可以将会话设置为等于或小于为该用户设置的宽限期的任意间隔。超级用户可以将其他用户和他们自己的会话的宽限期设置为不超过 20 天（包含）的任意值。

示例

超级用户 dbadmin 将数据库宽限期设置为 6 小时。此限制仅适用于非超级用户。 dbadmin 可以将自己的会话宽限期设置为不超过 20 天的任意值 — 在本例中为 10 小时：

=> ALTER DATABASE VMart SET BlockedSocketGracePeriod = '6 hours';
ALTER DATABASE
=> SHOW CURRENT BlockedSocketGracePeriod;
  level   |           name           | setting
----------+--------------------------+---------
 DATABASE | BlockedSocketGracePeriod | 6 hours
(1 row)

=> SET SESSION GRACEPERIOD '10 hours';
SET
=> SHOW GRACEPERIOD;
    name     | setting
-------------+---------
 graceperiod | 10:00
(1 row)

dbadmin 创建未设置宽限期的用户 user777。因此，user777 的有效宽限期派生自数据库的 BlockedSocketGracePeriod 设置，即 6 小时。user777 将会话宽限期设置为大于 6 小时的任何尝试都会返回错误：


=> CREATE USER user777;
=> \c - user777
You are now connected as user "user777".
=> SHOW GRACEPERIOD;
    name     | setting
-------------+---------
 graceperiod | 06:00
(1 row)

=> SET SESSION GRACEPERIOD '7 hours';
ERROR 8175:  The new period 07:00 would exceed the database limit of 06:00

dbadmin 为 user777 设置 5 分钟的宽限期。现在，user777 可以将会话宽限期设置为等于或小于用户级别设置的任何值：


=> \c
You are now connected as user "dbadmin".
=> ALTER USER user777 GRACEPERIOD '5 minutes';
ALTER USER
=> \c - user777
You are now connected as user "user777".
=> SET SESSION GRACEPERIOD '6 minutes';
ERROR 8175:  The new period 00:06 would exceed the user limit of 00:05
=> SET SESSION GRACEPERIOD '4 minutes';
SET

6.5.4 - 将用户定义的池和用户配置文件用于工作负载管理

本部分中的场景介绍常见的工作负载管理问题，并提供带示例的解决方案。

6.5.4.1 - 周期性批量加载

场景

您每天晚上都执行批量加载，偶尔（很少）在白天执行批量加载。当加载正在运行时，减少查询的资源使用量是可接受的，但在其他所有时间，您希望所有资源都可用于查询。

解决方案

为加载创建一个单独的资源池，使其优先级高于内置 GENERAL 池上的预配置设置。

在此场景中，在从 GENERAL 池中借用内存时，每天晚上的加载具有优先权。在没有运行加载时，所有内存将可自动用于查询。

示例

创建一个优先级高于 GENERAL 池的资源池：

创建 PRIORITY 设置为 10 的资源池 load_pool：
```
=> CREATE RESOURCE POOL load_pool PRIORITY 10;
```

修改用户 load_user 以使用新的资源池：

=> ALTER USER load_user RESOURCE POOL load_pool;

6.5.4.2 - CEO 查询

场景

CEO 在每周一的上午 9 点运行报告，您想要确保该报告始终运行。

解决方案

若要确保某个查询或某类查询始终获得资源，可以为其创建专用池，如下所示：

使用 PROFILE 命令，运行 CEO 每周运行的查询，确定应当分配的内存量：

=> PROFILE SELECT DISTINCT s.product_key, p.product_description
-> FROM store.store_sales_fact s, public.product_dimension p
-> WHERE s.product_key = p.product_key AND s.product_version = p.product_version
-> AND s.store_key IN (
->  SELECT store_key FROM store.store_dimension
->  WHERE store_state = 'MA')
-> ORDER BY s.product_key;

在查询结束时，系统返回一条含有资源使用量的通知：

NOTICE:  Statement is being profiled.HINT:  select * from v_monitor.execution_engine_profiles where
transaction_id=45035996273751349 and statement_id=6;
NOTICE:  Initiator memory estimate for query: [on pool general: 1723648 KB,
minimum: 355920 KB]

创建具有上述提示所报告的 MEMORYSIZE 的资源池，确保至少为 CEO 查询保留此内存大小：

=> CREATE RESOURCE POOL ceo_pool MEMORYSIZE '1800M' PRIORITY 10;
CREATE RESOURCE POOL
=> \x
Expanded display is on.
=> SELECT * FROM resource_pools WHERE name = 'ceo_pool';
-[ RECORD 1 ]-------+-------------
name                | ceo_pool
is_internal         | f
memorysize          | 1800M
maxmemorysize       |
priority            | 10
queuetimeout        | 300
plannedconcurrency  | 4
maxconcurrency      |
singleinitiator     | f

假设 CEO 报告用户已存在，使用 ALTER USER 语句将此用户与上述资源池相关联。
```
=> ALTER USER ceo_user RESOURCE POOL ceo_pool;
```

发出以下命令确认 ceo_user 与 ceo_pool 相关联：

=> SELECT * FROM users WHERE user_name ='ceo_user';
-[ RECORD 1 ]-+------------------
user_id       | 45035996273713548
user_name     | ceo_user
is_super_user | f
resource_pool | ceo_pool
memory_cap_kb | unlimited

如果 CEO 查询内存使用量过大，可以让资源管理器将其降至符合特定预算的水平。请参阅查询预算。

6.5.4.3 - 防止失控查询

场景

Joe 是一位经常在中午运行大型报告的业务分析员，这些报告占用了整个机器的资源。您想要防止 Joe 使用超过 100MB 的内存，并且想要将 Joe 的查询运行时间限制在 2 小时以内。

解决方案

用户配置文件为此场景提供了一个解决方案。若要限制 Joe 一次可以使用的内存量，使用 ALTER USER 命令将 Joe 的 MEMORYCAP 设置为 100MB。若要限制 Joe 的查询可以运行的时间长度，使用相同的命令将 RUNTIMECAP 设置为 2 小时。如果 Joe 运行的查询超过其最高限值，Vertica 会拒绝该查询。

如果您有一批需要限制查询的用户，也可以为他们创建一个资源池并为该资源池设置 RUNTIMECAP。将这些用户移至此资源池后，Vertica 会将这些用户的所有查询限制为您为该资源池指定的 RUNTIMECAP。

示例

=> ALTER USER analyst_user MEMORYCAP '100M' RUNTIMECAP '2 hours';

如果 Joe 尝试运行超过 100MB 的查询，系统会返回一个错误，说明请求超出内存会话限制，如以下示例所示：

\i vmart_query_04.sqlvsql:vmart_query_04.sql:12: ERROR:  Insufficient resources to initiate plan
on pool general [Request exceeds memory session limit: 137669KB > 102400KB]

只有系统数据库管理员 (dbadmin) 可以提高 MEMORYCAP 设置。用户不能提高自己的 MEMORYCAP 设置，如果他们尝试编辑其 MEMORYCAP 或 RUNTIMECAP 设置，则将看到类似于以下内容的错误：

ALTER USER analyst_user MEMORYCAP '135M';
ROLLBACK:  permission denied

6.5.4.4 - 限制临时查询应用程序的资源使用率

场景

您最近将数据仓库提供给一大群用户，而他们并不熟悉 SQL。一些用户对大量的行运行报告，耗尽了系统资源。您想要制约这些用户的系统使用量。

解决方案

为 MAXMEMORYSIZE 等于 MEMORYSIZE 的临时应用程序创建资源池。这可以防止该资源池中的查询从 GENERAL 池中借用资源。另外，设置 RUNTIMECAP 以限制临时查询的最大持续时间。

=> CREATE RESOURCE POOL adhoc_pool
    MEMORYSIZE '200M'
       MAXMEMORYSIZE '200M'
    RUNTIMECAP '20 seconds'
    PRIORITY 0
    QUEUETIMEOUT 300
    PLANNEDCONCURRENCY 4;
=> SELECT pool_name, memory_size_kb, queueing_threshold_kb
    FROM V_MONITOR.RESOURCE_POOL_STATUS WHERE pool_name='adhoc_pool';
 pool_name  | memory_size_kb | queueing_threshold_kb
------------+----------------+-----------------------
 adhoc_pool |         204800 |                153600
(1 row)

将此资源池与应用程序用于连接到数据库的数据库用户相关联。
```
=> ALTER USER app1_user RESOURCE POOL adhoc_pool;
```

提示

其他解决方案包括像在防止失控查询中一样限制单个用户的内存使用量。

6.5.4.5 - 为应用程序设置硬性并发限制

场景

为了便于开票，分析员 Jane 希望对此应用程序的并发性实施硬性限制。如何做到这一点？

解决方案

最简单的解决方案是为该应用程序的用户创建一个单独的资源池，并将其 MAXCONCURRENCY 设置为所需的并发级别。任何超过 MAXCONCURRENCY 的查询都会进入队列。

提示

Vertica 建议将 PLANNEDCONCURRENCY 保留为默认级别，以便查询获得最大的资源量。从而使整个系统以最高效率运行。

示例

在本示例中，存在四位与开票池相关联的开票用户。目的是对资源池设置硬性限制，使一次最多可以执行三个并发查询。所有其他查询将排队并在资源释放后完成。

=> CREATE RESOURCE POOL billing_pool MAXCONCURRENCY 3 QUEUETIMEOUT 2;
=> CREATE USER bill1_user RESOURCE POOL billing_pool;
=> CREATE USER bill2_user RESOURCE POOL billing_pool;
=> CREATE USER bill3_user RESOURCE POOL billing_pool;
=> CREATE USER bill4_user RESOURCE POOL billing_pool;
=> \x
Expanded display is on.

=> select maxconcurrency,queuetimeout from resource_pools where name = 'billing_pool';
maxconcurrency | queuetimeout
----------------+--------------
             3 |            2
(1 row)
> SELECT reason, resource_type, rejection_count  FROM RESOURCE_REJECTIONS
WHERE pool_name = 'billing_pool' AND node_name ilike '%node0001';
reason                                | resource_type | rejection_count
---------------------------------------+---------------+-----------------
Timedout waiting for resource request | Queries       |              16
(1 row)

如果查询正在运行并且没有在规定时间内完成（默认超时设置为 5 分钟），请求的下一查询将收到一条类似于以下内容的错误：

ERROR:  Insufficient resources to initiate plan on pool billing_pool [Timedout waiting for resource request: Request exceeds limits:
Queries Exceeded: Requested = 1, Free = 0 (Limit = 3, Used = 3)]

下表显示在开票池中存在三个活动查询。

=> SELECT pool_name, thread_count, open_file_handle_count, memory_inuse_kb FROM RESOURCE_ACQUISITIONS

WHERE pool_name = 'billing_pool';

pool_name    | thread_count | open_file_handle_count | memory_inuse_kb

--------------+--------------+------------------------+-----------------

billing_pool |            4 |                      5 |          132870

billing_pool |            4 |                      5 |          132870

billing_pool |            4 |                      5 |          132870

(3 rows)

6.5.4.6 - 处理混合工作负载：批处理与交互式处理

场景

您具有一个带交互门户的 Web 应用程序。有时，当 IT 人员运行批处理报告时，Web 页面需要很长时间才能刷新，引起用户抱怨，因此您想要为网站用户提供更好的体验。

解决方案

可以应用先前场景中学习到的原则解决此问题。基本思想是将查询分离成与不同资源池相关联的两组。先决条件是存在两个不同的数据库用户，他们发出不同类型的查询。如果情况与此不同，请将此视为应用程序设计的最佳方法。

方法 1
：创建专门用于 Web 页面刷新查询的资源池，同时：

根据查询的平均资源需求以及门户中发出的并发查询的预期数量来设定资源池大小。
将此资源池与运行网站查询的数据库用户相关联。有关创建专用池的信息，请参阅CEO 查询。

这可确保网站查询始终运行并且从不排列在大型批处理作业之后。让处理作业不在 GENERAL 池上运行。

例如，以下池是根据从 Web 运行的查询所需的平均资源量以及并发查询的预期数量来确定的。另外，它给予 Web 查询的优先级要高于任何正在运行的批处理作业，并假定将查询调整为每个查询占用 250M：

=> CREATE RESOURCE POOL web_pool
     MEMORYSIZE '250M'
     MAXMEMORYSIZE NONE
     PRIORITY 10
     MAXCONCURRENCY 5
     PLANNEDCONCURRENCY 1;

方法 2
创建具有固定内存大小的资源池。这将限制批处理报告可用的内存量，使内存始终留作其他用途。有关详细信息，请参阅限制临时查询应用程序的资源使用率。

例如：

=> CREATE RESOURCE POOL batch_pool
     MEMORYSIZE '4G'
     MAXMEMORYSIZE '4G'
     MAXCONCURRENCY 10;

如果您有三个或更多不同类别的工作负载，此原则同样适用。

6.5.4.7 - 对不同用户发出的查询设置优先级

场景

您希望一个部门的用户查询比另一个部门的查询具有更高的优先级。

解决方案

解决方案类似于混合工作负载场景。在此场景中，您没有限制资源使用量；您设置了不同的优先级。若要这样做，可创建两个不同的池，每个池都具有 MEMORYSIZE=0% 以及一个不同的 PRIORITY 参数。这两个池都从 GENERAL 池中借用资源，但在争夺资源时，优先级决定了每个池的请求获得批准的顺序。例如：

=> CREATE RESOURCE POOL dept1_pool PRIORITY 5;
=> CREATE RESOURCE POOL dept2_pool PRIORITY 8;

如果您发现此解决方案不足以满足需要，或者一个部门的查询一直使另一个部门的用户难以执行查询，则可以通过设置 MEMORYSIZE 为每个池添加预留，这样会保证每个部门都可以使用一些内存。

例如，两个资源都使用 GENERAL 池获取内存，所以您可以通过使用 ALTER RESOURCE POOL 更改每个池的 MEMORYSIZE，为每个资源池分配一些内存。

=> ALTER RESOURCE POOL dept1_pool MEMORYSIZE '100M';
=> ALTER RESOURCE POOL dept2_pool MEMORYSIZE '150M';

6.5.4.8 - 持续加载和查询

场景

您希望应用程序运行连续加载流，但许多应用程序运行的是并行查询流。您希望确保性能是可预计的。

解决方案

此场景的解决方案取决于您的查询组合。在所有情况下，以下方法均适用：

确定所需的连续加载流数量。如果单个流没有提供足够的吐吞量，则这可能与所需加载速率有关，或者与要加载的数据源数量有更直接的关系。为加载创建一个专用资源池，并将其与要执行加载的数据库用户相关联。有关详细信息，请参阅CREATE RESOURCE POOL。

通常，加载池的并行设置应少于每个节点的内核数。除非源进程较慢，否则会更高效地为每个加载贡献更多内存，并且具有更多的加载队列。如果预计有队列，请调整加载池的 QUEUETIMEOUT 设置。
运行加载工作负载一会儿，观察加载性能是否符合预期。如果 Tuple Mover 没有经过充分优化以涵盖加载行为，请参阅管理 Tuple Mover。
如果系统中有多种类型的查询（例如，对于某些查询，必须为交互用户快速提供答复，而其他查询属于批量报告处理的一部分），请遵循处理混合工作负载：批处理与交互式处理中的准则。
运行查询并观察性能。如果某些类别的查询没有按预期执行，那么您可能需要按照限制临时查询应用程序的资源使用率中所述调整 GENERAL 池，或者为这些查询创建更多专用资源池。有关详细信息，请参阅CEO 查询和处理混合工作负载：批处理与交互式处理。

有关在混合工作负载环境中获得可预测结果的信息，请参阅关于管理工作负载和CREATE RESOURCE POOL的部分。

6.5.4.9 - 确定运行时短查询的优先级

场景

您最近为没有 SQL 方面经验并且经常运行临时报表的用户创建了一个资源池。到目前为止，您通过创建 MEMORYSIZE 和 MAXMEMORYSIZE 相等的资源池来管理资源分配。这可以防止该资源池中的查询从 GENERAL 池中借用资源。现在，您希望在运行时管理资源并优先考虑短查询，使其不会因为运行时资源有限而排队。

解决方案

将资源池的 RUNTIMEPRIORITY设置为 MEDIUM 或 LOW。
将资源池的 RUNTIMEPRIORITYTHRESHOLD设置为您希望确保始终以较高优先级运行的查询的持续时间。

例如：

=> ALTER RESOURCE POOL ad_hoc_pool RUNTIMEPRIORITY medium RUNTIMEPRIORITYTHRESHOLD 5;

由于 RUNTIMEPRIORITYTHRESHOLD 设置为 5，因此资源池 ad_hoc_pool 中在 5 秒内完成的所有查询都以高优先级运行。超过 5 秒的查询将下降到分配给该资源池的 RUNTIMEPRIORITYMEDIUM。

6.5.4.10 - 删除运行时较长查询的优先级

场景

您希望资源池中的大部分查询以 HIGH 运行时优先级运行，但能够将长于 1 小时的作业调整为更低的优先级。

解决方案

将资源池的 RUNTIMEPRIORITY 设置为 LOW，将 RUNTIMEPRIORITYTHRESHOLD 设置为一个仅截断最长作业的数值。

示例

要确保向所有持续时间长于 3600 秒（1 小时）的查询分配低运行时优先级，请按如下所示修改资源池：

将 RUNTIMEPRIORITY 设置为 LOW。
将 RUNTIMETHRESHOLD 设置为 3600

=> ALTER RESOURCE POOL ad_hoc_pool RUNTIMEPRIORITY low RUNTIMEPRIORITYTHRESHOLD 3600;

6.5.5 - 调整内置池

本部分中的场景介绍如何优化内置池。

6.5.5.1 - 将 Vertica 限制为仅占用 60% 的内存

场景

您有一个嵌入 Vertica 的单节点应用程序，部分 RAM 需要专用于该应用程序进程。在此场景中，您想要将 Vertica 限制为仅使用可用 RAM 的 60%。

解决方案

将 GENERAL 池的 MAXMEMORYSIZE 参数设置为所需的内存大小。有关资源限制的讨论，请参阅资源池架构。

6.5.5.2 - 为恢复进行调整

场景

您有一个大型数据库，其中包含一个具有两个投影以及默认设置的大型表，恢复操作所需的时间过长。您想要为恢复操作提供更多内存以提高速度。

解决方案

将 RECOVERY 池的 PLANNEDCONCURRENCY 和 MAXCONCURRENCY 设为 1，使恢复操作可以从 GENERAL 池中获得尽可能多的内存并且每次仅运行一个线程。

当心

此设置会降低您系统中其他查询的速度。

6.5.5.3 - 调整刷新

场景

当刷新操作正在运行时，系统性能会受到影响，用户查询会被拒绝。您想要降低刷新作业的内存用量。

解决方案

将刷新池的 MEMORYSIZE 设置为固定值。然后，资源管理器调整刷新查询，使其仅使用此数量的内存。

重要

请记得在刷新操作完成后，将刷新池的 MEMORYSIZE 重置为 0%，以便可将内存用于其他操作。

6.5.5.4 - 调整 Tuple Mover 池设置

场景 1

在重负载操作期间，您偶尔会注意到 ROS 容器的数量激增。您希望 Tuple Mover 更主动地执行合并以合并 ROS 容器，并避免 ROS 推回。

解决方案

使用 ALTER RESOURCE POOL 增加 TM 资源池中 MAXCONCURRENCY 的设置。此设置确定有多少线程可用于合并。默认情况下，此参数设置为 7。Vertica 将一半线程分配给处于活动状态的分区，其余一半根据需要分配给处于活动状态和非活动状态的分区。如果 MAXCONCURRENCY 设置为奇整数，Vertica 会向上舍入以支持处于活动状态的分区。

例如，如果您将 MAXCONCURRENCY 增加到 9，则 Vertica 会将五个线程专门分配给处于活动状态的分区，并将剩余的四个线程分配给处于活动状态和非活动状态的分区。

场景 2

您有一个专用于时间敏感型分析查询的辅助子群集。您希望限制此子群集上可能干扰其处理查询的任何其他工作负载，并同时释放内存以执行查询。

默认情况下，每个子群集都有一个用于 Tuple Mover 操作的内置 TM 资源池，该资源池可用于执行 Tuple Mover 合并操作。TM 池消耗可用于查询的内存。此外，合并操作可能会给子群集的处理稍微增加一点开销。您希望重新分配由 TM 池消耗的内存，并阻止子群集运行合并操作。

解决方案

使用 ALTER RESOURCE POOL 覆盖辅助子群集的全局 TM 资源池，并将其 MAXMEMORYSIZE 和 MEMORYSIZE 都设置为 0。这允许您使用由全局 TM 池消耗的内存来运行分析查询，并防止为子群集分配要执行的 TM 合并操作。

6.5.5.5 - 为机器学习进行调整

场景

大量机器学习功能正在运行，您希望为它们提供更多内存以提高性能。

解决方案

Vertica 在 BLOBDATA 资源池中执行机器学习功能。为了提高机器学习功能的性能并避免将查询溢出到磁盘，请使用 ALTER RESOURCE POOL 增加池的 MAXMEMORYSIZE 设置。

有关调整查询预算的更多信息，请参阅查询预算。

另请参阅

6.5.6 - 缩短查询运行时间

查询的运行时间取决于查询的复杂性、计划中的运算符数、数据量和投影设计。I/O 或 CPU 瓶颈可能导致查询运行速度低于预期。您通常可以使用更好的投影设计来纠正 CPU 使用率过高的问题。高 I/O 通常可以追溯到由溢出到磁盘的联接和排序引起的争用。但是，没有单一的解决方案可以解决所有导致高 CPU 或 I/O 使用率的查询。您必须单独分析和优化每个查询。

可通过两种方式评估运行缓慢的查询：

使用 EXPLAIN 预先修复查询以查看优化器的查询计划。
通过查询系统表 QUERY_CONSUMPTION 或 执行_引擎_配置文件 检查执行配置文件。

检查查询计划会揭露以下一个或多个问题：

投影排序顺序不理想
对未排序或未编码的列进行谓词评估
使用 GROUPBY HASH 而非 GROUPBY PIPE

分析

Vertica 提供的分析机制可帮助您评估不同级别的数据库性能。例如，可为单个语句、单个会话或所有节点上的所有会话收集分析数据。有关详细信息，请参阅对数据库性能执行分析。

6.5.7 - 管理 Eon 模式数据库中的工作负载资源

您主要使用子群集来控制 Eon 模式数据库中的工作负载。例如，您可以为特定用例（如 ETL 或查询工作负载）创建子群集，也可以为不同的用户组创建子群集以隔离工作负载。在每个子群集中，您可以创建单独的资源池以根据工作负载优化资源分配。有关 Vertica 如何使用子群集的详细信息，请参阅管理子群集。

全局资源池和特定于子群集的资源池

您可以定义影响数据库中所有节点的全局资源池分配。您还可以在子群集级别创建资源池分配。如果您同时创建这两种分配，则子群集级别的设置会覆盖全局设置。

注意

GENERAL 池需要至少 25% 的可用内存才能正常运行。如果您尝试将用户定义的资源池的 MEMORYSIZE 设置为 75% 以上，Vertica 会返回错误。

您可以使用此功能移除子群集不需要的全局资源池。此外，您可以使用适合大多数子群集的设置创建资源池，然后根据需要为特定子群集定制设置。

优化 ETL 和查询子群集

覆盖子群集级别的资源池设置将允许您隔离内置和用户定义的资源池并按工作负载优化它们。您通常为不同的子群集分配特定的角色：

专用于 ETL 工作负载和 DDL 语句（这些语句用来更改数据库）的子群集。
专用于运行长时间运行的深入分析查询的子群集。为了获得最佳性能，需要为这些查询分配更多的资源。
用于运行许多短时间运行的“仪表板”查询（您希望快速完成且并行运行这些查询）的子群集。

定义由每个子群集执行的查询类型后，您可以创建一个特定于子群集的资源池，并对该资源池进行优化以提高此工作负载的效率。

以下方案按工作负载优化 3 个子群集：

ETL：用于执行 ETL 的子群集，您希望针对 Tuple Mover 操作优化该 ETL。
仪表板：您要为短时间运行的查询指定的子群集，这些查询由大量用户执行，可用于刷新网页。
分析：要为长时间运行的查询指定的子群集。

有关资源池调整的其他方案，请参阅工作负载资源管理最佳实践。

配置 ETL 子群集以提高 TM 性能

Vertica 选择在存储库中的合并操作中涉及 ROS 容器最多的子群集来执行合并（请参阅 Eon 模式数据库中的 Tuple Mover）。通常，执行 ETL 的子群集将是执行合并的最佳候选者，因为该子群集加载的数据参与合并。您可以选择通过更改 TM 池的 MAXCONCURRENCY 设置来提高子群集上合并操作的性能，以增加可用于合并操作的线程数。您无法在子群集级别更改此设置，因此您必须在全局设置它：

=> ALTER RESOURCE POOL TM MAXCONCURRENCY 10;

有关 Tuple Mover 资源的更多信息，请参阅调整 Tuple Mover 池设置。

配置仪表板查询子群集

默认情况下，辅助子群集将内存分配给 Tuple Mover 资源池。此池设置允许 Vertica 将合并操作分配给辅助子群集，这会增加少量开销。如果您将辅助子群集主要用于查询，则最佳做法是回收 TM 池使用的内存并防止将合并操作分配给辅助子群集。

要优化仪表板查询辅助子群集，请设置其 TM 池的 MEMORYSIZE 和 MAXMEMORYSIZE 设置为 0：

=> ALTER RESOURCE POOL TM FOR SUBCLUSTER dashboard MEMORYSIZE '0%'
   MAXMEMORYSIZE '0%';

重要

请勿在

主子群集上将 TM 池的 MEMORYSIZE 和 MAXMEMORYSIZE 设置为 0。它们必须始终能够运行 Tuple Mover。

若要确认覆盖，请查询 SUBCLUSTER_RESOURCE_POOL_OVERRIDES 表：

=> SELECT pool_oid, name, subcluster_name, memorysize, maxmemorysize
          FROM SUBCLUSTER_RESOURCE_POOL_OVERRIDES;

     pool_oid      | name | subcluster_name | memorysize | maxmemorysize
-------------------+------+-----------------+------------+---------------
 45035996273705046 | tm   | dashboard       | 0%         | 0%
(1 row)

若要针对网页上短时间运行的查询优化仪表板子群集，请创建一个名为 dash_pool 的子群集级资源池，该池使用子群集 70% 的内存。此外，增加 PLANNEDCONCURRENCY 以使用机器的所有逻辑核心，并将 EXECUTIONPARALLELISM 限制为不超过机器可用核心的一半：

=> CREATE RESOURCE POOL dash_pool FOR SUBCLUSTER dashboard
     MEMORYSIZE '70%'
     PLANNEDCONCURRENCY 16
     EXECUTIONPARALLELISM 8;

配置分析查询子群集

若要针对网页上长时间运行的查询优化分析子群集，请创建一个名为 analytics_pool 的子群集级资源池，该池使用子群集 60% 的内存。在这种情况下，您无法为该池分配更多内存，因为该子群集中的节点仍将内存分配给其 TM 池。此外，将 EXECUTIONPARALLELISM 设置为 AUTO 以使用节点上的所有可用核心来处理查询，并将 PLANNEDCONCURRENCY 限制为不超过 8 个并发查询：

=> CREATE RESOURCE POOL analytics_pool FOR SUBCLUSTER analytics
      MEMORYSIZE '60%'
      EXECUTIONPARALLELISM AUTO
      PLANNEDCONCURRENCY 8;

6.6 - 管理系统资源使用率

您可以使用使用系统表来跟踪群集上的总体资源使用情况。Vertica 系统表中介绍了这些系统表和其他系统表。

如果您的查询因资源不可用而遇到错误，则可使用以下系统表获取更多详细信息：

当某种类型的资源请求被拒绝时，请执行以下操作之一：

通过添加更多内存、更多磁盘空间等措施增加节点上的可用资源。请参阅管理磁盘空间。
通过减少系统上的用户数（请参阅管理会话）、重新安排操作等措施减少资源需求。

RESOURCE_REJECTIONS 中的 LAST_REJECTED_VALUE 字段指示问题原因。例如：

消息 Usage of a single requests exceeds high limit 表示系统没有可用于单个请求的足够资源。当文件处理限制设置得过低且您正在加载包含大量列的表时，通常会出现上述情况。
消息“等待资源预留超时或已取消等待资源预留 (Timed out or Canceled waiting for resource reservation)”通常表示资源争夺过于激烈，因为硬件平台无法支持使用它的并发用户数。

6.6.1 - 管理会话

Vertica 为数据库管理员提供了用于查看和控制会话的强大方法。具体方法因会话类型而异：

外部（用户）会话通过 vsql 或编程式（ODBC 或 JDBC）连接启动，并且具有关联的客户端状态。
内部（系统）会话由 Vertica 启动，但没有客户端状态。

配置最大会话数

每个节点的最大用户会话数由配置参数 MaxClientSessions 设置，默认值为 50。您可以将 MaxClientSessions 参数设置为 0 到 1000 之间的任何值。除了这个最大值外，Vertica 还允许每个节点最多五个管理会话。

例如：

=> ALTER DATABASE DEFAULT SET MaxClientSessions = 100;

注意

如果使用管理工具 (Administration Tools) 的“连接到数据库 (Connect to Database)”选项，则当本地连接未成功时，Vertica 将会尝试连接到其他节点。与您在给定 MaxClientSessions 值的情况下的预期相比，这些情况可以产生更多成功的“连接到数据库 (Connect to Database)”命令。

查看会话

系统表 SESSIONS 包含有关用户会话的详细信息，每个会话将返回一行。超级用户可以无限制地访问所有数据库元数据。其他用户的访问权限因他们的权限而异。

中断和关闭会话

您可以使用 Vertica 函数 INTERRUPT_STATEMENT 中断正在运行的语句。中断正在运行的语句会将会话返回到空闲状态：

没有语句或事务正在运行。
没有保留任何锁。
数据库不代表会话做任何工作。

关闭用户会话将中断该会话并处置与其相关的所有状态，包括用于目标会话的客户端套接字连接。以下 Vertica 函数关闭一个或多个用户会话：

SELECT 用来调用这些函数的 SELECT 语句在中断或关闭消息传递到所有节点后返回。该函数可能会在 Vertica 完成中断或关闭操作的执行之前返回。因此，在语句返回之后以及在中断或关闭操作在整个群集中生效过程中可能存在一个延迟。若要确定会话或事务是否结束，请查询 SESSIONS 系统表。

为了关闭数据库，您必须首先关闭所有用户会话。有关数据库关闭的更多信息，请参阅停止数据库。

6.6.2 - 管理加载流

您可以使用系统表 LOAD_STREAMS 在数据加载到群集时对数据进行监控。此表中的几列显示每个节点上每个加载流的指标，包括：

取决于数据大小，在 PARSE_COMPLETE_PERCENT 达到 100% 的时间与 SORT_COMPLETE_PERCENT 开始增长的时间之间可能会出现明显的滞后。