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

返回本页常规视图.

大型群集

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

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

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

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

大型群集和数据库增长

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

  • 在企业模式下，如果为数据库群集配置的控制节点数大于其包含的当前节点数，Vertica 会将新节点设为控制节点。在 Eon 模式下，在子群集级别设置控制节点的数量。如果为包含新节点的子群集设置的控制节点数小于此设置，Vertica 会将新节点设为控制节点。

  • 如果企业模式群集或 Eon 模式子群集已达到其控制节点限制，则新节点将成为现有控制节点的依赖节点。

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

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

  • Eon 模式数据库：Vertica 始终将新节点添加到子群集。Vertica 将新节点分配给该子群集中具有最少依赖节点的控制节点。启用了大型群集的 Eon 模式数据库中的每个子群集都至少有一个控制节点。将依赖节点与其控制节点保持在同一个子群集中可以保持子群集隔离。

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

何时启用大型群集

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

  • 数据库群集包含 120 个或更多节点。对于企业模式和 Eon 模式都是如此。

  • 您创建一个包含 16 个或更多初始节点的 Eon 模式 子群集（ 主要子群集或一个 辅助子群集）。

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

您可以选择在 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 - 计划大型群集

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

  • 数据库群集应该有多少个控制节点？

  • 这些控制节点应该如何分布？

确定控制节点的数量

当您手动启用大型群集或添加足够的节点触发 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 个节点作为依赖项。

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

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

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

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 设置初始 默认子群集中的控制节点数。此设置对您稍后创建的 子群集不起作用。

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 调用 REALIGN_CONTROL_NODES 函数。此函数告诉 Vertica 重新评估群集或子群集中控制节点及其依赖项的分配。在 Eon 模式数据库中调用此函数时，必须提供在其中更改控制节点设置的子群集的名称。

  2. 调用 RELOAD_SPREAD 函数。此函数更新配置文件中的控制节点分配信息，并触发 Spread 重新加载。

  3. 重新启动受控制节点变更影响的节点。在企业模式数据库中，必须重新启动整个数据库，才能确保所有节点都已更新配置信息。在 Eon 模式下，重新启动受变更影响的一个或多个子群集。如果您更改了关键子群集（例如唯一的 主子群集），则必须重新启动整个 Eon 模式数据库。

  4. 在企业模式数据库中，调用 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)

4 - 监控大型群集

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

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