复制子群集

子群集包含许多设置，您可以对其进行优化，以使它们按照您想要的方式工作。优化子群集后，您可能需要使用以相同方式配置的其他子群集。例如，假设您有一个已优化为执行分析工作负载的子群集。为了提高查询吞吐量，您可以再创建多个配置与其完全相同的子群集。您可以将现有子群集（称为源子群集）复制到新子群集（目标子群集），而不是创建新的子群集后再从头开始手动配置它们。

当您基于另一个子群集创建新子群集时，Vertica 会复制源子群集的大部分设置。有关 Vertica 复制的设置的列表，请参阅下文。这些设置都处于节点级别和子群集级别。

目标子群集的要求

数据库群集中必须有一组您会将其用作子群集复制目标的主机。Vertica 会将这些主机组成一个目标子群集，用于接收源子群集的大部分设置。目标子群集的主机必须满足以下要求：

  • 它们必须是数据库群集的一部分，但不是数据库的一部分。例如，您可以使用从子群集中删除的主机或已移除其子群集的主机。如果您尝试将子群集复制到当前参与数据库的一个或多个节点上，Vertica 会返回错误。

  • 您为目标子群集提供的节点数必须等于源子群集中的节点数。复制子群集时，Vertica 会将源子群集中每个节点的一些节点级别设置原封不动地复制到目标中的相应节点。

  • 目标子群集中主机的 RAM 和磁盘分配至少应与源节点相同。从技术角度而言，您的目标节点可以拥有比源节点更少的 RAM 或磁盘空间。但是，您通常会在新子群集中遇到性能问题，因为原始子群集的设置不会针对目标子群集的资源进行优化。

即使源子群集中的某些节点或目标中的主机已关闭，您也可以复制子群集。如果目标中的节点已关闭，它们会在恢复时使用 Vertica 从源节点复制的编录。

复制子群集级别设置

下表列出了 Vertica 从源子群集复制到目标的子群集级别设置。

Vertica 不会 复制以下子群集设置：

复制节点级别设置

当 Vertica 复制子群集时，它会将源子群集中的每个节点映射到目标子群集中的节点。然后，它会将相关的节点级别设置从每个单独的源节点复制到相应的目标节点。

例如，假设您有一个由名为 node01、node02 和 node03 的节点组成的三节点子群集。目标子群集具有名为 node04、node05 和 node06 的节点。在这种情况下，Vertica 会将设置从 node01 复制到 node04，从 node02 复制到 node05，以及从 node03 复制到 node06。

Vertica 从源节点复制到目标节点的节点级别设置包含：

Vertica 不会 复制以下节点级别设置：

使用 admintools 复制子群集

要复制子群集，请使用创建新子群集所用的 admintools db_add_subcluster 工具（请参阅创建子群集）。除了创建子群集所需的选项（主机列表、新子群集的名称、数据库名称等）之外，您还可以将 --like 选项与要复制的源子群集名称一起传递。

以下示例演示了如何复制名为 analytics_1 的三节点子群集。第一个示例会检查 analytics_1 子群集中的一些设置：

  • 覆盖全局 TM 资源池的内存大小。

  • 它自己的名为 analytics 的资源池

  • 它在名为 analytics 的基于子群集的负载均衡组中的成员身份

=> SELECT name, subcluster_name, memorysize FROM SUBCLUSTER_RESOURCE_POOL_OVERRIDES;
 name | subcluster_name | memorysize
------+-----------------+------------
 tm   | analytics_1     | 0%
(1 row)

=> SELECT name, subcluster_name, memorysize, plannedconcurrency
      FROM resource_pools WHERE subcluster_name IS NOT NULL;
      name      | subcluster_name | memorysize | plannedconcurrency
----------------+-----------------+------------+--------------------
 analytics_pool | analytics_1     | 70%        | 8
(1 row)

=> SELECT * FROM LOAD_BALANCE_GROUPS;
   name    |   policy   |  filter   |    type    | object_name
-----------+------------+-----------+------------+-------------
 analytics | ROUNDROBIN | 0.0.0.0/0 | Subcluster | analytics_1
