Vertica 能够在正在处理查询的实时群集上添加、移除和替换节点。此功能使您可在不中断用户的情况下扩展数据库。
管理节点
- 1: 在节点上停止 Vertica
- 2: 在节点上重新启动 Vertica
- 3: 设置节点类型
- 4: 活动备用节点
- 4.1: 创建活动备用节点
- 4.2: 使用活动备用节点替换节点
- 4.3: 恢复活动备用节点
- 5: 大型群集
- 5.1: 计划大型群集
- 5.2: 启用大型群集
- 5.3: 更改控制节点的数量并重新对齐
- 5.4: 监控大型群集
- 6: 容错组
- 7: Terrace 路由
- 8: 弹性群集
- 9: 添加节点
- 10: 移除节点
- 10.1: 自动逐出运行状况不佳的节点
- 10.2: 降低 K‑Safety 以启用节点移除
- 10.3: 从数据库中移除节点
- 10.4: 从群集中移除主机
- 11: 替换节点
- 11.1: 使用相同的名称和 IP 地址替换主机
- 11.2: 使用具有不同 IP 地址的节点替换故障节点
- 11.3: 使用不同的名称和 IP 地址替换正常运行的节点
- 11.4: 使用管理工具替换节点
- 12: 在节点之间重新平衡数据
- 12.1: 使用管理工具 UI 重新平衡数据
- 12.2: 使用 SQL 函数重新平衡数据
- 13: 向节点重新分发配置文件
- 14: 在 MC 上停止和启动节点
- 15: 映射新 IP 地址
- 15.1: 使用映射文件更改 IP 地址
- 15.2: Re-IP 命令行选项
- 15.3: 重新启动具有新主机 IP 的节点
1 - 在节点上停止 Vertica
在某些情况下，您需要关闭节点才能执行维护任务或升级硬件。可以通过以下方法之一执行此操作：
重要
在从群集中移除节点之前，请检查群集是否具有符合 K-safety 所需的最少节点数。如有必要，请暂时降低数据库的 K‑safety 级别。管理工具
-
运行管理工具 (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
2 - 在节点上重新启动 Vertica
在停止节点以执行维护任务（如升级硬件）之后，需要重新启动该节点才能重新连接数据库群集。
-
运行管理工具。从“主菜单 (Main Menu)”中选择在主机上重新启动 Vertica (Restart Vertica on Host)，然后单击确定 (OK)。
-
选择数据库并单击确定 (OK)。
-
选择要重新启动的主机并单击确定 (OK)。
注意
此操作可能需要一些时间。 -
返回主菜单，选择查看数据库群集状态 (View Database Cluster State)，然后单击确定 (OK)。您重新启动的主机现在显示为 UP，如下图所示。
3 - 设置节点类型
创建节点时，Vertica 会自动将其类型设置为 PERMANENT。这使 Vertica 可以使用此节点来存储数据。您可以使用
ALTER NODE 将节点的类型更改为以下类型之一：
-
PERMANENT：（默认值）：存储数据的节点。
-
EPHEMERAL：从一种类型转换到另一种类型的节点——通常是从 PERMANENT 到 STANDBY 或 EXECUTE。
-
STANDBY：保留以在任何节点发生故障时替换该节点的节点。备用节点不存储段或数据，直到它被调用以替换故障节点。当用作替换节点时，Vertica 将其类型更改为 PERMANENT。有关详细信息，请参阅活动备用节点。
-
EXECUTE：该节点仅为计算目的而保留。执行节点不包含段或数据。
注意
仅 Enterprise 模式支持 STANDBY 和 EXECUTE 节点类型。4 - 活动备用节点
活动备用节点是企业模式数据库中可用于替换任何故障节点的节点。与标准 Vertica 节点不同，备用节点不执行计算或包含数据。如果永久节点出现故障，那么在故障节点超过故障转移时间限制后，活动备用节点可以替换故障节点。替换故障节点后，活动备用节点包含投影并执行它所替换的节点的全部计算。
此部分内容
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;
4.2 - 使用活动备用节点替换节点
企业模式数据库上的故障节点可以自动或手动替换为活动备用节点。
重要
节点必须处于关闭状态，之后才能使用活动备用节点替换它。尝试替换正常运行的节点会返回错误。自动替换
您可以使用参数 FailoverToStandbyAfter 配置故障节点的自动替换。如果启用了此参数，它将指定活动备用节点等待多长时间后替换故障节点。如果可以，Vertica 将从故障节点所在的容错组中选择备用节点。否则，Vertica 将随机选择一个可用的活动备用节点。
手动替换
作为管理员，您可以使用 ALTER NODE 手动替换故障节点：
4.3 - 恢复活动备用节点
当企业模式数据库中的已关闭节点准备好重新激活时，您可以还原该节点，方法是将其替换节点恢复为备用状态。您可以使用 ALTER NODE 针对单个节点执行此操作，或使用 ALTER DATABASE 针对整个数据库执行此操作：
-
恢复备用节点。
-
使用 ALTER NODE 恢复单个节点：
ALTER NODE node‑name RESET; -
使用 ALTER DATABASE 恢复整个数据库群集中的节点：
ALTER DATABASE DEFAULT RESET STANDBY;
-
如果关闭的节点无法恢复操作，Vertica 会忽略重置请求并将备用节点留在原地。
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 数据包大小限制。
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 个节点的限制。
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 模式子群集中的控制节点数。
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)
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 — 显示参与数据库群集的节点和影响这些节点的容错组的实际排列的相对位置。
6 - 容错组
注意
您不能为 Eon 模式数据库创建容错组。相反，Vertica 会自动在大型 Eon 群集数据库上创建容错组；这些容错组围绕每个子群集的控制节点及其依赖项进行配置。这些容错组由 Vertica 内部管理，无法供用户访问。容错组允许您为物理群集布局配置企业模式数据库。共享您的群集拓扑让您可以使用 Terrace 路由来减少大型查询的缓冲区要求。它还有助于最大限度地降低环境中固有的相关故障所带来的风险，这些故障通常由共享资源引起。
Vertica 将在大型群集排列中的 控制节点（运行 spread 的服务器）周围自动创建容错组，将共享控制节点的节点放在同一容错组中。自动容错组和用户定义的容错组不包括暂时节点，因为类似的节点不容纳数据。
如果要执行以下操作，请考虑定义您自己的特定于群集物理布局的容错组：
-
使用 Terrace 路由来减少大型查询的缓冲区要求。
-
降低相关故障的风险。例如，通过定义机架布局，Vertica 对故障的容忍度更高。
-
影响控制节点在群集中的放置。
Vertica 支持使用具有不同形状和大小的复杂、层次结构容错组。数据库平台提供容错组脚本（DDL 生成器）、SQL 语句、系统表和其他监控工具。
有关包含群集拓扑示例的容错组的概述，请参阅使用容错组的高可用性。
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
另请参阅
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 群集上，并且该群集使用多个机架，您可以使用容错组来提高性能。请参阅配置机架位置。
另请参阅
创建容错组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();
另请参阅
6.4 - 监控容错组
您可以通过查询 Vertica 系统表或登录到管理控制台界面监控容错组。
使用系统表监控容错组
使用以下系统表查看与容错组和群集缺陷有关的信息，例如在不关闭数据库的情况下群集无法丢失的节点：
-
V_CATALOG.FAULT_GROUPS：查看群集中所有容错组的层次结构。
-
V_CATALOG.CLUSTER_LAYOUT：观察参与数据业务的节点的排列以及影响这些节点的容错组。临时节点不显示在群集布局环中，因为它们没有任何数据。
使用管理控制台监控容错组
MC 管理员可以通过以下步骤监控和突出显示感兴趣的容错组：
-
单击要监控的正在运行的数据库，然后在任务栏中单击管理 (Manage)。
-
打开容错组视图 (Fault Group View) 菜单，然后选择要查看的容错组。
-
（可选）隐藏不在选定容错组中的节点以关注感兴趣的容错组。
分配给容错组的节点每个都在节点图标左上角有一个彩色气泡。每个容错组都有一个独特的颜色。如果容错组的数量超过可用的颜色数量，MC 将循环使用先前使用的颜色。
由于 Vertica 支持不同形状和大小的复杂分层容错组，因此 MC 将多个容错组的参与显示为一堆不同颜色的气泡。气泡越高，代表容错组的层次越低，这意味着气泡更接近父容错组（而不是子容错组或孙容错组）。
有关容错组层次结构的详细信息，请参阅容错组的高可用性。
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 语句。
另请参阅
7 - 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 内部管理，无法供用户访问。
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 重新平衡数据库时，伸缩系数才会发挥作用。重新平衡时，每个节点都会将它包含的投影分段拆分到存储容器中，然后根据需要将存储容器移动至其他节点。重新平衡后，数据会重新合并到
启用弹性群集
使用 ENABLE_ELASTIC_CLUSTER 启用弹性群集。查询 ELASTIC_CLUSTER 系统表来验证弹性群集是否已启用：
=> SELECT is_enabled FROM ELASTIC_CLUSTER;
is_enabled
------------
t
(1 row)
8.1 - 伸缩系数
为避免 ROS 容器数量增加，请不要启用局部分段，也不要更改伸缩系数。
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)
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)
8.4 - 局部数据分段
默认情况下，只有当 Vertica 重新平衡数据库时，伸缩系数才会发挥作用。在重新平衡期间，节点会将其包含的投影分段分解到多个存储容器中，以便它们能够快速移动到其他节点。
与对整个投影进行重新分段相比，此过程更加高效（特别是，它需要更少的可用磁盘空间），但是仍然需要较大开销，因为必须将存储容器分离到多个局部分段中，然后将其中一些局部分段传输到其他节点。如果您很少从数据库中添加或移除节点，此开销并不算是一个问题。
但是，如果您的数据库增长快速并且持续处于繁忙状态，则可能会发现添加节点的过程将变得具有破坏性。这种情况下，您可以启用局部分段，这会告诉 Vertica 始终根据伸缩系数对其数据进行分段，因此始终将数据分解到多个易于移动的容器中。通过这种方式对数据进行分段会显著提高添加或删除节点的速度，因为数据始终处于一种可以快速重新定位到另一个节点的状态。Vertica 在添加或移除节点后执行的重新平衡过程只需要决定要重新定位的存储容器即可，无须首先将数据分解到存储容器中。
局部数据分段会增加存储在每个节点上的存储容器数量。除非表包含许多分区，否则这算不上一个问题。（例如，如果表按天进行分区并包含一个或多个年份。）如果启用局部数据分段，则会将其中每个表分区分解到多个局部存储分段中，这可能会生成大量文件，进而可能导致 ROS“推回”。请先考虑表分区以及启用局部数据分段可能造成的影响，然后再启用此功能。
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)
8.5 - 弹性群集最佳实践
下面是一些关于局部分段的最佳实践。
注意
您应始终在执行本主题讨论的任何操作之前和之后执行数据库备份。在更改任何弹性群集或局部分段设置之前需要进行备份，以防止可导致重新平衡过程，使数据库处于不可用状态的硬件故障。在重新平衡过程之后，应执行数据库完整备份，以避免在从备份还原时需要再次重新平衡数据库。何时启用局部数据分段
局部数据分段 可以显著加快调整群集大小的过程。在以下情况下，应当启用局部数据分段：
-
数据库不包含具有数百个分区的表。
-
数据库群集中的节点数为 2 的幂次方。
-
计划扩大或缩小群集大小。
局部分段可能会导致具有数百个分区的表或节点数不是 2 的幂次方的群集的存储容器数量过多。如果您的数据库具有这两个特征，在启用局部分段时请小心。
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 会自动将更新后的配置文件分布到群集中的其余节点，并启动在群集中重新平衡数据的过程。有关详细信息，请参阅在节点之间重新平衡数据。
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
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 向企业模式数据库中添加节点，请参阅 向群集中添加主机
10 - 移除节点
永久删除节点虽然不像添加节点那样常见，但如果主机系统过时或过度配置，它将非常有用。
重要
在从群集中移除节点之前，请检查群集是否具有符合 K-safety 所需的最少节点数。如有必要，请暂时降低数据库的 K‑safety 级别。10.1 - 自动逐出运行状况不佳的节点
为了管理群集中节点的运行状况，Vertica 通过发送和接收检测信号来定期执行运行状况检查。在运行状况检查期间，群集中的每个节点都会验证对其编录、编录磁盘和本地存储位置（'TEMP、DATA'、TEMP、DATA 和 DEPOT）的读写访问权限。验证后，节点发送检测信号。如果一个节点在五个间隔后未能发送检测信号（五次运行状况检查失败），则会将该节点从群集中逐出。
您可以使用 DatabaseHeartBeatInterval 参数控制相邻两次运行状况检查之间的时间。默认情况下，DatabaseHeartBeatInterval 设置为 120，即允许在无检测信号的情况下经过五个 120 秒的间隔。
逐出前允许的时间长度为：
TOT = DHBI * 5
其中，TOT 是在逐出之前所允许的无检测信号总时间（以秒为单位），DHBI 等于 DatabaseHeartBeatInterval 的值。
如果您设置的 DatabaseHeartBeatInterval 值过低，则可能导致节点在出现短暂的运行状况问题时被逐出。有时，此类过早逐出会降低 Vertica 数据库的可用性和性能。
另请参阅
常规参数中的 DatabaseHeartbeatInterval 常规参数
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，请首先备份数据库。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。
-
如果该主机未被群集中的任何其他数据库使用，您可以从群集中移除该主机。请参阅从群集中移除主机。
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。
11 - 替换节点
如果您具有 K-safe 数据库，则可根据需要替换节点，而且不会降低系统性能。例如，您可以希望在以下情况下替换现有节点：
-
需要修复不再正常运行的现有主机系统并将其恢复为群集
-
要将现有主机系统换成更加强大的另一系统
用于替换节点的过程取决于您是否正在将节点替换为：
-
使用相同名称和 IP 地址的主机
-
使用不同名称和 IP 地址的主机
-
活动的备用节点
先决条件
-
配置 Vertica 的替换主机。请参阅在安装 Vertica 之前。
-
确保新主机上存在数据库管理员用户且其配置方式与现有主机相同。Vertica 将根据需要设置免密码 ssh。
-
确保将编录路径、数据路径和任何存储位置的目录在创建数据库时已添加到数据库中，并且/或者这些目录已正确安装到新主机上，而且数据库管理员用户具有读写访问权限。另请确保有足够的磁盘空间。
-
按照下面的最佳实践步骤将故障硬件重新引入群集中，从而避免虚假完整节点重建。
按照下述过程进行操作可防止 Vertica 将磁盘缺失或挂载错误的情况错误地诊断为数据损坏，进而避免发生耗时的全节点恢复。
如果服务器因硬件问题（例如磁盘错误或控制器故障）而发生故障，请在修复硬件时：
-
将计算机重启至运行级别 1，这是仅适用于控制台的 root 模式。
运行级别 1 可禁止网络连接并阻止 Vertica 尝试重新连接到群集。
-
在运行级别 1 中，验证硬件是否已得到修复，控制器是否处于联机状态，以及是否可以继续执行任何 RAID 恢复操作。
注意
在运行级别 1 中，无需初始化 RAID 恢复；只需验证其是否可以恢复。 -
只有在确认硬件一致之后才能重启至运行级别 3 或更高级别。
此时将激活网络，同时 Vertica 会重新加入群集并自动恢复任何缺失的数据。请注意，在单节点数据库中，如果与投影关联的任何文件被删除或损坏，Vertica 将删除与该投影关联的所有文件，这可能会导致数据丢失。
11.1 - 使用相同的名称和 IP 地址替换主机
如果已移除现有 Vertica 数据库的主机，您可以在该数据库正在运行时替换此主机。
注意
请记住，Vertica 中的主机由 Vertica 软件所在的硬件和操作系统以及相同的网络配置组成。您可以将此主机替换为与旧主机具有以下相同特征的新主机：
-
名称
-
IP 地址
-
操作系统
-
操作系统管理员用户
-
目录位置
在数据库正在运行时替换主机可防止系统停机。在替换主机之前，请首先备份您的数据库。有关详细信息，请参阅备份和还原数据库。
按照如下方式替换为具有以下相同特征的主机：
-
使用 --rpm 或 --deb 参数从正常运行的主机运行 install_vertica：
$ /opt/vertica/sbin/install_vertica --rpm rpm_package有关详细信息，请参阅使用命令行安装。
-
使用现有节点中的管理工具重新启动新主机。请参阅在节点上重新启动 Vertica。
节点即会自动加入数据库，并通过查询数据库中的其他节点恢复其数据。随后它会过渡为 UP 状态。
11.2 - 使用具有不同 IP 地址的节点替换故障节点
使用 IP 地址与原始地址不同的主机系统替换故障节点包含以下步骤：
-
Vertica 建议您在执行这项重大操作前先备份数据库，因为在操作过程中需要执行创建新投影、删除旧投影和重新加载数据的操作。
-
将新主机添加到群集中。请参阅向群集中添加主机。
-
如果 Vertica 仍在将被替换节点中运行，请使用管理工具在将被替换的主机上停止主机上的 Vertica。
-
使用向新主机分发配置文件将元数据传输到新主机。
-
使用管理工具在主机上重新启动 Vertica。在主菜单 (Main Menu) 上，选择在主机上重新启动 Vertica (Restart Vertica on Host)，然后单击确定 (OK)。有关详细信息，请参阅启动数据库。
完成此过程后，替换节点将查询数据库内的其他节点，从而自动恢复存储在原始节点中的数据。
11.3 - 使用不同的名称和 IP 地址替换正常运行的节点
使用 IP 地址和主机名与原始值不同的主机系统替换节点包含以下常规步骤：
-
Vertica 建议您在执行这项重大操作前先备份数据库，因为在操作过程中需要执行创建新投影、删除旧投影和重新加载数据的操作。
-
此时，您要删除的原始主机和新替换主机均为群集成员。
-
使用管理工具在将被替换的主机上停止主机上的 Vertica。
-
重新启动主机上的 Vertica。
完成此过程后，替换节点将查询数据库内的其他节点，从而自动恢复存储在原始节点中的数据。随后它会过渡为 UP 状态。
注意
如果您不从群集中删除原始主机且尝试重新启动数据库，则该主机不会被邀请加入数据库，因为其节点地址与存储在数据库编录中的新地址不匹配。因此，它仍保持 INITIALIZING 状态。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 的数据库，则数据库的当前容错能力处于关键级别。如果您又失去一个节点，则数据库将关闭。确保您未停止任何其他节点。
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。
临时表
节点重新平衡对临时表的投影没有影响。
有关重新平衡的详细信息
请参阅知识库文章：
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 返回管理工具。
12.2 - 使用 SQL 函数重新平衡数据
Vertica 具有三个用于启动和停止群集重新平衡的 SQL 函数。您可以从在非高峰时段运行的脚本调用这些函数，而不是通过管理工具手动触发重新平衡。
-
REBALANCE_CLUSTER作为会话前台任务同步重新平衡数据库群集。 -
START_REBALANCE_CLUSTER()作为后台任务异步重新平衡数据库群集。 -
CANCEL_REBALANCE_CLUSTER停止任何正在进行中或正在等待执行的重新平衡任务。
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
14 - 在 MC 上停止和启动节点
您可以在管理 (Manage) 页面单击特定节点以选择它，然后单击“节点列表 (Node List)”中的“启动 (Start)”或“停止 (Stop)”按钮，以此来启动或停止一个或多个数据库节点。
注意
工具栏中的“启动 (Start)”或“停止 (Stop)”按钮启动和停止的是数据库，而不是单个节点。在数据库和群集 (Databases and Clusters) 页面，您必须首先单击选择数据库。要在该数据库中停止或启动节点，请单击查看 (View) 按钮。您将转到“概览 (Overview)”页面。单击页面底部小程序面板中的管理 (Manage)，随后您将转到数据库节点视图。
“启动 (Start)”和“停止 (Stop)”数据库按钮始终处于活动状态，但是只有当选择的一个或多个节点处于相同状态时，节点“启动 (Start)”或“停止 (Stop)”按钮才会处于活动状态；例如，所有节点都是 UP 或 DOWN。
单击“启动 (Start)”或“停止 (Stop)”按钮后，管理控制台会为您正在启动或停止的节点或数据库更新状态和消息图标。
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。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 -
使用该文本文件创建可用于执行下列任务之一的映射文件：
-
创建采用如下格式的映射文件：
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.255controlAddress 和 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 运行。
-
-
创建采用如下格式的映射文件：
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 -
重新启动数据库。
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 ControlBroadcastNodeName 和 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
-
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