(1 row)

以下示例会调用 admintool 的 db_add_subcluster 工具以将 analytics_1 子群集复制到由三个主机组成的主机组，以创建名为 analytics_2 的子群集。

$ admintools -t db_add_subcluster -d verticadb \
             -s 10.11.12.13,10.11.12.14,10.11.12.15 \
          -p mypassword --like=analytics_1 -c analytics_2

Creating new subcluster 'analytics_2'
Adding new hosts to 'analytics_2'
Eon database detected, creating new depot locations for newly added nodes
Creating depot locations for 1 nodes
 Warning when creating depot location for node: v_verticadb_node0007
 WARNING: Target node v_verticadb_node0007 is down, so depot size has been
          estimated from depot location on initiator. As soon as the node comes
          up, its depot size might be altered depending on its disk size
Eon database detected, creating new depot locations for newly added nodes
Creating depot locations for 1 nodes
 Warning when creating depot location for node: v_verticadb_node0008
 WARNING: Target node v_verticadb_node0008 is down, so depot size has been
          estimated from depot location on initiator. As soon as the node comes
          up, its depot size might be altered depending on its disk size
Eon database detected, creating new depot locations for newly added nodes
Creating depot locations for 1 nodes
 Warning when creating depot location for node: v_verticadb_node0009
 WARNING: Target node v_verticadb_node0009 is down, so depot size has been
          estimated from depot location on initiator. As soon as the node comes
          up, its depot size might be altered depending on its disk size
Cloning subcluster properties
NOTICE: Nodes in subcluster analytics_1 have network addresses, you
might need to configure network addresses for nodes in subcluster
analytics_2 in order to get load balance groups to work correctly.

    Replicating configuration to all nodes
    Generating new configuration information and reloading spread
    Starting nodes:
        v_verticadb_node0007 (10.11.12.81)
        v_verticadb_node0008 (10.11.12.209)
        v_verticadb_node0009 (10.11.12.186)
    Starting Vertica on all nodes. Please wait, databases with a large catalog
         may take a while to initialize.
    Checking database state for newly added nodes
    Node Status: v_verticadb_node0007: (DOWN) v_verticadb_node0008:
                 (DOWN) v_verticadb_node0009: (DOWN)
    Node Status: v_verticadb_node0007: (INITIALIZING) v_verticadb_node0008:
                 (INITIALIZING) v_verticadb_node0009: (INITIALIZING)
    Node Status: v_verticadb_node0007: (UP) v_verticadb_node0008:
                 (UP) v_verticadb_node0009: (UP)
Syncing catalog on verticadb with 2000 attempts.
    Multi-node DB add completed
Nodes added to subcluster analytics_2 successfully.
Subcluster added to verticadb successfully.

重新运行示例第一部分中的查询后，系统将显示 analytics_1 中的设置已复制到 analytics_2 中：

=> SELECT name, subcluster_name, memorysize FROM SUBCLUSTER_RESOURCE_POOL_OVERRIDES;
 name | subcluster_name | memorysize
------+-----------------+------------
 tm   | analytics_1     | 0%
 tm   | analytics_2     | 0%
(2 rows)

=> SELECT name, subcluster_name, memorysize, plannedconcurrency
       FROM resource_pools WHERE subcluster_name IS NOT NULL;
      name      | subcluster_name | memorysize |  plannedconcurrency
----------------+-----------------+------------+--------------------
 analytics_pool | analytics_1     | 70%        | 8
 analytics_pool | analytics_2     | 70%        | 8
(2 rows)

=> SELECT * FROM LOAD_BALANCE_GROUPS;
   name    |   policy   |  filter   |    type    | object_name
-----------+------------+-----------+------------+-------------
 analytics | ROUNDROBIN | 0.0.0.0/0 | Subcluster | analytics_2
 analytics | ROUNDROBIN | 0.0.0.0/0 | Subcluster | analytics_1
(2 rows)

如前所述，即使 analytics_2 子群集是分析负载均衡组的一部分，其节点也没有为它们定义网络地址。在您为节点定义网络地址之前，Vertica 无法将客户端连接重定向到这些节点。