您可以在 Eon 模式而不是企业模式下操作 Vertica 数据库。这两种模式的主要区别在于它们存储数据的方式：
-
Eon 模式数据库使用公共存储来存储其数据。
-
企业模式数据库将数据本地存储在组成数据库的节点的文件系统中。
这些不同的存储方法导致两种模式之间存在许多重要差异。在企业模式中，每个数据库节点存储一部分数据并执行一部分计算。在 Eon 模式中，计算过程与公共（共享）存储层分离，这使得计算资源能够随着需求的变化而快速扩展。
有关这两种模式如何比较的详细信息，请参阅体系结构。
Eon 模式
- 1: 在 Eon 模式下创建数据库
- 2: 为 Eon 模式配置 Vertica 群集
- 3: 将企业数据库迁移到 Eon 模式
- 4: 管理子群集
- 4.1: 创建子群集
- 4.2: 复制子群集
- 4.3: 在子群集中添加和移除节点
- 4.4: 使用子群集管理工作负载
- 4.5: 启动和停止子群集
- 4.6: 更改子群集设置
- 4.7: 移除子群集
- 5: 存储库管理
- 6: 扩展 Eon 模式数据库
- 6.1: 更改数据库中的分片数
- 6.2: 使用子群集提高查询吞吐量
- 6.3: 使用 Elastic Crunch Scaling 提高查询性能
- 6.4: 手动选择 ECS 策略
- 7: 存储容器的本地缓存
- 8: 在 MC 中管理 Eon 模式数据库
- 9: 停止和启动 Eon 模式群集
- 10: 终止 Eon 模式数据库群集
- 11: 恢复 Eon 模式数据库群集
- 12: 同步元数据
1 - 在 Eon 模式下创建数据库
在云环境中创建 Eon 模式数据库
在云中创建 Eon 模式数据库的最简单方法是使用 MC。MC 可以为您创建数据库并将节点配置为同时运行数据库。有关详细信息，请参阅使用 MC 创建数据库。有关云环境的具体说明，请参阅：
在 AWS 上，还可以使用 admintools 创建数据库：
-
手动为新数据库配置节点。有关说明，请参阅为 Vertica 数据库群集部署 AWS 实例。
-
使用 admintools 创建数据库。有关步骤，请参阅创建 Eon 模式数据库。
创建内部部署 Eon 模式数据库
如果您有内部部署安装，则可以使用 admintools 创建 Eon 模式数据库。有关详细信息，请参阅公共存储后端安装说明中的“创建数据库”步骤：
2 - 为 Eon 模式配置 Vertica 群集
在 Eon 模式下运行 Vertica 可将群集大小从数据量中分离出来，让您可以独立于存储需求来配置计算需求。在决定使用哪种类型的实例以及 Eon 模式群集的大小时，您必须考虑许多因素。
开始操作之前
Vertica Eon 模式可在云和本地工作。作为 Vertica 管理员，设置在 Eon 模式下运行的生产群集时，您必须决定要使用的虚拟或物理硬件以满足您的需求。本主题为在 Eon 模式下运行的 Vertica 数据库选择服务器类型和群集大小提供指南和最佳实践，并假设您对 Eon 模式架构和概念（例如 公共存储、 存储库和 分片）具有基本的了解。如果需要增加了解程度，请参阅 Eon 模式体系结构。
群集大小概述
由于 Eon 模式将数据存储与节点的计算能力分开，因此选择群集大小比选择企业模式数据库更复杂。通常，您选择的节点基数将构成一个或多个 主子群集。这些子群集包含始终在数据库中运行的节点。您通常会将它们用于数据加载和执行 DDL 语句等工作负载，很少会动态更改这些子群集的大小。由于需要额外的计算资源来执行查询，因此您可以向数据库中添加一个或多个节点子群集（通常是 辅助子群集）。
在为 Eon 模式选择实例和调整群集大小时，请考虑数据库将要处理的工作数据大小。这是大多数查询会处理的数据量。例如，假设您的数据库存储的是销售数据。如果您的数据库上运行的大多数查询对过去一两个月的销售情况进行分析以创建有关销售趋势的报告，那么工作数据大小就是您通常在几个月内加载的数据量。
选择实例或物理硬件
根据工作负载的复杂性和预期并发性，请选择具有足够 CPU 和内存的物理或虚拟硬件。对于生产群集，Vertica 建议对 Eon 模式数据库中的虚拟或物理节点进行以下最低配置：
-
16 核
-
128 GB RAM
-
2 TB 本地存储
注意
上述规格只是最低建议值。您应考虑根据工作负载和正在处理的数据量增加这些规格值。Eon 模式数据库群集中必须至少有 3 个节点。
有关基于云的 Eon 模式数据库实例的具体建议，请参阅：
确定本地存储要求
对于虚拟和物理硬件，您必须确定节点所需的本地存储量。在 Eon 模式下，数据库数据的最终副本驻留在公共存储中。此存储由基于云的对象存储（如 AWS S3）或本地对象存储（如 Pure Storage FlashBlade 设备）提供。
即使数据库的数据存储在公共存储中，节点也仍需一些本地存储。Eon 模式数据库中的节点会出于三种用途使用本地存储：
-
存储库存储：要以最短的时间响应频繁执行的查询，请提供足够大的存储库以在数据压缩后保存工作数据集。将工作数据大小除以子群集中拥有的节点数，可以估计出子群集中每个节点所需的存储库大小。请参阅下面的选择分片数和初始节点数，以了解您希望在初始数据库子群集中拥有的节点数量。如果您希望动态扩展群集，请根据您预计在子群集中拥有的最小节点数来估计存储库大小。
还需考虑在调整存储库大小时一次加载的数据量。加载数据时，Vertica 会默认将未提交的 ROS 文件写入到存储库中，然后再将文件上传到公共存储。如果存储库中的可用空间不足，Vertica 会从存储库中逐出文件以便为新文件腾出空间。
如果您尝试在单个事务中加载的数据量大于子群集中所有存储库的总大小，则数据加载将失败。要使加载的数据量多于子群集的组合存储库中的空间，请将 UseDepotForWrites 设置为 0。此配置参数会告知 Vertica 将数据直接加载到公共存储中。
-
数据存储：数据存储位置可保存属于临时表的文件和溢出到磁盘的排序运算符中的临时数据。将数据加载到 Vertica 时，排序运算符可能会溢出到磁盘。根据加载的大小，Vertica 可能会在多个合并阶段执行排序。并发加载到 Vertica 的数据量不能大于所有节点之间的临时存储位置大小之和的一半。
-
编录存储。编录大小取决于每个分片的数据库对象数和每个节点的分片订阅数。
Vertica 建议每个节点的最小本地存储容量为 2 TB，其中 60% 会为存储库保留，其他 40% 由编录和数据位置共享。如果您确定每个节点需要大于 1.2 TB 的存储库（即 2 TB 的 60%），请添加多于此最低建议值的存储空间。您可以使用以下公式计算所需的空间：
例如，假设压缩工作数据大小为 24 TB，并且您希望拥有包含 3 个节点的初始主子群集。在等式中使用这些值所计算出的结果为 13.33 TB：
选择分片数和初始节点数
分片是 Vertica 如何在节点之间拆分公共存储中数据的责任。子群集中的每个节点需要至少订阅公共存储中的一个分片。在查询、数据加载和其他数据库任务期间，每个节点负责其订阅的分片中的数据。有关详细信息，请参阅分片和订阅。
分片与节点之间的关系是指在为数据库选择分片数量时，您必须考虑数据库中拥有的节点数。
创建数据库时设置初始分片数。如果将来群集大小或使用模式发生变化，您可以调用 RESHARD_DATABASE 来更改分片数量。有关详细信息，请参阅更改数据库中的分片数。
初始节点数是您核心主子群集中拥有的节点数。分片数应始终是节点数的倍数或除数。这样可确保分片在节点之间平均分配。例如，在一个六分片数据库中，您应该拥有包含两个、三个、六个或六的倍数个节点的子群集。如果分片数不是节点数的除数或倍数，则分片订阅不会均匀地分布在各个节点上。这会导致某些节点的负载比其他节点更重。
注意
在节点数是分片数倍数的数据库中，子群集将使用 Elastic Crunch Scaling (ECS) 将分片覆盖率平均分配给两个或更多节点。有关详细信息，请参阅使用 Elastic Crunch Scaling 提高查询性能。在选择分片数量时，请考虑如何增加或减少子群集中的节点数量。某些数量的分片可提高灵活性。例如，如果数据库中有七个分片，则这些分片只能在节点数为七的倍数的子群集中平均分配。对于包含 12 个分片的数据库，这些分片可以平均分布在具有 2 个、3 个、4 个、6 个、12 个或 12 的倍数个节点的子群集中。
下表显示了基于工作数据大小的建议分片数和初始节点数：
重要
为保证性能，建议分片与节点之比为 2:1，而不是硬限制。如果您尝试使用高于 3:1 的比率，MC 会发出警告，以确保您已将分片数的各个方面都考虑在内。分片数量对群集扩展产生的影响
为数据库选择的分片数量会影响您将来能否扩展数据库。如果分片太少，则高效扩展数据库可能受到限制。如果分片太多，则数据库性能可能受到影响。较多数量的分片会增加节点间通信和编录的复杂性。
决定分片数的一个关键因素是确定您希望扩展数据库的方式。将节点添加到数据库时可以使用两种策略。这两种策略都可以提高不同类型的数据库的性能：
-
要提高复杂且运行时间长的查询的性能，请向现有子群集添加节点。这些额外的节点会通过将负载分散到更多计算节点来提高这些复杂查询的整体性能。向子群集添加的节点数可以多于数据库中的分片数。在这种情况下，订阅同一分片的子群集中的节点会在执行查询时拆分该分片中的数据。有关详细信息，请参阅弹性。
-
要增加多个短期查询（通常称为“仪表板查询”）的吞吐量，请通过添加额外的 子群集来提高群集的并行度。子群集将独立且并行处理这些较短的查询。有关详细信息，请参阅子群集。
这两种方法都会影响您启动数据库时选择使用的分片数量。复杂的分析查询在具有更多节点的子群集上拥有更出色的性能，这意味着具有 6 个分片的 6 个节点比具有 6 个分片的 3 个节点的性能更出色。节点数多于分片数可以进一步提高性能，但性能增益不是线性的。例如，在 6 分片数据库中包含 12 个节点的子群集不如在 12 分片数据库中包含 12 个节点的子群集高效。在 6 分片数据库中的 3 节点子群集与 6 分片数据库中的 6 节点子群集之间，处理较小数据集的仪表板类型查询的性能可能没有太大区别。
通常，应选择与未来 6-12 个月的预期工作数据大小相匹配的分片数。有关扩展数据库的详细信息，请参阅弹性。
用例
下面我们来看看一些用例，了解如何调整 Eon 模式群集的大小以满足您自己的特定需求。
用例 1：在需要时而不是在高峰时通过配置来降低成本
此用例通过将群集从 6 个节点扩展到 18 个节点（3 个子群集，每个子群集包含 6 个节点）来强调在 Eon 模式下增加查询吞吐量。在此用例中，您需要在 24 TB 或更少的工作数据集上支持高并发、短查询工作负载。创建包含 6 个节点和 6 个分片的初始数据库。您可以通过在预期出现峰值加载的一周中的某些天或特定日期范围添加一个或多个子群集，按需扩展数据库以增加并发吞吐量。然后，当数据库需求较低时，可以关闭或终止添加的子群集。通过在 Eon 模式下使用 Vertica，您可以通过按需进行配置而不是针对高峰时间进行配置来降低成本。
用例 2：复杂的分析工作负载需要更多的计算节点
此用例展示了以下观点：大型工作数据集上的复杂分析工作负载可受益于较多的分片数和节点数。创建包含 24 个节点和 24 个分片的初始子群集。根据需要，您可以向初始子群集额外添加 24 个节点。这些额外添加的节点支持子群集使用 Elastic Crunch Scaling 来缩短完成复杂分析查询所需的时间。
用例 3：工作负载隔离
此用例展示了以下观点：使用单独的子群集隔离 ETL 和报告工作负载。创建包含 6 个节点和 6 个分片的初始 主子群集，以服务于 ETL 工作负载。然后，添加另一个 6 节点 辅助子群集，用于执行查询工作负载。要分离这两个工作负载，您可以在 Vertica 中配置网络负载均衡器或创建连接负载均衡策略，以根据客户端需要执行的工作负载类型引导客户端连接到正确的子群集。
3 - 将企业数据库迁移到 Eon 模式
MIGRATE_ENTERPRISE_TO_EON 函数会将企业数据库迁移到 Eon 模式。迁移过程包括以下阶段：
提示
计划如何配置目标 Eon 数据库时，应考虑 MIGRATE_ENTERPRISE_TO_EON 会创建与原始企业数据库上的节点数相同的节点数以及相等数量的分段分片。请根据情况选择合适的实例类型。迁移先决条件
必须满足以下条件；否则 MIGRATE_ENTERPRISE_TO_EON 将返回错误：
-
源企业数据库版本必须不低于 10.0。
-
源数据库中的所有节点必须处于 UP 状态，且类型为 PERMANENT 或 EPHEMERAL。通过查询 NODES 系统表进行验证：
=> SELECT node_name, node_type, node_state FROM nodes; node_name | node_type | node_state ------------------+-----------+------------ v_vmart_node0001 | PERMANENT | UP v_vmart_node0002 | PERMANENT | UP v_vmart_node0003 | PERMANENT | UP (3 rows) -
必须将源数据库配置为弹性群集。默认情况下，将自 Vertica 版本 9.2.1 起创建的任何数据库配置为弹性群集。要验证是否已将企业数据库配置为弹性群集，请查询 ELASTIC_CLUSTER 系统表：
=> SELECT is_enabled FROM elastic_cluster; is_enabled ------------ t (1 row)如果查询返回 false，请对企业数据库调用 ENABLE_ELASTIC_CLUSTER 函数。
-
源企业数据库必须根据目标 Eon 对象存储的要求（请参阅下面的配置要求）来配置 Eon 参数。
-
该数据库不得包含不受 Eon 支持的投影。
不受支持的投影
Eon 数据库不支持四种类型的投影，如下所述。如果 MIGRATE_ENTERPRISE_TO_EON 在企业数据库中找到这些投影类型中的任何一种，它将回滚迁移并在迁移错误日志中报告违规投影或其锚表。例如：
The following projections are inconsistent with cluster segmentation. Rebalance them with REBALANCE_CLUSTER() or REBALANCE_TABLE():
Projection(Anchor Table): public.incon1_p1_b0(public.incon1)
配置要求
在迁移之前，您必须在源数据库中设置某些配置参数。具体参数取决于 Eon 数据库的环境。
重要
所有参数都必须在数据库级别设置。S3：AWS、Pure Storage、MinIO
以下要求适用于所有受支持的云和非云（本地）S3 环境：AWS、Pure Storage 和 MinIO。但有一个例外：通过 AWS 从企业模式数据库迁移时不适用。
-
AWSEndpoint（仅限 Pure Storage、MinIO）
-
AWSRegion（仅限 AWS）
重要
如果使用 Pure Storage 和 MinIO 迁移到本地公共存储，请将 AWSEnableHttps 设置为与数据库 TLS 加密设置兼容：如果使用 TLS，则 AWSEnableHttps=1，否则为 0。如果设置不兼容，迁移将返回错误。Azure
-
您必须使用
azb://架构 URI 来设置用于公共数据存储的 Azure Blob 存储位置。有关此 URI 的格式，请参阅 Azure Blob 存储对象存储。 -
请选择以下身份验证方法之一以授予 Vertica 对存储位置的访问权限：
-
配置托管标识以授予 Azure VM 对存储位置的访问权限。此选项不需要在 Vertica 中进行任何配置。
-
在数据库级别设置 AzureStorageCredentials 和 AzureStorageEndpointConfig 配置参数，以使 Vertica 使用存储位置进行身份验证。
-
有关这两种身份验证方法的详细信息，请参阅 Azure Blob 存储对象存储。
GCP
HDFS
-
必须将源数据库配置为访问 HDFS，包括（如适用）高可用性 (HA) 和 Kerberos 身份验证 设置。
-
在数据库级别设置 HadoopConfDir（非 HA 环境则不需要）。
提示
如果使用 Kerberos 身份验证，请记录以下 Kerberos 配置参数的设置。您需要将这些设置应用于迁移的 Eon 数据库：
-
KerberosServiceName
-
KerberosRealm
-
KerberosKeytabFile
合规性验证
在运行迁移之前，请检查企业源数据库是否符合所有迁移要求。您可以通过将 MIGRATE_ENTERPRISE_TO_EON 的最后一个布尔实参设置为 true 来表示这是一次试运行而不是实际迁移：
=> SELECT migrate_enterprise_to_eon('s3://dbbucket', '/vertica/depot', true);
如果该函数遇到任何合规性问题，它会将这些问题写入数据库目录中的迁移错误日志 migrate_enterprise_to_eon_error.log 中。
迁移执行
MIGRATE_ENTERPRISE_TO_EON 将企业数据库迁移到 Eon 模式数据库。例如：
=> SELECT migrate_enterprise_to_eon('s3://dbbucket', '/vertica/depot', false);
如果最后一个实参被忽略或为 false，则该函数会执行迁移。MIGRATE_ENTERPRISE_TO_EON 将在前台运行，直到它返回成功或错误（阻止在源企业数据库上的同一会话中执行所有操作）。如果成功，MIGRATE_ENTERPRISE_TO_EON 将返回已迁移数据库中的节点的列表。然后，您可以继续恢复已迁移的 Eon 数据库。
处理中断的迁移
如果迁移在该函数返回结果（例如，客户端断开连接或发生网络中断）之前中断，则迁移会出错。在这种情况下，请调用 MIGRATE_ENTERPRISE_TO_EON 以重新开始迁移。
目标数据库的公共存储将保留发生错误之前已复制的数据。当您调用 MIGRATE_ENTERPRISE_TO_EON 以恢复迁移时，该函数会先检查公共存储上的数据，然后仅从源数据库复制未处理的数据。
重要
迁移到具有 HDFS 公共存储的 Eon 数据库时，迁移中断可能会使文件处于对用户可见的未完成状态。当您调用 MIGRATE_ENTERPRISE_TO_EON 以恢复迁移时，该函数会先比较源文件和目标文件的大小。如果发现给定文件的大小不一致，它会截断目标群集文件并重复传输整个文件。重复迁移
您可以多次重复迁移到同一个公共存储位置。这对于回填上一次迁移期间在源数据库中进行的更改很有用。
以下约束适用：
-
您只能从一个数据库迁移到同一公共存储位置。
-
恢复新迁移的 Eon 数据库后，您无法再次迁移到其公共存储，除非您先删除数据库，然后再清理存储。
监控迁移
DATABASE_MIGRATION_STATUS 系统表会实时显示迁移进度，还会存储以前迁移的数据。以下示例显示正在进行迁移的数据：
=> SELECT node_name, phase, status, bytes_to_transfer, bytes_transferred, communal_storage_location FROM database_migration_status ORDER BY node_name, start_time;
node_name | phase | status | bytes_to_transfer | bytes_transferred | communal_storage_location
------------------+--------------------+-----------+-------------------+------------------+---------------------------
v_vmart_node0001 | Catalog Conversion | COMPLETED | 0 | 0 | s3://verticadbbucket/
v_vmart_node0001 | Data Transfer | COMPLETED | 1134 | 1134 | s3://verticadbbucket/
v_vmart_node0001 | Catalog Transfer | COMPLETED | 3765 | 3765 | s3://verticadbbucket/
v_vmart_node0002 | Catalog Conversion | COMPLETED | 0 | 0 | s3://verticadbbucket/
v_vmart_node0002 | Data Transfer | COMPLETED | 1140 | 1140 | s3://verticadbbucket/
v_vmart_node0002 | Catalog Transfer | COMPLETED | 3766 | 3766 | s3://verticadbbucket/
v_vmart_node0003 | Catalog Conversion | COMPLETED | 0 | 0 | s3://verticadbbucket/
v_vmart_node0003 | Data Transfer | RUNNING | 5272616 | 183955 | s3://verticadbbucket/
错误日志记录
MIGRATE_ENTERPRISE_TO_EON 会在数据库目录的 migrate_enterprise_to_eon_error.log 中记录与迁移相关的警告、错误和提示。在执行期间，该函数还会将消息以及错误日志的路径名一起打印到标准输出中。
转换结果
请按如下方式处理源数据库中的可见对象：
-
全局编录对象：已同步到公共存储。
-
同一伙伴实例投影组中的多个分段投影：将迁移组中的一个投影。
-
仅在一个节点上复制的未分段投影：分布在所有节点上。
-
节点数：相同数量的节点，以及相等数量的分段分片。您可能希望更改分片数量，以提高与子群集中节点数量的一致性。有关详细信息，请参阅RESHARD_DATABASE。
-
USER 和 TEMP 存储位置：已迁移。请考虑评估所有已迁移的存储位置与 Eon 模式数据库的相关性。有关详细信息，请参阅临时数据的 S3 存储。
-
DATA 和 TEMP,DATA 存储位置：未迁移。新的默认 DATA 和 TEMP,DATA 位置与存储库位于同一路径上。
-
故障组和存储策略：未迁移。
-
外部过程：未迁移。
-
与网络设置（负载均衡组、网络地址、路由规则、子网等）相关的编录对象：未迁移。
存储库位置是在 MIGRATE_ENTERPRISE_TO_EON 中指定的。恢复后，将默认存储库大小设置为本地文件系统的 80%。
Eon 数据库激活
HDFS 先决条件
如果迁移到具有 HDFS 公共存储的 Eon 数据库，请创建在恢复新的 Eon 数据库时要使用的引导文件。引导文件必须位于要启动恢复操作的同一节点上，并且可以由启动恢复操作的用户读取。
仅当新的 Eon 数据库使用以下一项或两项时，才需要引导文件：
-
高可用性 (HA) 名称节点：将
HadoopConfDir设为hdfs-site.xml配置文件的位置 — 通常为/etc/hadoop/conf。此文件定义了hdfs.nameservices参数和各个名称节点，并且必须分布在所有群集节点上。有关详细信息，请参阅配置 HDFS 访问。 -
Kerberos 身份验证：设置以下 Kerberos 配置参数：
-
KerberosServiceName
-
KerberosRealm
-
KerberosKeytabFile
-
例如，采用 HA 和 Kerberos 身份验证的 Eon 数据库的引导文件必须具有以下设置：
HadoopConfDir = config-path
KerberosServiceName = principal-name
KerberosRealm = realm-name
KerberosKeytabFile = keytab-path
所有迁移
迁移完成且 Eon 数据库已做好使用准备后，请执行以下步骤：
-
请使用以下方法之一恢复数据库：
在以下示例中，管理工具
revive_db命令会恢复使用 S3 公共存储的三节点数据库：admintools -t revive_db -x auth_params.conf \ --communal-storage-location=s3://verticadbbucket \ -d VMart \ -s 172.16.116.27,172.16.116.28,172.16.116.29 \ --force在下一个示例中，
revive_db会恢复使用 HDFS 公共存储的三节点数据库：admintools -t revive_db -x bootstrap_params.conf \ --communal-storage-location=webhdfs://mycluster/verticadb \ -d verticadb \ -s vnode01,vnode02,vnode03 -
检查
/opt/vertica/config/admintools.conf中的controlmode设置。此设置必须与实施 Eon 需满足的网络消息传递要求兼容。例如，S3/AWS (Amazon Cloud) 依赖于单播消息传递，这与point-to-point(pt2pt) 的controlmode设置兼容。如果源数据库controlmode设置为broacast且迁移到 S3/AWS 公共存储，则必须使用管理工具来更改controlmode：$ admintools -t re_ip -d dbname -T重要
如果未正确设置controlmode，则尝试启动迁移的 Eon 数据库将失败。 -
启动 Eon 模式数据库。
-
调用 CLEAN_COMMUNAL_STORAGE 以移除迁移过程中可能留下的不需要的数据文件。
-
如果迁移到 S3 本地公共存储（Pure Storage 或 MinIO），则使用 ALTER DATABASE...SET PARAMETER 将 AWSStreamingConnectionPercentage 配置参数设为 0。
-
查看存储库存储位置大小并根据需要进行调整。
-
如果分片数量不是最佳，请考虑重新切分 Eon 模式数据库。有关详细信息，请参阅选择分片数和初始节点计数。如果需要，请使用 RESHARD_DATABASE 来更改分片数量。
4.1 - 创建子群集
默认情况下，新的 Eon 模式数据库包含一个名为 default_subcluster 的主子群集。此子群集包含创建数据库时属于数据库的所有节点。您经常需要创建子群集来分离和管理工作负载。在数据库中创建新的子群集有三种方法：
使用 admintools 创建子群集
要创建新的子群集，请使用 admintools db_add_subcluster 工具：
$ admintools -t db_add_subcluster --help
Usage: db_add_subcluster [options]
Options:
-h, --help show this help message and exit
-d DB, --database=DB Name of database to be modified
-s HOSTS, --hosts=HOSTS
Comma separated list of hosts to add to the subcluster
-p DBPASSWORD, --password=DBPASSWORD
Database password in single quotes
-c SCNAME, --subcluster=SCNAME
Name of the new subcluster for the new node
--is-primary Create primary subcluster
--is-secondary Create secondary subcluster
--control-set-size=CONTROLSETSIZE
Set the number of nodes that will run spread within
the subcluster
--like=CLONESUBCLUSTER
Name of an existing subcluster from which to clone
properties for the new subcluster
--timeout=NONINTERACTIVE_TIMEOUT
set a timeout (in seconds) to wait for actions to
complete ('never') will wait forever (implicitly sets
-i)
-i, --noprompts do not stop and wait for user input(default false).
Setting this implies a timeout of 20 min.
这个最简单的命令会添加一个空子群集。它需要数据库名称、密码和新子群集的名称。此示例会将名为 analytics_cluster 的子群集添加到名为 verticadb 的数据库中：
$ adminTools -t db_add_subcluster -d verticadb -p 'password' -c analytics_cluster
Creating new subcluster 'analytics_cluster'
Subcluster added to verticadb successfully.
默认情况下，admintools 会将新子群集创建为
辅助子群集。您可以通过提供 --is-primary 实参让该工具创建一个
主子群集。
在创建子群集时添加节点
您还可以为 admintools 指定一个或多个主机以作为新节点添加到子群集中。这些主机必须是群集的一部分，但还不是数据库的一部分。例如，您可以使用通过 MC 或 admintools 添加到群集的主机，或者在您从数据库中删除节点后仍保留在群集中的主机。此示例会创建一个名为 analytics_cluster 的子群集，并使用 -s 选项指定群集中的可用主机：
$ adminTools -t db_add_subcluster -c analytics_cluster -d verticadb -p 'password' -s 10.0.33.77,10.0.33.181,10.0.33.85
使用加入 V_CATALOG.NODES 和 V_CATALOG.NODE_SUBSCRIPTIONS 系统表的以下查询查看数据库中所有节点的订阅状态：
=> SELECT subcluster_name, n.node_name, shard_name, subscription_state FROM
v_catalog.nodes n LEFT JOIN v_catalog.node_subscriptions ns ON (n.node_name
= ns.node_name) ORDER BY 1,2,3;
subcluster_name | node_name | shard_name | subscription_state
-------------------+----------------------+-------------+--------------------
analytics_cluster | v_verticadb_node0004 | replica | ACTIVE
analytics_cluster | v_verticadb_node0004 | segment0001 | ACTIVE
analytics_cluster | v_verticadb_node0004 | segment0003 | ACTIVE
analytics_cluster | v_verticadb_node0005 | replica | ACTIVE
analytics_cluster | v_verticadb_node0005 | segment0001 | ACTIVE
analytics_cluster | v_verticadb_node0005 | segment0002 | ACTIVE
analytics_cluster | v_verticadb_node0006 | replica | ACTIVE
analytics_cluster | v_verticadb_node0006 | segment0002 | ACTIVE
analytics_cluster | v_verticadb_node0006 | segment0003 | ACTIVE
default_subcluster | v_verticadb_node0001 | replica | ACTIVE
default_subcluster | v_verticadb_node0001 | segment0001 | ACTIVE
default_subcluster | v_verticadb_node0001 | segment0003 | ACTIVE
default_subcluster | v_verticadb_node0002 | replica | ACTIVE
default_subcluster | v_verticadb_node0002 | segment0001 | ACTIVE
default_subcluster | v_verticadb_node0002 | segment0002 | ACTIVE
default_subcluster | v_verticadb_node0003 | replica | ACTIVE
default_subcluster | v_verticadb_node0003 | segment0002 | ACTIVE
default_subcluster | v_verticadb_node0003 | segment0003 | ACTIVE
(18 rows)
如果您在创建子群集时不包括主机，则必须在以后添加节点时手动重新平衡子群集中的分片。有关详细信息，请参阅添加节点后更新分片订阅。
子群集和大型群集
Vertica 具有一项名为大型群集的功能，可帮助在数据库群集增长时管理广播消息。它对添加新子群集会产生多种影响：
-
如果创建具有 16 个或更多节点的新子群集，Vertica 会自动启用大型群集功能。它会将 控制节点的数量设置为子群集中节点数量的平方根。请参阅计划大型群集。
-
您可以使用 admintools 命令行中的
--control-set-size选项来设置子群集中控制节点的数量。 -
如果数据库群集有 120 个控制节点，则在您尝试添加新子群集时 Vertica 会返回错误。每个子群集必须至少有一个控制节点。数据库包含的控制节点不能超过 120 个。当数据库达到此限值时，必须减少其他子群集中的控制节点数，然后才能添加新的子群集。有关详细信息，请参阅更改控制节点的数量并重新对齐。
-
如果您尝试创建控制节点数超过 120 个控制节点限值的子群集，Vertica 会向您发出警告并创建具有更少控制节点的子群集。它会向子群集添加尽可能多的控制节点，即 120 减去群集中的当前控制节点数。例如，假设您在已经有 118 个控制节点的数据库群集中创建了一个 16 节点的子群集。在这种情况下，Vertica 会向您发出警告，并仅使用 2 个控制节点而非默认的 4 个控制节点来创建子群集。
有关大型群集功能的详细信息，请参阅大型群集。
4.2 - 复制子群集
子群集包含许多设置，您可以对其进行优化，以使它们按照您想要的方式工作。优化子群集后，您可能需要使用以相同方式配置的其他子群集。例如，假设您有一个已优化为执行分析工作负载的子群集。为了提高查询吞吐量，您可以再创建多个配置与其完全相同的子群集。您可以将现有子群集（称为源子群集）复制到新子群集（目标子群集），而不是创建新的子群集后再从头开始手动配置它们。
当您基于另一个子群集创建新子群集时，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 选项与要复制的源子群集名称一起传递。
重要
使用--like 选项时，无法使用 --is-secondary 或 --control-set-size 选项。Vertica 会根据源子群集来确定新的子群集是否为辅助子群集以及它包含的控制节点数量。如果您将这些选项与 --like 选项一起提供，则 admintools 会返回错误。
以下示例演示了如何复制名为 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 无法将客户端连接重定向到这些节点。
4.3 - 在子群集中添加和移除节点
您通常会希望在子群集中添加新节点和移除现有节点。此功能使您可以扩展数据库以响应不断变化的分析需求。有关将节点添加到子群集如何影响数据库性能的详细信息，请参阅扩展 Eon 模式数据库。
将新节点添加到子群集
您可以将节点添加到子群集以满足额外的工作负载。添加到子群集的节点必须已经是群集的一部分。它们可以是：
-
从其他子群集中移除的节点。
-
按照将节点添加到云上正在运行的群集中的步骤添加的节点。
-
使用云提供商的界面创建的节点，例如 AWS EC2“以类似方式启动”功能。
要将新节点添加到子群集，请使用 admintools 的 db_add_node 命令：
$ adminTools -t db_add_node -h
Usage: db_add_node [options]
Options:
-h, --help show this help message and exit
-d DB, --database=DB Name of the database
-s HOSTS, --hosts=HOSTS
Comma separated list of hosts to add to database
-p DBPASSWORD, --password=DBPASSWORD
Database password in single quotes
-a AHOSTS, --add=AHOSTS
Comma separated list of hosts to add to database
-c SCNAME, --subcluster=SCNAME
Name of subcluster for the new node
--timeout=NONINTERACTIVE_TIMEOUT
set a timeout (in seconds) to wait for actions to
complete ('never') will wait forever (implicitly sets
-i)
-i, --noprompts do not stop and wait for user input(default false).
Setting this implies a timeout of 20 min.
--compat21 (deprecated) Use Vertica 2.1 method using node names
instead of hostnames
如果您不使用 -c 选项，Vertica 会将新节点添加到
默认子群集（在新数据库中设置为 default_subcluster）。此示例添加一个新节点而不指定子群集：
$ adminTools -t db_add_node -p 'password' -d verticadb -s 10.11.12.117
Subcluster not specified, validating default subcluster
Nodes will be added to subcluster 'default_subcluster'
Verifying database connectivity...10.11.12.10
Eon database detected, creating new depot locations for newly added nodes
Creating depots for each node
Generating new configuration information and reloading spread
Replicating configuration to all nodes
Starting nodes
Starting nodes:
v_verticadb_node0004 (10.11.12.117)
Starting Vertica on all nodes. Please wait, databases with a
large catalog may take a while to initialize.
Checking database state
Node Status: v_verticadb_node0004: (DOWN)
Node Status: v_verticadb_node0004: (DOWN)
Node Status: v_verticadb_node0004: (DOWN)
Node Status: v_verticadb_node0004: (DOWN)
Node Status: v_verticadb_node0004: (UP)
Communal storage detected: syncing catalog
Multi-node DB add completed
Nodes added to verticadb successfully.
You will need to redesign your schema to take advantage of the new nodes.
要将节点添加到特定的现有子群集，请使用 db_add_node 工具的 -c 选项：
$ adminTools -t db_add_node -s 10.11.12.178 -d verticadb -p 'password' \
-c analytics_subcluster
Subcluster 'analytics_subcluster' specified, validating
Nodes will be added to subcluster 'analytics_subcluster'
Verifying database connectivity...10.11.12.10
Eon database detected, creating new depot locations for newly added nodes
Creating depots for each node
Generating new configuration information and reloading spread
Replicating configuration to all nodes
Starting nodes
Starting nodes:
v_verticadb_node0007 (10.11.12.178)
Starting Vertica on all nodes. Please wait, databases with a
large catalog may take a while to initialize.
Checking database state
Node Status: v_verticadb_node0007: (DOWN)
Node Status: v_verticadb_node0007: (DOWN)
Node Status: v_verticadb_node0007: (DOWN)
Node Status: v_verticadb_node0007: (DOWN)
Node Status: v_verticadb_node0007: (UP)
Communal storage detected: syncing catalog
Multi-node DB add completed
Nodes added to verticadb successfully.
You will need to redesign your schema to take advantage of the new nodes.
添加节点后更新分片订阅
将节点添加到子群集后，它们尚未订阅分片。您可以使用以下联接 V_CATALOG.NODES 和 V_CATALOG.NODE_SUBSCRIPTIONS 系统表的查询来查看数据库中所有节点的订阅状态：
=> SELECT subcluster_name, n.node_name, shard_name, subscription_state FROM
v_catalog.nodes n LEFT JOIN v_catalog.node_subscriptions ns ON (n.node_name
= ns.node_name) ORDER BY 1,2,3;
subcluster_name | node_name | shard_name | subscription_state
----------------------+----------------------+-------------+--------------------
analytics_subcluster | v_verticadb_node0004 | |
analytics_subcluster | v_verticadb_node0005 | |
analytics_subcluster | v_verticadb_node0006 | |
default_subcluster | v_verticadb_node0001 | replica | ACTIVE
default_subcluster | v_verticadb_node0001 | segment0001 | ACTIVE
default_subcluster | v_verticadb_node0001 | segment0003 | ACTIVE
default_subcluster | v_verticadb_node0002 | replica | ACTIVE
default_subcluster | v_verticadb_node0002 | segment0001 | ACTIVE
default_subcluster | v_verticadb_node0002 | segment0002 | ACTIVE
default_subcluster | v_verticadb_node0003 | replica | ACTIVE
default_subcluster | v_verticadb_node0003 | segment0002 | ACTIVE
default_subcluster | v_verticadb_node0003 | segment0003 | ACTIVE
(12 rows)
可以看到新增的 analytics_subcluster 中没有一个节点有订阅。
要更新新节点的订阅，请调用 REBALANCE_SHARDS 函数。您可以通过将其名称传递给 REBALANCE_SHARDS 函数调用，将重新平衡限制为包含新节点的子群集。以下示例运行重新平衡分片以更新 analytics_subcluster 的订阅：
=> SELECT REBALANCE_SHARDS('analytics_subcluster');
REBALANCE_SHARDS
-------------------
REBALANCED SHARDS
(1 row)
=> SELECT subcluster_name, n.node_name, shard_name, subscription_state FROM
v_catalog.nodes n LEFT JOIN v_catalog.node_subscriptions ns ON (n.node_name
= ns.node_name) ORDER BY 1,2,3;
subcluster_name | node_name | shard_name | subscription_state
----------------------+----------------------+-------------+--------------------
analytics_subcluster | v_verticadb_node0004 | replica | ACTIVE
analytics_subcluster | v_verticadb_node0004 | segment0001 | ACTIVE
analytics_subcluster | v_verticadb_node0004 | segment0003 | ACTIVE
analytics_subcluster | v_verticadb_node0005 | replica | ACTIVE
analytics_subcluster | v_verticadb_node0005 | segment0001 | ACTIVE
analytics_subcluster | v_verticadb_node0005 | segment0002 | ACTIVE
analytics_subcluster | v_verticadb_node0006 | replica | ACTIVE
analytics_subcluster | v_verticadb_node0006 | segment0002 | ACTIVE
analytics_subcluster | v_verticadb_node0006 | segment0003 | ACTIVE
default_subcluster | v_verticadb_node0001 | replica | ACTIVE
default_subcluster | v_verticadb_node0001 | segment0001 | ACTIVE
default_subcluster | v_verticadb_node0001 | segment0003 | ACTIVE
default_subcluster | v_verticadb_node0002 | replica | ACTIVE
default_subcluster | v_verticadb_node0002 | segment0001 | ACTIVE
default_subcluster | v_verticadb_node0002 | segment0002 | ACTIVE
default_subcluster | v_verticadb_node0003 | replica | ACTIVE
default_subcluster | v_verticadb_node0003 | segment0002 | ACTIVE
default_subcluster | v_verticadb_node0003 | segment0003 | ACTIVE
(18 rows)
移除节点
您的数据库必须满足以下要求，然后才能从子群集中移除节点：
-
要从 主子群集中移除节点，子群集中的所有 主节点必须运行，并且在移除主节点后数据库必须能够保持仲裁（请参阅Eon 模式数据库中的数据完整性和高可用性）。这些要求是必要的，因为 Vertica 调用 REBALANCE_SHARDS 在子群集中的剩余节点之间重新分配分片订阅。如果您在数据库不满足要求时尝试移除主节点，则重新平衡分片过程将等待，直到关闭的节点恢复或超时。在等待期间，您会定期看到一条消息“重新平衡分片轮询迭代次数 (Rebalance shards polling iteration number [nn])”，表明重新平衡过程正在等待完成。
即使子群集中的节点已关闭，您也可以从 辅助子群集中移除节点。
-
当您的数据库启用了大型群集功能时，如果节点是子群集的最后一个 控制节点并且有依赖于它的节点，则无法移除该节点。有关详细信息，请参阅大型群集。
如果子群集中还有其他控制节点，您可以删除一个控制节点。Vertica 将依赖于被删除节点的节点重新分配给其他控制节点。
要移除一个或多个节点，请使用 admintools 的 db_remove_node 工具：
$ adminTools -t db_remove_node -p 'password' -d verticadb -s 10.11.12.117
connecting to 10.11.12.10
Waiting for rebalance shards. We will wait for at most 36000 seconds.
Rebalance shards polling iteration number [0], started at [14:56:41], time out at [00:56:41]
Attempting to drop node v_verticadb_node0004 ( 10.11.12.117 )
Shutting down node v_verticadb_node0004
Sending node shutdown command to '['v_verticadb_node0004', '10.11.12.117', '/vertica/data', '/vertica/data']'
Deleting catalog and data directories
Update admintools metadata for v_verticadb_node0004
Eon mode detected. The node v_verticadb_node0004 has been removed from host 10.11.12.117. To remove the
node metadata completely, please clean up the files corresponding to this node, at the communal
location: s3://eonbucket/metadata/verticadb/nodes/v_verticadb_node0004
Reload spread configuration
Replicating configuration to all nodes
Checking database state
Node Status: v_verticadb_node0001: (UP) v_verticadb_node0002: (UP) v_verticadb_node0003: (UP)
Communal storage detected: syncing catalog
当您从子群集中移除一个或多个节点时，Vertica 会自动重新平衡子群集中的分片。移除节点后，您无需手动重新平衡分片。
在子群集之间移动节点
要将节点从一个子群集移动到另一个子群集：
-
从当前所属的子群集中移除一个或多个节点。
-
将节点添加到要将其移动到的子群集中。
4.4 - 使用子群集管理工作负载
默认情况下，查询仅限于在包含启动程序节点（客户端连接到的节点）的子群集中的节点上执行。此示例演示了如何在连接到群集的节点 4 时执行查询的解释计划。节点 4 是包含节点 4 到 6 的子群集的一部分。您可以看到只有子群集中的节点才会参与查询：
=> EXPLAIN SELECT customer_name, customer_state FROM customer_dimension LIMIT 10;
QUERY PLAN
--------------------------------------------------------------------------------
QUERY PLAN DESCRIPTION:
------------------------------
EXPLAIN SELECT customer_name, customer_state FROM customer_dimension LIMIT 10;
Access Path:
+-SELECT LIMIT 10 [Cost: 442, Rows: 10 (NO STATISTICS)] (PATH ID: 0)
| Output Only: 10 tuples
| Execute on: Query Initiator
| +---> STORAGE ACCESS for customer_dimension [Cost: 442, Rows: 10K (NO
STATISTICS)] (PATH ID: 1)
| | Projection: public.customer_dimension_b0
| | Materialize: customer_dimension.customer_name,
customer_dimension.customer_state
| | Output Only: 10 tuples
| | Execute on: v_verticadb_node0004, v_verticadb_node0005,
v_verticadb_node0006
. . .
在 Eon 模式下，您可以覆盖内置全局资源池的 MEMORYSIZE、 MAXMEMORYSIZE 和 MAXQUERYMEMORYSIZE 设置以微调子群集中的工作负载。有关详细信息，请参阅管理 Eon 模式数据库中的工作负载资源。
子群集无法运行查询时发生的情况
为了处理查询，每个子群集的节点必须完全覆盖数据库中的所有分片。如果节点没有完全覆盖（在节点出现故障时可能会发生这种情况），子群集将无法再处理查询。此状态不会导致子群集关闭。不过，如果您尝试在此状态下对子群集运行某个查询，则会收到错误消息，告知您没有足够的节点可用于完成该查询。
=> SELECT node_name, node_state FROM nodes
WHERE subcluster_name = 'analytics_cluster';
node_name | node_state
----------------------+------------
v_verticadb_node0004 | DOWN
v_verticadb_node0005 | UP
v_verticadb_node0006 | DOWN
(3 rows)
=> SELECT * FROM online_sales.online_sales_fact;
ERROR 9099: Cannot find participating nodes to run the query
发生故障的节点已恢复且子群集具有百分之百的分片覆盖率后，它将能够处理查询。
控制查询的运行位置
您可以通过控制客户端将连接到的子群集来控制特定类型的查询的运行位置。强制执行限制的最佳方式是创建一组连接负载均衡策略，将客户端从特定 IP 地址范围引导至正确子群集中的客户端。
例如，假设您有以下数据库，其中包含两个子群集：一个用于执行数据加载，一个用于执行分析。
数据加载任务来自 IP 10.20.0.0/16 地址范围内的一组 ETL 系统。分析任务可能来自任何其他 IP 地址。在这种情况下，您可以创建一组连接负载均衡策略，以确保 ETL 系统连接到数据加载子群集，而所有其他连接都进入分析子群集。
=> SELECT node_name,node_address,node_address_family,subcluster_name
FROM v_catalog.nodes;
node_name | node_address | node_address_family | subcluster_name
----------------------+--------------+---------------------+--------------------
v_verticadb_node0001 | 10.11.12.10 | ipv4 | load_subcluster
v_verticadb_node0002 | 10.11.12.20 | ipv4 | load_subcluster
v_verticadb_node0003 | 10.11.12.30 | ipv4 | load_subcluster
v_verticadb_node0004 | 10.11.12.40 | ipv4 | analytics_subcluster
v_verticadb_node0005 | 10.11.12.50 | ipv4 | analytics_subcluster
v_verticadb_node0006 | 10.11.12.60 | ipv4 | analytics_subcluster
(6 rows)
=> CREATE NETWORK ADDRESS node01 ON v_verticadb_node0001 WITH '10.11.12.10';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node02 ON v_verticadb_node0002 WITH '10.11.12.20';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node03 ON v_verticadb_node0003 WITH '10.11.12.30';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node04 ON v_verticadb_node0004 WITH '10.11.12.40';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node05 ON v_verticadb_node0005 WITH '10.11.12.50';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node06 ON v_verticadb_node0006 WITH '10.11.12.60';
CREATE NETWORK ADDRESS
=> CREATE LOAD BALANCE GROUP load_subcluster WITH SUBCLUSTER load_subcluster
FILTER '0.0.0.0/0';
CREATE LOAD BALANCE GROUP
=> CREATE LOAD BALANCE GROUP analytics_subcluster WITH SUBCLUSTER
analytics_subcluster FILTER '0.0.0.0/0';
CREATE LOAD BALANCE GROUP
=> CREATE ROUTING RULE etl_systems ROUTE '10.20.0.0/16' TO load_subcluster;
CREATE ROUTING RULE
=> CREATE ROUTING RULE analytic_clients ROUTE '0.0.0.0/0' TO analytics_subcluster;
CREATE ROUTING RULE
创建负载均衡策略后，您可以使用 DESCRIBE_LOAD_BALANCE_DECISION 函数对其进行测试。
=> SELECT describe_load_balance_decision('192.168.1.1');
describe_load_balance_decision
--------------------------------
Describing load balance decision for address [192.168.1.1]
Load balance cache internal version id (node-local): [1]
Considered rule [etl_systems] source ip filter [10.20.0.0/16]...
input address does not match source ip filter for this rule.
Considered rule [analytic_clients] source ip filter [0.0.0.0/0]...
input address matches this rule
Matched to load balance group [analytics_cluster] the group has
policy [ROUNDROBIN] number of addresses [3]
(0) LB Address: [10.11.12.181]:5433
(1) LB Address: [10.11.12.205]:5433
(2) LB Address: [10.11.12.192]:5433
Chose address at position [1]
Routing table decision: Success. Load balance redirect to: [10.11.12.205]
port [5433]
(1 row)
=> SELECT describe_load_balance_decision('10.20.1.1');
describe_load_balance_decision
--------------------------------
Describing load balance decision for address [10.20.1.1]
Load balance cache internal version id (node-local): [1]
Considered rule [etl_systems] source ip filter [10.20.0.0/16]...
input address matches this rule
Matched to load balance group [default_cluster] the group has policy
[ROUNDROBIN] number of addresses [3]
(0) LB Address: [10.11.12.10]:5433
(1) LB Address: [10.11.12.20]:5433
(2) LB Address: [10.11.12.30]:5433
Chose address at position [1]
Routing table decision: Success. Load balance redirect to: [10.11.12.20]
port [5433]
(1 row)
通常，使用这些策略时，ETL 系统运行的所有查询都将在加载子群集上运行。所有其他查询将在分析子群集上运行。在某些情况下（尤其是在子群集发生故障或排空的情况下），客户端可能会连接到另一个子群集中的节点。为此，客户端应始终验证它们是否已连接到正确的子群集。有关负载均衡策略的详细信息，请参阅连接负载均衡策略。
4.5 - 启动和停止子群集
借助子群集，可以根据需要方便地启动和停止一组节点。您可以使用 admintools 命令行或 Vertica 元函数启动和停止它们。
启动子群集
要启动子群集，请使用 restart_subcluster 工具：
$ adminTools -t restart_subcluster -h
Usage: restart_subcluster [options]
Options:
-h, --help show this help message and exit
-d DB, --database=DB Name of database whose subcluster is to be restarted
-c SCNAME, --subcluster=SCNAME
Name of subcluster to be restarted
-p DBPASSWORD, --password=DBPASSWORD
Database password in single quotes
--timeout=NONINTERACTIVE_TIMEOUT
set a timeout (in seconds) to wait for actions to
complete ('never') will wait forever (implicitly sets
-i)
-i, --noprompts do not stop and wait for user input(default false).
Setting this implies a timeout of 20 min.
-F, --force Force the nodes in the subcluster to start and auto
recover if necessary
此示例启动名为 analytics_cluster 的子群集：
$ adminTools -t restart_subcluster -c analytics_cluster \
-d verticadb -p password
*** Restarting subcluster for database verticadb ***
Restarting host [10.11.12.192] with catalog [v_verticadb_node0006_catalog]
Restarting host [10.11.12.181] with catalog [v_verticadb_node0004_catalog]
Restarting host [10.11.12.205] with catalog [v_verticadb_node0005_catalog]
Issuing multi-node restart
Starting nodes:
v_verticadb_node0004 (10.11.12.181)
v_verticadb_node0005 (10.11.12.205)
v_verticadb_node0006 (10.11.12.192)
Starting Vertica on all nodes. Please wait, databases with a large
catalog may take a while to initialize.
Node Status: v_verticadb_node0002: (UP) v_verticadb_node0004: (DOWN)
v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
Node Status: v_verticadb_node0002: (UP) v_verticadb_node0004: (DOWN)
v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
Node Status: v_verticadb_node0002: (UP) v_verticadb_node0004: (DOWN)
v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
Node Status: v_verticadb_node0002: (UP) v_verticadb_node0004: (DOWN)
v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
Node Status: v_verticadb_node0002: (UP) v_verticadb_node0004: (UP)
v_verticadb_node0005: (UP) v_verticadb_node0006: (UP)
Communal storage detected: syncing catalog
Restart Subcluster result: 1
停止子群集
您可以使用 stop_subcluster admintools 命令或 SHUTDOWN_WITH_DRAIN 和 SHUTDOWN_SUBCLUSTER 函数停止子群集。
admintools
重要
stop_subcluster 如果存在连接到子群集的活动用户会话，则不会发出警告。此行为与停止单个节点相同。在停止子群集之前，确认没有用户连接到它。
要停止子群集，请使用 stop_subcluster 工具：
$ adminTools -t stop_subcluster -h
Usage: stop_subcluster [options]
Options:
-h, --help show this help message and exit
-d DB, --database=DB Name of database whose subcluster is to be stopped
-c SCNAME, --subcluster=SCNAME
Name of subcluster to be stopped
-p DBPASSWORD, --password=DBPASSWORD
Database password in single quotes
--timeout=NONINTERACTIVE_TIMEOUT
set a timeout (in seconds) to wait for actions to
complete ('never') will wait forever (implicitly sets
-i)
-i, --noprompts do not stop and wait for user input(default false).
Setting this implies a timeout of 20 min.
此示例停止名为 analytics_cluster 的子群集：
$ adminTools -t stop_subcluster -c analytics_cluster -d verticadb -p password
*** Forcing subcluster shutdown ***
Verifying subcluster 'analytics_cluster'
Node 'v_verticadb_node0004' will shutdown
Node 'v_verticadb_node0005' will shutdown
Node 'v_verticadb_node0006' will shutdown
Shutdown subcluster command sent to the database
正常关闭
如果您希望在关闭子群集之前清空子群集的客户端连接，则可以使用 SHUTDOWN_WITH_DRAIN 函数正常关闭子群集。该函数首先将指定子群集中的所有节点标记为正在清空。现有用户会话中的工作继续在正在清空的节点上进行，但节点拒绝新的客户端连接，并被排除在负载均衡操作之外。dbadmin 仍然可以连接到正在清空的节点。有关客户端连接清空的详细信息，请参阅排空客户端连接。
要运行 SHUTDOWN_WITH_DRAIN 函数，您必须指定超时值。该函数的行为取决于超时值的正负：
- 正值：节点清空，直到所有现有连接关闭或该函数达到超时值设置的运行时限制为止。一旦满足这些条件之一，该函数就会向子群集发送一条关闭消息并返回。
- 零：该函数立即关闭子群集中所有活动用户会话，然后关闭子群集并返回。
- 负值：该函数将子群集节点标记为正在清空，等待关闭子群集，直到所有活动用户会话断开连接为止。
正在清空的子群集中所有节点关闭之后，其节点自动重置为非清空状态。
以下示例演示如何使用正超时值给予活动用户会话时间，以在关闭子群集之前完成其工作：
=> SELECT node_name, subcluster_name, is_draining, count_client_user_sessions, oldest_session_user FROM draining_status ORDER BY 1;
node_name | subcluster_name | is_draining | count_client_user_sessions | oldest_session_user
----------------------+--------------------+-------------+----------------------------+---------------------
v_verticadb_node0001 | default_subcluster | f | 0 |
v_verticadb_node0002 | default_subcluster | f | 0 |
v_verticadb_node0003 | default_subcluster | f | 0 |
v_verticadb_node0004 | analytics | f | 1 | analyst
v_verticadb_node0005 | analytics | f | 0 |
v_verticadb_node0006 | analytics | f | 0 |
(6 rows)
=> SELECT SHUTDOWN_WITH_DRAIN('analytics', 300);
NOTICE 0: Draining has started on subcluster (analytics)
NOTICE 0: Begin shutdown of subcluster (analytics)
SHUTDOWN_WITH_DRAIN
--------------------------------------------------------------------------------------------------------------------
Set subcluster (analytics) to draining state
Waited for 3 nodes to drain
Shutdown message sent to subcluster (analytics)
(1 row)
您可以查询 NODES 系统表以确认子群集已关闭：
=> SELECT subcluster_name, node_name, node_state FROM nodes;
subcluster_name | node_name | node_state
--------------------+----------------------+------------
default_subcluster | v_verticadb_node0001 | UP
default_subcluster | v_verticadb_node0002 | UP
default_subcluster | v_verticadb_node0003 | UP
analytics | v_verticadb_node0004 | DOWN
analytics | v_verticadb_node0005 | DOWN
analytics | v_verticadb_node0006 | DOWN
(6 rows)
如果要查看有关清空和关闭事件的详细信息（例如所有用户会话是否在超时之前完成工作），可以查询 dc_draining_events 表。在本例中，当函数达到超时的时候，子群集仍有一个活动用户会话：
=> SELECT event_type, event_type_name, event_description, event_result, event_result_name FROM dc_draining_events;
event_type | event_type_name | event_description | event_result | event_result_name
------------+------------------------------+---------------------------------------------------------------------+--------------+-------------------
0 | START_DRAIN_SUBCLUSTER | START_DRAIN for SHUTDOWN of subcluster (analytics) | 0 | SUCCESS
2 | START_WAIT_FOR_NODE_DRAIN | Wait timeout is 300 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 0 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 60 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 120 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 125 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 180 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 240 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 250 seconds | 4 | INFORMATIONAL
4 | INTERVAL_WAIT_FOR_NODE_DRAIN | 1 sessions remain after 300 seconds | 4 | INFORMATIONAL
3 | END_WAIT_FOR_NODE_DRAIN | Wait for drain ended with 1 sessions remaining | 2 | TIMEOUT
5 | BEGIN_SHUTDOWN_AFTER_DRAIN | Staring shutdown of subcluster (analytics) following drain | 4 | INFORMATIONAL
(12 rows)
重新启动子群集后，可以查询 DRAINING_STATUS 系统表以确认节点已将其清空状态重置为非清空：
=> SELECT node_name, subcluster_name, is_draining, count_client_user_sessions, oldest_session_user FROM draining_status ORDER BY 1;
node_name | subcluster_name | is_draining | count_client_user_sessions | oldest_session_user
----------------------+--------------------+-------------+----------------------------+---------------------
v_verticadb_node0001 | default_subcluster | f | 0 |
v_verticadb_node0002 | default_subcluster | f | 0 |
v_verticadb_node0003 | default_subcluster | f | 0 |
v_verticadb_node0004 | analytics | f | 0 |
v_verticadb_node0005 | analytics | f | 0 |
v_verticadb_node0006 | analytics | f | 0 |
(6 rows)
立即关闭
如果想要立即关闭子群集，则可以调用 SHUTDOWN_SUBCLUSTER。以下示例立即关闭名为 analytics 的子群集，而不检查任何活动客户端连接：
=> SELECT SHUTDOWN_SUBCLUSTER('analytics');
SHUTDOWN_SUBCLUSTER
---------------------
Subcluster shutdown
(1 row)
4.6 - 更改子群集设置
您可以使用 ALTER SUBCLUSTER 语句在子群集上更改多个设置。您还可以将子群集从主子群集切换到辅助子群集，或者从辅助子群集切换到主子群集。
重命名子群集
要重命名现有子群集，请使用 ALTER SUBCLUSTER 语句的 RENAME TO 子句：
=> ALTER SUBCLUSTER default_subcluster RENAME TO load_subcluster;
ALTER SUBCLUSTER
=> SELECT DISTINCT subcluster_name FROM subclusters;
subcluster_name
-------------------
load_subcluster
analytics_cluster
(2 rows)
更改默认子群集
如果您在将节点添加到数据库时未明确指定子群集，则默认子群集会指定 Vertica 要将节点添加到的子群集。创建新数据库时（或从 9.3.0 之前的版本升级数据库时），default_subcluster 是默认值。您可以通过查询 SUBCLUSTERS 系统表的 is_default 列找到当前的默认子群集。
以下示例演示如何查找默认子群集，然后将其更改为名为 analytics_cluster 的子群集：
=> SELECT DISTINCT subcluster_name FROM SUBCLUSTERS WHERE is_default = true;
subcluster_name
--------------------
default_subcluster
(1 row)
=> ALTER SUBCLUSTER analytics_cluster SET DEFAULT;
ALTER SUBCLUSTER
=> SELECT DISTINCT subcluster_name FROM SUBCLUSTERS WHERE is_default = true;
subcluster_name
-------------------
analytics_cluster
(1 row)
将子群集从主子群集转换为辅助子群集，或者从辅助子群集转换为主子群集
您通常会在创建子群集时选择子群集是 主子群集还是 辅助子群集（请参阅创建子群集以了解详细信息）。但在创建子群集后，您可以在这两个设置之间切换。您可能希望更改子群集是主子群集还是辅助子群集，来影响数据库的 K-Safety。例如，如果您有一个主子群集，其中包含无法轻松替换的关闭节点，则可以将辅助子群集提升为主子群集，以确保丢失另一个主节点不会导致数据库关闭。另一方面，您可以选择在最终关闭之前将主子群集转换为辅助子群集。如果您要关闭的子群集包含数据库中主节点总数的一半或以上，则此转换可以防止数据库丢失 K-Safety。
要将辅助子群集设为主子群集，请使用 PROMOTE_SUBCLUSTER_TO_PRIMARY 函数：
=> SELECT DISTINCT subcluster_name, is_primary from subclusters;
subcluster_name | is_primary
-------------------+------------
analytics_cluster | f
load_subcluster | t
(2 rows)
=> SELECT PROMOTE_SUBCLUSTER_TO_PRIMARY('analytics_cluster');
PROMOTE_SUBCLUSTER_TO_PRIMARY
-------------------------------
PROMOTE SUBCLUSTER TO PRIMARY
(1 row)
=> SELECT DISTINCT subcluster_name, is_primary from subclusters;
subcluster_name | is_primary
-------------------+------------
analytics_cluster | t
load_subcluster | t
(2 rows)
将主子群集设为辅助子群集的方法与此类似。与将辅助子群集转换为主子群集不同，有几个问题可能会阻止您将主子群集设为辅助子群集。如果以下任一情况属实，Vertica 会阻止您将主子群集设为辅助子群集：
-
子群集包含一个 关键节点。
-
子群集是数据库中唯一的主子群集。您必须至少有一个主子群集。
-
启动程序节点是指您尝试降级的子群集的成员。您必须从另一个子群集调用 DEMOTE_SUBCLUSTER_TO_SECONDARY。
要将主子群集转换为辅助子群集，请使用 DEMOTE_SUBCLUSTER_TO_SECONDARY 函数：
=> SELECT DISTINCT subcluster_name, is_primary from subclusters;
subcluster_name | is_primary
-------------------+------------
analytics_cluster | t
load_subcluster | t
(2 rows)
=> SELECT DEMOTE_SUBCLUSTER_TO_SECONDARY('analytics_cluster');
DEMOTE_SUBCLUSTER_TO_SECONDARY
--------------------------------
DEMOTE SUBCLUSTER TO SECONDARY
(1 row)
=> SELECT DISTINCT subcluster_name, is_primary from subclusters;
subcluster_name | is_primary
-------------------+------------
analytics_cluster | f
load_subcluster | t
(2 rows)
4.7 - 移除子群集
从数据库移除子群集会从 Vertica 编录中删除子群集。在移除期间，Vertica 从数据库移除子群集中的所有节点。这些节点仍是数据库群集的一部分，但不再是数据库的一部分。如果您在 MC 中查看群集，您将看到这些节点的状态为“待机 (STANDBY)”。通过将它们添加到另一个子群集，可以将它们添加回数据库。请参阅创建子群集和将新节点添加到子群集。
Vertica 对移除子群集有一些限制：
注意
如果数据库重新分区，移除子群集可能失败。如果发生失败，您将看到错误消息“事务提交中止，因为会话订阅与编录不匹配 (Transaction commit aborted because session subscriptions do not match catalog)”。等待重新分区完成，然后再移除子群集。要移除子群集，请使用 admintools 命令行 db_remove_subcluster 工具：
$ adminTools -t db_remove_subcluster -h
Usage: db_remove_subcluster [options]
Options:
-h, --help show this help message and exit
-d DB, --database=DB Name of database to be modified
-c SCNAME, --subcluster=SCNAME
Name of subcluster to be removed
-p DBPASSWORD, --password=DBPASSWORD
Database password in single quotes
--timeout=NONINTERACTIVE_TIMEOUT
set a timeout (in seconds) to wait for actions to
complete ('never') will wait forever (implicitly sets
-i)
-i, --noprompts do not stop and wait for user input(default false).
Setting this implies a timeout of 20 min.
--skip-directory-cleanup
Caution: this option will force you to do a manual
cleanup. This option skips directory deletion during
remove subcluster. This is best used in a cloud
environment where the hosts being removed will be
subsequently discarded.
此示例移除名为 analytics_cluster 的子群集：
$ adminTools -t db_remove_subcluster -d verticadb -c analytics_cluster -p 'password'
Found node v_verticadb_node0004 in subcluster analytics_cluster
Found node v_verticadb_node0005 in subcluster analytics_cluster
Found node v_verticadb_node0006 in subcluster analytics_cluster
Found node v_verticadb_node0007 in subcluster analytics_cluster
Waiting for rebalance shards. We will wait for at most 36000 seconds.
Rebalance shards polling iteration number [0], started at [17:09:35], time
out at [03:09:35]
Attempting to drop node v_verticadb_node0004 ( 10.11.12.40 )
Shutting down node v_verticadb_node0004
Sending node shutdown command to '['v_verticadb_node0004', '10.11.12.40',
'/vertica/data', '/vertica/data']'
Deleting catalog and data directories
Update admintools metadata for v_verticadb_node0004
Eon mode detected. The node v_verticadb_node0004 has been removed from
host 10.11.12.40. To remove the node metadata completely, please clean
up the files corresponding to this node, at the communal location:
s3://eonbucket/verticadb/metadata/verticadb/nodes/v_verticadb_node0004
Attempting to drop node v_verticadb_node0005 ( 10.11.12.50 )
Shutting down node v_verticadb_node0005
Sending node shutdown command to '['v_verticadb_node0005', '10.11.12.50',
'/vertica/data', '/vertica/data']'
Deleting catalog and data directories
Update admintools metadata for v_verticadb_node0005
Eon mode detected. The node v_verticadb_node0005 has been removed from
host 10.11.12.50. To remove the node metadata completely, please clean
up the files corresponding to this node, at the communal location:
s3://eonbucket/verticadb/metadata/verticadb/nodes/v_verticadb_node0005
Attempting to drop node v_verticadb_node0006 ( 10.11.12.60 )
Shutting down node v_verticadb_node0006
Sending node shutdown command to '['v_verticadb_node0006', '10.11.12.60',
'/vertica/data', '/vertica/data']'
Deleting catalog and data directories
Update admintools metadata for v_verticadb_node0006
Eon mode detected. The node v_verticadb_node0006 has been removed from
host 10.11.12.60. To remove the node metadata completely, please clean
up the files corresponding to this node, at the communal location:
s3://eonbucket/verticadb/metadata/verticadb/nodes/v_verticadb_node0006
Attempting to drop node v_verticadb_node0007 ( 10.11.12.70 )
Shutting down node v_verticadb_node0007
Sending node shutdown command to '['v_verticadb_node0007', '10.11.12.70',
'/vertica/data', '/vertica/data']'
Deleting catalog and data directories
Update admintools metadata for v_verticadb_node0007
Eon mode detected. The node v_verticadb_node0007 has been removed from
host 10.11.12.70. To remove the node metadata completely, please clean
up the files corresponding to this node, at the communal location:
s3://eonbucket/verticadb/metadata/verticadb/nodes/v_verticadb_node0007
Reload spread configuration
Replicating configuration to all nodes
Checking database state
Node Status: v_verticadb_node0001: (UP) v_verticadb_node0002: (UP)
v_verticadb_node0003: (UP)
Communal storage detected: syncing catalog
5 - 存储库管理
Eon 模式数据库的节点会根据需要从公共存储中提取数据以处理查询，并将该数据缓存在本地磁盘上。子群集内所有节点的缓存数据将构成该群集的存储库。Vertica 使用存储库来加快查询执行：在处理查询时，Vertica 会先检查当前存储库中是否包含所需的数据。如果数据不可用，Vertica 会从公共存储中提取数据并将副本保存在存储库中以加快将来查询的速度。此外，Vertica 还会使用存储库保存加载操作，以便在将新加载的数据上传到公共存储之前将其缓存在存储库中。
5.1 - 管理存储库缓存
您可以通过多种方式控制存储库缓存：
-
配置网关参数，以便存储库仅缓存已查询的数据或已加载的数据。
-
控制从公共存储中提取查询数据。
您可以使用多个 V_MONITOR 系统表或管理控制台来监控存储库活动和设置。
注意
仅在主分片订户节点上支持缓存存储库。存储库网关参数
Vertica 存储库可以缓存两种类型的数据：
-
已查询的数据：存储库可通过从公共存储中提取已查询的数据并将其缓存到存储库中来提高查询执行速度。已缓存的数据将保持可用状态，直到被逐出以便为更新的数据腾出空间，或者为更新的查询提取的数据腾出空间。
-
已加载的数据：存储库可通过临时缓存数据直到将其上传到公共存储，来加快 COPY 等加载操作。
默认情况下，将存储库配置为缓存这两种类型的数据。
以下两个配置参数确定存储库是缓存已查询的数据还是已加载的数据：
这两个参数都可以在会话级别、用户级别和数据库级别进行设置。
如果在会话或用户级别设置，则这些参数可用于隔离不同子群集存储库上的读取和写入活动。例如，可以按如下所示为用户 joe 和 rhonda 设置参数 UseDepotForReads 和 UseDepotForWrites：
=> SHOW USER joe ALL;
name | setting
-------------------------+---------
UseDepotForReads | 1
UseDepotForWrites | 0
(2 rows)
=> SHOW USER rhonda ALL;
name | setting
-------------------------+---------
UseDepotForReads | 0
UseDepotForWrites | 1
(2 rows)
鉴于这些用户设置，当 joe 连接到 Vertica 子群集时，他的会话将仅使用当前存储库来处理查询；所有加载操作都会上传到公共存储。相反，rhonda 的会话将仅使用存储库来处理加载操作；所有查询都必须从公共存储中提取数据。
存储库提取
如果已启用存储库以缓存已查询的数据 (UseDepotForReads = 1)，您可以使用配置参数 DepotOperationsForQuery 配置它从公共存储中提取数据的方式。此参数具有三个设置：
-
ALL（默认值）：从公共存储中提取文件数据，如有必要，通过将现有文件从存储库中逐出来替换它们。 -
FETCHES：仅当空间可用时才从公共存储中提取文件数据；否则，直接从公共存储中读取查询的数据。 -
NONE：请勿将文件数据提取到存储库，而应直接从公共存储中读取查询的数据。
您可以按优先级升序在四个级别设置提取行为：
-
按查询： DEPOT_FETCH 提示
例如，您可以在数据库级别设置 DepotOperationsForQuery，如下所示：
=> ALTER DATABASE default SET PARAMETER DepotOperationsForQuery = FETCHES;
ALTER DATABASE
此设置适用于所有数据库存储库，除非在其他级别被覆盖。例如，以下 ALTER USER 语句指定了在处理来自用户 joe 的查询时存储库的提取行为：
=> ALTER USER joe SET PARAMETER DepotOperationsForQuery = ALL;
ALTER USER
最后，joe 可以通过在各个查询中包含 DEPOT_FETCH 提示来覆盖他自己的 DepotOperationsForQuery 设置：
SELECT /*+DEPOT_FETCH(NONE)*/ count(*) FROM bar;
逐出存储库数据
通常，Vertica 会根据需要从存储库中逐出数据，以便为新数据提供空间和加快请求处理。在将新数据写入存储库之前，Vertica 会按如下方式对其进行评估：
-
从公共存储中提取的数据：Vertica 会调整下载大小并相应地从存储库中逐出数据。
-
从 DML 操作（例如 COPY）上传的数据：Vertica 无法在上传完成之前估计其总大小，因此它会根据需要调整各个缓冲区的大小并从存储库中逐出数据。
在这两种情况下，Vertica 都会评估现有的存储库数据并按优先级降序（最易受到攻击到最不易受到攻击）确定要从如下存储库中逐出的对象：
-
为任何新的固定或未固定对象逐出最近最少使用的未固定对象。
-
为新的固定对象逐出最近最少使用的固定对象。
固定存储库对象
您可以对数据库对象设置存储库固定策略，以减少它们被逐出的风险。可以在各个子群集或整个数据库上以及不同的粒度级别（表、投影和分区）设置固定策略：
默认情况下，系统会根据需要将固定对象排入从公共存储下载的队列，以执行查询或 DML 操作。SET_DEPOT_PIN_POLICY 函数可以指定覆盖此行为并立即将新固定的对象排入下载队列：将该函数的最后一个布尔值实参设置为 true。
在以下示例中，SET_DEPOT_PIN_POLICY_TABLE 会固定表 foo 的数据，并指定立即将数据排入下载队列：
=> SELECT SET_DEPOT_PIN_POLICY_TABLE ('foo', 'default_subluster', true );
提示
Vertica 从公共存储下载固定对象的速度取决于许多因素，包括空间可用性以及排入下载队列的其他固定对象的优先级。您可以通过调用 FINISH_FETCHING_FILES 来强制立即下载已排队的对象。使用准则
将一个或多个对象固定在存储库上会影响其保留已提取（已查询）的数据已上传（新加载）的数据。如果固定对象占用的存储库空间过多，则存储库可能无法处理未固定对象上的加载操作。在这种情况下，请将配置参数 UseDepotForWrites 设置为 0，以便将加载操作直接路由到公共存储进行处理。否则，加载操作很可能会返回错误。
为了尽量减少争用存储库的现象，请考虑以下准则：
-
仅固定 DML 操作和查询中最活跃的对象。
-
通过在最小的有效级别中设置策略（例如，仅限固定表的活动分区的数据），可以最小化固定数据的大小。
存储库预热
启动时，新节点的存储库为空，而重新启动节点的存储库通常包含必须刷新的陈旧数据。启用存储库预热后，正在启动的节点会抢先加载其存储库，其中包含频繁查询和固定的数据。当节点完成启动并开始执行查询时，它的存储库已经包含了处理这些查询所需的大部分数据。这减少了从公共存储中提取数据的需要，并相应地提高了查询性能。
注意
将数据提取到预热存储库时，可能会导致节点延迟启动。默认情况下，存储库预热处于禁用状态 (EnableDepotWarmingFromPeers = 0)。节点将按如下所示执行存储库预热：
-
节点会检查配置参数 PreFetchPinnedObjectsToDepotAtStartup。如果启用（设置为 1），则节点：
-
从数据库编录中获取此节点的子群集上固定的所有对象的列表。
-
将已固定的对象排入队列以进行获取并计算它们的总大小。
-
-
节点会检查配置参数 EnableDepotWarmingFromPeers。如果启用（设置为 1），则节点：
-
标识可以复制其存储库内容的同一子群集中的对等节点。
-
在考虑所有已固定的对象后，计算预热存储库中的剩余可用空间。
-
从对等节点获取最近使用过的对象（可放入存储库）的列表。
-
将对象排入队列以进行提取。
-
-
如果 BackgroundDepotWarming 处于启用状态（默认设置为 1），则节点会在预热时将已排队的对象加载到其存储库中，并在节点变为活动状态并开始执行查询后继续在后台执行此操作。否则 BackgroundDepotWarming = 0，节点激活将被推迟，直到存储库提取并加载所有已排队的对象为止。
监控存储库
您可以使用多个 V_MONITOR 系统表来监控存储库活动和设置。
提示
您还可以使用管理控制台来监控存储库活动。有关详细信息，请参阅 在 MC 中监控存储库活动5.2 - 调整存储库缓存容量
Eon 数据库中的每个节点都将存储库数据缓存在预定义的存储位置。存储位置路径取决于 Vertica 安装的文件系统。默认情况下，群集中的每个节点最多可以使用存储位置文件系统上 60% 的磁盘空间来缓存存储库数据。您可以使用 ALTER_LOCATION_SIZE 通过指定固定大小或总磁盘空间的百分比来更改缓存容量。该函数可以指定单个节点、子群集或数据库群集中的所有节点。您可以将每个节点的存储库缓存容量提高多达 80%。
在以下示例中，ALTER_LOCATION_SIZE 将存储库缓存容量增加到存储位置文件系统上磁盘空间的 80%。该函数提供一个空字符串作为第二个 (node-name) 实参，因此更改应用于所有节点：
重要
默认情况下，存储库缓存容量不能超过存储位置文件系统上磁盘空间的 80%；尝试将其设置为更高的值会返回错误。Vertica 需要至少 20% 的磁盘空间用于编录、数据收集器表和临时文件。=> SELECT node_name, location_label, location_path, max_size, disk_percent FROM storage_locations WHERE location_usage = 'DEPOT' ORDER BY node_name;
node_name | location_label | location_path | max_size | disk_percent
------------------+-----------------+-------------------------+-------------+--------------
v_vmart_node0001 | auto-data-depot | /home/dbadmin/verticadb | 36060108800 | 70%
v_vmart_node0002 | auto-data-depot | /home/dbadmin/verticadb | 36059377664 | 70%
v_vmart_node0003 | auto-data-depot | /home/dbadmin/verticadb | 36060108800 | 70%
(3 rows)
=> SELECT alter_location_size('depot', '','80%');
alter_location_size
---------------------
depotSize changed.
(1 row)
=> SELECT node_name, location_label, location_path, max_size, disk_percent FROM storage_locations WHERE location_usage = 'DEPOT' ORDER BY node_name;
node_name | location_label | location_path | max_size | disk_percent
------------------+-----------------+-------------------------+-------------+--------------
v_vmart_node0001 | auto-data-depot | /home/dbadmin/verticadb | 41211552768 | 80%
v_vmart_node0002 | auto-data-depot | /home/dbadmin/verticadb | 41210717184 | 80%
v_vmart_node0003 | auto-data-depot | /home/dbadmin/verticadb | 41211552768 | 80%
(3 rows)
重新调整存储库容量
当数据库在磁盘空间大于或小于以前空间的实例上恢复时，Vertica 会评估以前有效的存储库大小设置。如果将库大小指定为可用磁盘空间的百分比，Vertica 会按比例重新调整存储库容量。例如，如果给定节点的存储库缓存容量设置为 70%，则恢复的节点会将该设置应用于新磁盘空间，并相应地调整存储库缓存容量。如果存储库容量设置为固定大小，Vertica 会应用该设置，除非这样做会消耗 80% 以上的可用磁盘空间。在这种情况下，Vertica 会根据需要自动调整存储库大小。
6 - 扩展 Eon 模式数据库
Eon 模式数据库的优势之一是它能够增大或缩小以满足您的工作负载需求。您可以在数据库中添加和移除节点以满足不断变化的工作负载需求。有关扩展数据库的原因以及它影响查询的方式的概述，请参阅弹性。
通过启动停止的节点来扩展数据库
扩展数据库的最简单方法是启动任何停止的节点：
-
要启动单个节点，请参阅在 MC 上停止和启动节点。
-
要启动已停止的整个子群集，请参阅启动和停止子群集。
通过添加节点来扩展数据库
如果您的数据库中没有停止的节点，或者停止的节点不在您要添加新节点的子群集中，则可以将新节点添加到数据库中。在受支持的环境中，使用 MC 只需一步便可配置新节点并将其添加到您的数据库中。有关详细信息，请参阅查看和管理您的群集。
您还可以手动添加新节点：
-
对于在 AWS 上运行的数据库，请参阅将节点添加到云上正在运行的群集。
-
对于在本地或其他环境中运行的数据库：
-
为新节点配置硬件。请务必按照在安装 Vertica 之前中的步骤验证您的硬件配置是否正确。
-
按照向群集中添加主机中的步骤将新节点添加到数据库群集。
-
按照将新节点添加到子群集中的步骤将节点添加到数据库。
-
控制 Vertica 使用新节点的方式
新节点可以通过以下两种方式之一提高数据库的性能：
-
增加查询吞吐量（数据库同时处理的查询数量）。
-
提高单个查询性能（每个查询的运行速度）。
有关这些性能改进的详细信息，请参阅弹性。您可以通过选择将新节点添加到哪些子群集来控制新节点提高数据库性能的方式。以下主题说明如何使用扩展来提高吞吐量和查询性能。
6.1 - 更改数据库中的分片数
创建数据库时会设置初始分片数。出于以下原因，您可能会选择更改数据库中的分片数：
-
提高大型子群集的性能。例如，如果您有一个包含 6 个分片的 24 节点子群集，则该子群集使用 Elastic Crunch Scaling (ECS) 将处理每个分片中数据的责任分配给各个节点。将数据库重新分片为 24 个分片消除了 ECS 的必要性并提高了性能，因为 ECS 不如一比一的分片与节点比率那样高效。有关详细信息，请参阅使用 Elastic Crunch Scaling 提高查询性能。
-
减小编录大小。如果您的编录大小由于数据库中的大量分片而增加，您可能选择减少分片的数量。
-
从企业模式迁移到 Eon 模式后提高性能。当您将数据库从企业模式迁移到 Eon 模式时，Eon 数据库中的分片数最初设置为您在企业数据库中拥有的节点数。这个默认的分片数量可能并不理想。有关详细信息，请参阅选择分片数和初始节点数。
-
有效扩展您的数据库。为了在节点之间平均分配工作，数据库中的节点数量应当是分片数量的倍数或除数。如果您打算将子群集扩展到与本指南不兼容的大小，您可能需要将数据库重新分片。例如，对于有七个分片的数据库，其中的子群集包含的节点数必须为七的倍数。选择具有更多除数（例如 8 个）的分片数，可以让您在选择子群集中的节点数时具有更大的灵活性。
每次扩展子群集时，不应当将数据库重新分片。在重新分片过程中，可能会影响数据库的性能。重新分片后，子群集上的存储容器不会立即与新的分片订阅边界对齐。这种错位增加了查询执行的开销。
将 Eon 模式数据库重新分片
要将数据库重新分片，请使用新的分片计数作为实参调用 RESHARD_DATABASE 函数。此函数采用全局编录锁，因此请避免在繁忙时段或执行繁重的 ETL 负载时运行它。运行时取决于编录的大小。
RESHARD_DATABASE 完成后，群集中的节点使用新的编录分片定义。但是，重新分片过程不会立即更改公共存储中的存储容器。分片继续指向现有的存储容器。例如，如果您将数据库中的分片数量加倍，则每个存储容器现在有两个关联的分片。在查询期间，每个节点都会筛选掉存储容器中不适用于其订阅分片的数据。这为查询添加了少许开销。最终，Tuple Mover 的后台反身合并进程会自动更新存储容器，以便它们与新的分片定义保持一致。您可以调用 DO_TM_TASK 来运行让 Tuple Mover 立即重新对齐存储容器的 'RESHARDMERGEOUT' 任务。
以下查询返回 Tuple Mover 尚未重新对齐的任何存储容器的详细信息：
=> SELECT * FROM storage_containers WHERE original_segment_lower_bound IS NULL AND original_segment_upper_bound IS NULL;
示例
此示例演示了重新分片过程以及它如何影响分片分配和存储容器。为了说明重新分片的影响，我们比较了重新分片前后的分片分配和存储容器详细信息。以下三个查询返回有关数据库分片、节点订阅和存储容器编录对象的信息：
=> SELECT shard_name, lower_hash_bound, upper_hash_bound FROM shards ORDER BY shard_name;
shard_name | lower_hash_bound | upper_hash_bound
------------+------------------+------------------
replica | |
segment0001 | 0 | 1073741825
segment0002 | 1073741826 | 2147483649
segment0003 | 2147483650 | 3221225473
segment0004 | 3221225474 | 4294967295
(5 rows)
=> SELECT node_name, shard_name, is_primary, is_resubscribing, is_participating_primary FROM node_subscriptions;
node_name | shard_name | is_primary | is_resubscribing | is_participating_primary
----------+-------------+------------+------------------+--------------------------
initiator | replica | t | f | t
e0 | replica | f | f | t
e1 | replica | f | f | t
e2 | replica | f | f | t
e0 | segment0002 | t | f | t
e1 | segment0003 | t | f | t
e2 | segment0004 | t | f | t
initiator | segment0001 | t | f | t
(8 rows)
=> SELECT node_name, projection_name, storage_oid, sal_storage_id, total_row_count, deleted_row_count, segment_lower_bound, segment_upper_bound, shard_name FROM storage_containers WHERE projection_name = 't_super';
node_name | projection_name | storage_oid | sal_storage_id | total_row_count | deleted_row_count | segment_lower_bound | segment_upper_bound | shard_name
----------+-----------------+-------------------+--------------------------------------------------+-----------------+-------------------+---------------------+---------------------+-------------
initiator | t_super | 45035996273842990 | 022e836bff54b0aed318df2fe73b5afe00a0000000021b2d | 4 | 0 | 0 | 1073741825 | segment0001
e0 | t_super | 49539595901213486 | 024bbf043c1ca3f5c7a86a423fc7e1e300b0000000021b2d | 3 | 0 | 1073741826 | 2147483649 | segment0002
e1 | t_super | 54043195528583990 | 02dac7dc405a1620c92bae1a17c7bbad00c0000000021b35 | 8 | 0 | 2147483650 | 3221225473 | segment0003
e2 | t_super | 54043195528583992 | 02dac7dc405a1620c92bae1a17c7bbad00c0000000021b31 | 6 | 0 | 3221225474 | 4294967295 | segment0004
(4 rows)
以下对 RESHARD_DATABASE 的调用将分片数更改为八个：
=> SELECT RESHARD_DATABASE(8);
RESHARD_DATABASE
----------------------------------------------------------
The database has been re-sharded from 4 shards to 8 shards
(1 row)
可以使用以下查询来查看数据库的新分片定义：
=> SELECT shard_name, lower_hash_bound, upper_hash_bound FROM shards ORDER BY shard_name;
shard_name | lower_hash_bound | upper_hash_bound
-------------+------------------+------------------
replica | |
segment0001 | 0 | 536870913
segment0002 | 536870914 | 1073741825
segment0003 | 1073741826 | 1610612737
segment0004 | 1610612738 | 2147483649
segment0005 | 2147483650 | 2684354561
segment0006 | 2684354562 | 3221225473
segment0007 | 3221225474 | 3758096385
segment0008 | 3758096386 | 4294967295
(9 rows)
数据库现在有八个分片。因为重新分片将每个分片的边界范围减半，所以每个分片负责大约一半的公共存储数据。
以下查询返回数据库的新节点订阅：
=> SELECT node_name, shard_name, is_primary, is_resubscribing, is_participating_primary FROM node_subscriptions;
node_name | shard_name | is_primary | is_resubscribing | is_participating_primary
-----------+-------------+------------+------------------+--------------------------
initiator | replica | t | f | t
e0 | replica | f | f | t
e1 | replica | f | f | t
e2 | replica | f | f | t
initiator | segment0001 | t | f | t
e0 | segment0002 | t | f | t
e1 | segment0003 | t | f | t
e2 | segment0004 | t | f | t
initiator | segment0005 | t | f | t
e0 | segment0006 | t | f | t
e1 | segment0007 | t | f | t
e2 | segment0008 | t | f | t
(12 rows)
重新分片后，每个节点现在订阅两个分片而不是一个。
可以使用以下查询来查看重新分片如何影响数据库的存储容器编录对象：
=> SELECT node_name, projection_name, storage_oid, sal_storage_id, total_row_count, deleted_row_count, segment_lower_bound, segment_upper_bound, shard_name FROM storage_containers WHERE projection_name = 't_super';
node_name | projection_name | storage_oid | sal_storage_id | total_row_count | deleted_row_count | segment_lower_bound | segment_upper_bound | shard_name
----------+-----------------+-------------------+--------------------------------------------------+-----------------+-------------------+---------------------+---------------------+-------------
initiator | t_super | 45035996273843145 | 02dac7dc405a1620c92bae1a17c7bbad00c0000000021b35 | 8 | 0 | 2147483650 | 3221225473 | segment0005
initiator | t_super | 45035996273843149 | 022e836bff54b0aed318df2fe73b5afe00a0000000021b2d | 4 | 0 | 0 | 1073741825 | segment0001
e0 | t_super | 49539595901213641 | 02dac7dc405a1620c92bae1a17c7bbad00c0000000021b35 | 8 | 0 | 2147483650 | 3221225473 | segment0006
e0 | t_super | 49539595901213645 | 022e836bff54b0aed318df2fe73b5afe00a0000000021b2d | 4 | 0 | 0 | 1073741825 | segment0002
e1 | t_super | 54043195528584141 | 02dac7dc405a1620c92bae1a17c7bbad00c0000000021b31 | 6 | 0 | 3221225474 | 4294967295 | segment0007
e1 | t_super | 54043195528584143 | 02dac7dc405a1620c92bae1a17c7bbad00c0000000021b31 | 6 | 0 | 1073741826 | 2147483649 | segment0003
e2 | t_super | 54043195528584137 | 024bbf043c1ca3f5c7a86a423fc7e1e300b0000000021b2d | 3 | 0 | 3221225474 | 4294967295 | segment0008
e2 | t_super | 54043195528584139 | 024bbf043c1ca3f5c7a86a423fc7e1e300b0000000021b2d | 3 | 0 | 1073741826 | 2147483649 | segment0004
(8 rows)
分片指向与重新分片之前具有相同 sal_storage_id 的存储文件。最终，TM 的合并进程将自动更新存储容器。
将数据库重新分片后，您可以查询 DC_ROSES_CREATED 表以跟踪原始 ROS 容器和派生新存储容器的 DVMiniROS：
=> SELECT node_name, projection_name storage_oid, old_storage_oid, is_dv FROM DC_ROSES_CREATED;
node_name | projection_name | storage_oid | old_storage_oid | is_dv
---------------------+------------------+-------------------+-----------------------------
initiator | t_super | 45035996273860625 | 45035996273843149 | f
initiator | t_super | 45035996273860632 | 0 | f
e0 | t_super | 45035996273843149 | 0 | f
(3 rows)
6.2 - 使用子群集提高查询吞吐量
提高查询吞吐量会同时增加 Eon 模式数据库处理的查询数量。当您的工作负载包含多个短期运行的查询时，您通常会担心数据库的吞吐量。它们通常被称为“仪表板查询”。该术语描述了当大量用户打开基于 Web 的仪表板页面以监控某种状态时您看到的工作负载类型。这些仪表板往往会频繁更新，使用较简单的短期运行的查询，而不是分析量繁重的长期运行查询。
提高数据库吞吐量的最佳方法是向数据库添加新的子群集或启动任何停止的子群集。然后使用连接负载均衡策略在这些子群集之间分配客户端连接。子群集独立处理查询。通过添加更多子群集，您可以提高数据库的并行度。
为获得最佳性能，应使子群集中的节点数与数据库中的分片数相同。如果您选择的节点数少于分片数，请将节点数设为分片数的偶数除数。当分片数可以被节点数整除时，数据库中的数据就会在子群集中的节点之间平均分配。
添加子群集的最简单方法是使用 MC：
-
在 MC 主页中，单击要将子群集添加到的数据库。
-
单击管理 (Manage)。
-
单击添加子群集 (Add Subcluster)。
-
按照向导中的步骤添加子群集。通常，您需要填写的唯一项目是子群集名称和要添加到其中的实例数。
注意
MC 目前不支持在所有平台上创建实例。对于 MC 不支持实例的平台，您可以手动添加子群集。有关详细信息，请参阅创建子群集。在吞吐量子群集之间分配客户端
要从添加的子群集中获益，您必须让执行短期查询的客户端连接到子群集包含的节点。查询仅在包含启动程序节点（客户端连接到的节点）的子群集上运行。使用连接负载均衡策略将连接分布在您创建的所有子群集中，以提高查询吞吐量。有关详细信息，请参阅连接负载均衡策略。
以下示例创建了一个负载均衡策略，该策略将客户端连接分布在两个名为 query_pool_a 和 query_pool_b 的三节点子群集中。此示例：
-
在两个子群集中的六个节点上创建网络地址。
-
从两个子群集中的所有节点创建一个负载均衡组。
-
创建路由规则以将所有传入连接重定向到两个子群集。
=> CREATE NETWORK ADDRESS node04 ON v_verticadb_node0004 WITH '203.0.113.1';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node05 ON v_verticadb_node0005 WITH '203.0.113.2';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node06 ON v_verticadb_node0006 WITH '203.0.113.3';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node07 ON v_verticadb_node0007 WITH '203.0.113.4';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node08 ON v_verticadb_node0008 WITH '203.0.113.5';
CREATE NETWORK ADDRESS
=> CREATE NETWORK ADDRESS node09 ON v_verticadb_node0009 WITH '203.0.113.6';
CREATE NETWORK ADDRESS
=> CREATE LOAD BALANCE GROUP query_subclusters WITH SUBCLUSTER query_pool_a,
query_pool_b FILTER '0.0.0.0/0';
CREATE LOAD BALANCE GROUP
=> CREATE ROUTING RULE query_clients ROUTE '0.0.0.0/0' TO query_subclusters;
CREATE ROUTING RULE
重要
在将要从专用网络外部连接客户端的云环境中，在创建网络地址时对每个节点使用外部 IP 地址。否则，外部客户端将无法连接到节点。
如果您同时拥有内部和外部客户端，请为每个节点设置两个网络地址，并将它们添加到两个单独的负载均衡组：一个用于内部客户端，另一个用于外部客户端。然后创建两个路由规则，一个将内部客户端路由到内部组，另一个将外部客户端路由到外部组。使内部客户端的路由规则仅应用于您的内部客户端将从其中连接的虚拟专用网络（例如，10.0.0.0/8）。外部客户端的路由规则可以使用 0.0.0.0/0 CIDR 范围（所有 IP 地址）作为传入连接地址范围。这些规则将一起正常工作，因为更具体的内部客户端路由规则优先于限制较少的外部客户端规则。
创建策略后，任何选择负载均衡的客户端都将重定向到两个子群集中的节点之一。例如，当您使用带有 -C 标志的 vsql 连接到群集中的节点 1（IP 地址为 203.0.113.1）时，您会看到类似如下的输出：
$ vsql -h 203.0.113.1 -U dbadmin -w mypassword -C
Welcome to vsql, the Vertica Analytic Database interactive terminal.
Type: \h or \? for help with vsql commands
\g or terminate with semicolon to execute query
\q to quit
SSL connection (cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, protocol: TLSv1.2)
INFO: Connected using a load-balanced connection.
INFO: Connected to 203.0.113.7 at port 5433.
=>
连接负载均衡策略考虑了在选择节点来处理客户端连接时停止的节点。如果您在低需求期间关闭一个或多个子群集以节省资金，那么只要某些节点仍处于运行状态，您就无需调整负载均衡策略。
6.3 - 使用 Elastic Crunch Scaling 提高查询性能
您可以选择将节点添加到数据库中，以提高长时间运行的复杂分析查询的性能。添加节点有助于这些查询提高运行速度。
当子群集中的节点多于数据库中的分片时，多个节点将订阅每个分片。为使子群集中的所有节点都参与查询，Vertica 查询优化器会自动使用称为 Elastic Crunch Scaling (ECS) 的功能。此功能会将处理每个分片中的数据的责任分配给订阅它的各个节点。在查询期间，每个节点要处理的数据更少，通常可以更快地完成查询。
例如，假设三分片数据库中包含六节点子群集。在此子群集中，两个节点会订阅每个分片。执行某个查询时，Vertica 会为每个节点分配其订阅的分片中大约一半的数据。由于子群集中的所有节点都参与该查询，因此该查询通常比只有一半节点参与时完成的速度更快。
ECS 会让节点数多于分片的子群集表现得好像数据库中的分片计数更高。在三分片数据库中，六节点子群集表现得好像数据库将每个分片分成两半而具有六个分片。但是，使用 ECS 的效率不如拥有更多的分片计数。实际上，您会发现在三分片数据库中的六节点子群集的查询性能比六分片数据库中的六节点子群集稍慢。
您可以调用 RESHARD_DATABASE 来更改数据库中的分片数量。如果新的分片数大于或等于子群集中的节点数，则子群集不再使用 ECS。这通常会导致查询速度更快。但是，重新分片会导致编录大小以及最初与新分片定义不一致的存储容器更大。在重新对齐存储容器之前，查询必须筛选出存储容器中超出新分片边界的数据。这会为查询增加少许开销。有关详细信息，请参阅更改数据库中的分片数。
您可以通过查询 V_CATALOG.SESSION_SUBSCRIPTIONS 系统表并查找 is_collaborating 列为 TRUE 的节点来确定优化器何时在子群集中使用 ECS。节点计数小于或等于数据库中分片数的子群集只有参与节点。节点数多于数据库的分片计数的子群集会为“额外”的节点分配协作者角色。执行查询时，这两种类型的节点之间的差异并不重要。这两种类型仅与 Vertica 如何组织节点以执行启用 ECS 的查询有关。
此示例显示如何获取参与或协作解决当前会话查询的节点列表：
=> SELECT node_name, shard_name, is_collaborating, is_participating
FROM V_CATALOG.SESSION_SUBSCRIPTIONS
WHERE is_participating = TRUE OR is_collaborating = TRUE
ORDER BY shard_name, node_name;
node_name | shard_name | is_collaborating | is_participating
----------------------+-------------+------------------+------------------
v_verticadb_node0004 | replica | f | t
v_verticadb_node0005 | replica | f | t
v_verticadb_node0006 | replica | t | f
v_verticadb_node0007 | replica | f | t
v_verticadb_node0008 | replica | t | f
v_verticadb_node0009 | replica | t | f
v_verticadb_node0007 | segment0001 | f | t
v_verticadb_node0008 | segment0001 | t | f
v_verticadb_node0005 | segment0002 | f | t
v_verticadb_node0009 | segment0002 | t | f
v_verticadb_node0004 | segment0003 | f | t
v_verticadb_node0006 | segment0003 | t | f
(12 rows)
您可以看到节点 4、5 和 7 正在参与，而节点 6、8 和 9 正在协作。
通过查看查询的 EXPLAIN 计划，您还可以看到已启用 ECS。在启用 ECS 的查询计划的顶部，显示的语句是“此查询涉及非参与节点 (this query involves non-participating nodes)”。这些非参与节点是协作节点，后者会使用参与节点来拆分分片中的数据。该计划还列出了参与查询的节点。
此示例显示三分片数据库的六节点子群集中已启用 ECS 的查询的说明计划：
=> EXPLAIN SELECT sales_quantity, sales_dollar_amount, transaction_type, cc_name
FROM online_sales.online_sales_fact
INNER JOIN online_sales.call_center_dimension
ON (online_sales.online_sales_fact.call_center_key
= online_sales.call_center_dimension.call_center_key
AND sale_date_key = 156)
ORDER BY sales_dollar_amount DESC;
QUERY PLAN
--------------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
The execution of this query involves non-participating nodes. Crunch scaling
strategy preserves data segmentation
------------------------------
EXPLAIN SELECT sales_quantity, sales_dollar_amount, transaction_type, cc_name
FROM online_sales.online_sales_fact
INNER JOIN online_sales.call_center_dimension
ON (online_sales.online_sales_fact.call_center_key
= online_sales.call_center_dimension.call_center_key
AND sale_date_key = 156)
ORDER BY sales_dollar_amount DESC;
Access Path:
+-SORT [Cost: 6K, Rows: 754K] (PATH ID: 1)
| Order: online_sales_fact.sales_dollar_amount DESC
| Execute on: v_verticadb_node0007, v_verticadb_node0004, v_verticadb_node0005,
| v_verticadb_node0006, v_verticadb_node0008, v_verticadb_node0009
| +---> JOIN MERGEJOIN(inputs presorted) [Cost: 530, Rows: 754K (202 RLE)] (PATH ID: 2)
| | Join Cond: (online_sales_fact.call_center_key = call_center_dimension.call_center_key)
| | Materialize at Output: online_sales_fact.sales_quantity,
| | online_sales_fact.sales_dollar_amount, online_sales_fact.transaction_type
| | Execute on: v_verticadb_node0007, v_verticadb_node0004,
| | v_verticadb_node0005, v_verticadb_node0006, v_verticadb_node0008,
| | v_verticadb_node0009
| | +-- Outer -> STORAGE ACCESS for online_sales_fact [Cost: 13, Rows: 754K (202 RLE)] (PATH ID: 3)
| | | Projection: online_sales.online_sales_fact_DBD_18_seg_vmart_b0
| | | Materialize: online_sales_fact.call_center_key
| | | Filter: (online_sales_fact.sale_date_key = 156)
| | | Execute on: v_verticadb_node0007, v_verticadb_node0004,
| | | v_verticadb_node0005, v_verticadb_node0006, v_verticadb_node0008,
| | | v_verticadb_node0009
| | | Runtime Filter: (SIP1(MergeJoin): online_sales_fact.call_center_key)
| | +-- Inner -> STORAGE ACCESS for call_center_dimension [Cost: 17, Rows: 200] (PATH ID: 4)
| | | Projection: online_sales.call_center_dimension_DBD_16_seg_vmart_b0
| | | Materialize: call_center_dimension.call_center_key, call_center_dimension.cc_name
| | | Execute on: v_verticadb_node0007, v_verticadb_node0004,
v_verticadb_node0005, v_verticadb_node0006, v_verticadb_node0008,
v_verticadb_node0009
. . .
利用 ECS
要利用 ECS，请创建辅助子群集，其中节点数是数据库中分片数的倍数。例如，在 12 分片数据库中，创建包含的节点数为 12 的倍数的子群集，例如 24 或 36。节点数必须是分片数的倍数，才能将数据均匀分布在子群集中的节点上。有关详细信息，请参阅子群集。
注意
您可以向现有的辅助子群集添加更多节点，而不是创建新的子群集。只需确保子群集中的节点数是分片计数的倍数即可。创建子群集后，让用户连接到它并运行其分析查询。Vertica 会自动在子群集中启用 ECS，因为它包含的节点数多于数据库中的分片数。
优化器如何将数据责任分配给节点
在订阅节点之间划分分片中的数据时，优化器有两种策略可供选择。一种策略针对使用数据分段的查询进行优化。包含 JOIN 或 GROUP BY 子句的查询依赖于数据分段。另一种策略针对不需要分段的查询。
默认情况下，优化器会自动选择要使用的策略。对于大多数查询，自动选择的策略会提高查询速度。对于某些查询，您可能希望使用提示来手动覆盖策略。在少量查询中，ECS 对性能没有帮助。在这些情况下，您可以禁用 ECS。有关详细信息，请参阅手动选择 ECS 策略。
6.4 - 手动选择 ECS 策略
当子群集中的节点数大于数据库分片数时，Vertica 查询优化器使用 elastic crunch scaling (ECS) 让所有节点参与处理查询。对于每个分片，优化器使用以下策略之一在其订阅节点之间划分处理分片数据的责任：
优化器会根据查询是否可以利用数据分段而自动选择策略。您可以使用 EXPLAIN 来判断优化器为查询选择的策略。计划解释的顶部说明了 ECS 是否保留分段。例如，这个针对单表的简单查询不需要使用分段，所以使用了 I/O 优化策略：
=> EXPLAIN SELECT employee_last_name,
employee_first_name,employee_age
FROM employee_dimension
ORDER BY employee_age DESC;
QUERY PLAN
--------------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
The execution of this query involves non-participating nodes.
Crunch scaling strategy does not preserve data segmentation
------------------------------
. . .
对于使用 JOIN 的较复杂查询，ECS 会使用计算优化策略保留数据分段。查询计划告知您保留了分段：
=> EXPLAIN SELECT sales_quantity, sales_dollar_amount, transaction_type, cc_name
FROM online_sales.online_sales_fact
INNER JOIN online_sales.call_center_dimension
ON (online_sales.online_sales_fact.call_center_key
= online_sales.call_center_dimension.call_center_key
AND sale_date_key = 156)
ORDER BY sales_dollar_amount DESC;
QUERY PLAN
--------------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
The execution of this query involves non-participating nodes.
Crunch scaling strategy preserves data segmentation
------------------------------
. . .
在大多数情况下，优化器选择最佳策略来在订阅同一分片的节点之间拆分数据。但是，您可能偶尔发现某些查询性能不佳。在这些情况下，查询可以嵌入 ECSMODE 提示来指定使用哪种策略甚至禁用 ECS。
为单个查询设置 ECS 策略
您可以在查询中使用 ECSMODE 提示来强制优化器使用特定的 ECS 策略（或完全禁用 ECS）。ECSMODE 提示采用以下实参之一：
-
AUTO：优化器选择要使用的策略，仅当在会话级别设置 ECS 模式时才有用（请参阅为会话或数据库设置 ECS 策略）。 -
IO_OPTIMIZED：使用 I/O 优化策略。 -
COMPUTE_OPTIMIZED：使用计算优化策略。 -
NONE：对此查询禁用 ECS。只有参与节点才会涉及查询执行；协作节点不会涉及。
以下示例显示了简单的单表查询（被强制使用计算优化策略）的查询计划：
=> EXPLAIN SELECT /*+ECSMode(COMPUTE_OPTIMIZED)*/ employee_last_name,
employee_first_name,employee_age
FROM employee_dimension
ORDER BY employee_age DESC;
QUERY PLAN
--------------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
The execution of this query involves non-participating nodes.
Crunch scaling strategy preserves data segmentation
------------------------------
. . .
此示例在三分片数据库的六节点群集中禁用 ECS：
=> EXPLAIN SELECT /*+ECSMode(NONE)*/ employee_last_name,
employee_first_name,employee_age
FROM employee_dimension
ORDER BY employee_age DESC;
QUERY PLAN
--------------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
------------------------------
EXPLAIN SELECT /*+ECSMode(NONE)*/ employee_last_name,
employee_first_name,employee_age
FROM employee_dimension
ORDER BY employee_age DESC;
Access Path:
+-SORT [Cost: 243, Rows: 10K] (PATH ID: 1)
| Order: employee_dimension.employee_age DESC
| Execute on: v_verticadb_node0007, v_verticadb_node0004, v_verticadb_node0005
| +---> STORAGE ACCESS for employee_dimension [Cost: 71, Rows: 10K] (PATH ID: 2)
| | Projection: public.employee_dimension_DBD_8_seg_vmart_b0
| | Materialize: employee_dimension.employee_first_name,
| | employee_dimension.employee_last_name, employee_dimension.employee_age
| | Execute on: v_verticadb_node0007, v_verticadb_node0004,
| | v_verticadb_node0005
. . .
注意，该查询计划缺少“此查询涉及非参与节点 (this query involves non-participating nodes)”说明，这表示它不使用 ECS。另外，它仅列出了三个参与节点。这些节点被标记为参与 V_CATALOG.SESSION_SUBSCRIPTIONS 系统表。
为会话或数据库设置 ECS 策略
您可以使用 ECSMode 配置参数来设置当前会话的 ECS 策略。此参数接受与 ECSMODE 提示相同的值，NONE 除外（该值仅对单个查询有效）。
以下示例演示如何使用配置参数强制简单查询使用 COMPUTE_OPTIMIZED 策略。然后，它将参数设置回其默认值 AUTO：
=> EXPLAIN SELECT employee_first_name,employee_age
FROM employee_dimension ORDER BY employee_age DESC;
QUERY PLAN
--------------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
The execution of this query involves non-participating nodes.
Crunch scaling strategy does not preserve data segmentation
------------------------------
. . .
=> ALTER SESSION SET ECSMode = 'COMPUTE_OPTIMIZED';
ALTER SESSION
=> EXPLAIN SELECT employee_first_name,employee_age
FROM employee_dimension ORDER BY employee_age DESC;
QUERY PLAN
--------------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
The execution of this query involves non-participating nodes.
Crunch scaling strategy preserves data segmentation
------------------------------
. . .
=> ALTER SESSION SET ECSMode = 'AUTO';
ALTER SESSION
单个查询提示会覆盖会话级别设置。此示例将会话默认设置为使用 COMPUTE_OPTIMIZED，然后使用值为 AUTO 的 ECSMode 提示还原查询的默认行为：
=> ALTER SESSION SET ECSMode = 'COMPUTE_OPTIMIZED';
ALTER SESSION
=> EXPLAIN SELECT /*+ECSMode(AUTO)*/ employee_first_name,employee_age
FROM employee_dimension ORDER BY employee_age DESC;
QUERY PLAN
-----------------------------------------------------------------------------
------------------------------
QUERY PLAN DESCRIPTION:
The execution of this query involves non-participating nodes.
Crunch scaling strategy does not preserve data segmentation
------------------------------
请注意，将 ECSMode 提示设置为 AUTO 会让优化器选择 I/O 优化策略（不保留分段），而不是使用在会话级别设置的计算优化策略。
您还可以使用 ALTER DATABASE 在数据库级别设置 ECS 策略。但是，这样做会覆盖使用 ECS 的所有子群集中所有用户的 Vertica 优化器设置。在数据库级别设置 ECS 策略之前，请验证启用 ECS 的子群集的所有用户运行的大多数查询是否必须覆盖优化器的默认行为。如果不是，则仅针对受益于特定策略的查询，使用会话或查询级别设置来覆盖优化器。
7 - 存储容器的本地缓存
如果以投影指定的排序顺序读取容器数据很重要，则 Vertica 执行引擎使用 StorageMerge 运算符从存储容器中读取数据。这对于在将数据合并到单个存储容器之前必须保留从多个存储容器读取的数据的排序顺序的操作特别有用。强制排序顺序的常见操作包括 mergeout，以及一些带有 ORDER BY 子句的查询（例如 CREATE TABLE...AS，其中查询包含 ORDER BY 子句）。
执行引擎通常会向 StorageMerge 运算符分配多个线程。每个线程都分配有一个 Scan 运算符来打开和读取容器内容。如果要读取的容器数大于可用线程数，则执行引擎可能会将单个 Scan 运算符分配给多个容器。在这种情况下，Scan 运算符可能需要在不同的容器之间切换并多次重新打开它们，然后才能获取和组装所有必需的数据。尤其在读取远程文件系统（如 S3）上的存储容器时，这样做会出现问题。重新打开和读取远程存储容器所产生的额外开销会显著影响性能和使用成本。
您可以配置数据库，以便执行引擎在本地磁盘上缓存需要多次打开的 S3 存储容器的数据。每个查询分配给 StorageMerge 运算符用于缓存的临时空间大小由配置参数 StorageMergeMaxTempCacheMB 设置。默认情况下，此配置参数设置为 -1（无限制）。如果缓存请求超出临时空间限制或可用磁盘空间，Vertica 会缓存尽可能多的容器数据，然后从 S3 读取。
要关闭缓存，请将 StorageMergeMaxTempCacheMB 设置为 0。
8 - 在 MC 中管理 Eon 模式数据库
Vertica 管理控制台 (MC) 是一种数据库运行状况和活动监控工具，它提供浏览器内向导，您可以按照这些向导部署 Vertica 群集实例并在其上创建 Eon 模式数据库。您还可以使用 MC 来管理和监控特定于 Eon 模式的资源：
另请参阅
9 - 停止和启动 Eon 模式群集
使用 MC 停止 Eon 模式数据库和群集
在云中运行 Eon 模式数据库时，您通常希望在停止数据库时停止运行数据库的节点。停止节点可避免浪费钱。数据库关闭后，不需要使用节点。
注意
您仍然可以通过关闭未使用的子群集来节省费用，而不是关闭整个数据库。此技术可以让您的数据库继续运行和加载数据，同时降低每小时成本。有关详细信息，请参阅启动和停止子群集。停止数据库和运行它的节点的最简单方法是使用 MC：
-
在 MC 主页中，单击查看您的基础结构 (View Your Infrastructure)。
-
在带有“数据库 (Databases)”标签的行中，单击要停止的数据库。
-
在弹出窗口中，单击停止 (Stop)。
-
单击确定 (OK) 以确认要停止数据库。
-
数据库停止后，在带有“群集 (Clusters)”标签的行中，单击与运行刚刚停止的数据库的群集对应的条目。
-
在弹出窗口中，单击管理 (Manage)。
-
在群集视图顶部的功能区中，单击停止群集 (Stop Cluster)。
-
在对话框中，选中我想停止群集中的所有实例 (I would like to stop all instances in the cluster) 框，然后单击停止群集 (Stop Cluster)。
手动停止数据库和群集
要手动停止数据库和群集，请先使用以下方法之一停止数据库：
-
使用
stop_db管理工具命令停止数据库。请参阅停止数据库。 -
使用 SHUTDOWN 或 SHUTDOWN_WITH_DRAIN 函数停止数据库。
停止数据库后，您可以停止节点。如果您处于云环境中，请参阅云提供商的文档以获取有关停止节点的说明。
使用 MC 启动群集和数据库
要启动数据库群集和数据库：
-
在 MC 主页中，单击查看基础结构 (View Infrastructure)。
-
在“群集 (Clusters)”行中，单击运行要启动的数据库的群集。
-
在弹出窗口中，单击管理 (Manage)。
-
在群集页面顶部的功能区中，单击启动群集 (Start Cluster)。
-
选中我想启动群集中的所有实例 (I would like to start all instances in the cluster) 框，然后单击启动群集 (Start Cluster)。
启动群集会自动启动数据库。
手动启动群集和数据库
要手动启动群集和数据库：
-
启动数据库群集中的节点。如果在云中运行，请参阅云提供商的文档以了解如何启动实例。
-
连接到群集中的某个节点并使用管理工具菜单或命令行来启动数据库。有关说明，请参阅启动数据库。
10 - 终止 Eon 模式数据库群集
终止 Eon 模式数据库的群集时，即会释放其资源。在云环境中，终止群集会删除已运行数据库节点的实例。在本地数据库中，终止群集通常意味着将物理硬件重新用于其他用途。有关详细信息，请参阅停止、启动、终止和恢复 Eon 模式数据库群集。
终止 Eon 模式数据库的群集不会影响它存储的数据。数据仍然存储在公共存储位置。只要不删除公共存储位置，就可以将数据库恢复到新的 Eon 模式群集。有关详细信息，请参阅恢复 Eon 模式数据库群集。
重要
Vertica 会将编录数据保存在公共存储中，每隔几分钟更新一次。然而，在关闭数据库之前，应该确保元数据在公共存储上是最新的。为此，请参阅同步元数据。使用管理控制台终止 Eon 模式群集
管理控制台提供了终止 Eon 模式群集的最简单方法。您必须遵循两步过程：先停止数据库，然后终止群集：
-
如果您尚未同步数据库的编录，请按照同步元数据中的步骤操作。
-
在管理控制台主页中，单击查看您的基础结构 (View Your Infrastructure)。
-
在带有“数据库 (Databases)”标签的行中，单击要终止其群集的数据库。
-
在弹出窗口中，单击停止 (Stop)。
-
单击确定 (OK) 以确认要停止数据库。
-
数据库停止后，在带有“群集 (Clusters)”标签的行中，单击与要终止的群集对应的条目。
-
在弹出窗口中，单击管理 (Manage)。
-
在群集视图顶部的功能区中，单击高级 (Advanced)，然后选择终止群集 (Terminate Cluster)。
-
在对话框中：
-
选中我了解终止群集将终止群集中的所有实例 (I understand that terminating a cluster will terminate all instances in the cluster)
-
单击终止群集 (Terminate Cluster)。
-
手动终止 Eon 模式群集
要手动终止 Eon 模式群集：
-
如果您尚未同步数据库的编录，请按照同步元数据中的步骤操作。
-
请使用以下方法之一停止数据库：
-
终止数据库节点实例。如果处于云环境中，请参阅云提供商的文档以获取有关终止实例的说明。对于本地数据库群集，您可以改变属于群集的各个系统的用途。
另请参阅
11 - 恢复 Eon 模式数据库群集
如果已终止 Eon 模式数据库的群集，但尚未删除数据库的公共存储，则可以恢复数据库。恢复数据库会将其还原到关闭前的状态。恢复过程需要创建新的数据库群集并将其配置为使用数据库的公共存储位置。有关详细信息，请参阅停止、启动、终止和恢复 Eon 模式数据库群集。
当数据库的节点没有持久性本地存储时，您还可以使用恢复过程重新启动数据库。您可以选择使用非持久性本地存储在基于云的 Eon 模式群集中配置节点的实例，以降低成本。如果关闭实例时不需要使用实例来保留数据，则 AWS 和 GCP 等云提供商对实例收取较低的费用。
您可以使用管理控制台或管理工具来恢复数据库。MC 和管理工具提供的恢复方法不同：
-
MC 始终恢复到其自己创建的新配置群集上。它无法恢复到现有群集中。在还没有为您的数据库配置群集时，请使用 MC 来恢复数据库。
-
管理工具仅恢复到现有的数据库群集中。您可以手动创建用于恢复数据库的群集。请参阅手动安装。
此外，还可以恢复其主机使用实例存储的数据库，系统不会在关闭间隔之间持久存储实例存储中的数据。在这种情况下，管理工具会将现有数据库群集视为新群集，因为主机不包含数据库的编录数据。
-
目前，只有管理工具允许您仅恢复数据库群集中的 主子群集。如果要恢复启动数据库所需的最少节点数，此选项非常有用。请参阅下面的仅恢复主子群集。
MC 会始终恢复整个数据库群集。
注意
您无法从当前在另一个群集上运行的公共存储位置恢复数据库。如果检测到有一个已在运行数据库的群集，则恢复过程会失败。让两个数据库实例使用相同的公共存储位置在不同的群集上运行会导致数据损坏。使用管理控制台恢复
您可以使用管理控制台中的向导来配置新群集并通过浏览器将数据库恢复到该群集上。有关详细信息，请参阅：
使用管理工具恢复
您可以使用管理工具在现有群集上恢复 Eon 模式数据库。
群集要求
此现有群集必须：
-
安装有相同版本（或更高版本）的 Vertica。您可以改变已关闭其数据库的现有 Vertica 群集的用途。另一个选择是通过手动安装 Vertica 从头开始创建群集（请参阅手动安装）。
-
包含数量等于或大于以下任一数量的群集中的多个主机：
-
关闭时数据库群集拥有的节点总数。
-
关闭时数据库群集拥有的 主节点的总数。当您提供与数据库中主节点数量相匹配的群集时，管理工具只会恢复主节点。
-
恢复时，为管理工具提供要将数据库恢复到的群集中的主机的列表。此列表中的主机数必须与关闭时数据库中的节点总数或主节点数匹配。如果您提供的节点数与这些值中的任何一个都不匹配，则管理工具会返回错误。
您无需使用群集中的所有主机来恢复数据库。您可以将数据库恢复到群集中的主机子集上。但是，您必须至少有足够的主机来恢复所有主节点。
例如，假设您想恢复关闭时拥有 16 个节点的数据库，其中四个节点是主节点。在这种情况下，您可以：
-
仅将主节点恢复到至少包含四个节点的群集上。
-
将所有 16 个节点恢复到至少包含 16 个节点的群集上。
您可以选择将数据库恢复到具有更多节点的群集上，在要快速添加新节点时必须这样做。您可能还希望仅将数据库中的主节点恢复到更大的群集上。在这种情况下，您可以使用群集中的额外节点来启动一个或多个辅助子群集。
所需的数据库信息
要恢复数据库，您必须知道：
-
要恢复的数据库的名称（注意数据库名称区分大小写）
-
已创建数据库的 Vertica 版本，因此您可以使用相同或更高的版本
-
关闭时数据库中的所有节点总数或主节点数
-
数据库公共存储位置的 URL 和凭据
-
数据库管理员的用户名和密码
-
您要恢复到的群集中的所有主机的 IP 地址
如果您不知道已创建数据库的 Vertica 版本或不确定它拥有的节点数，请参阅下面的从公共存储位置获取数据库详细信息。
所需的数据库设置
在开始恢复过程之前，请验证您的 Eon 模式环境是否满足以下条件：
从公共存储位置获取数据库详细信息
要恢复数据库，您必须知道：
-
创建它所用的 Vertica 版本（因此您可以使用相同或更高版本）
-
关闭时数据库群集中的节点总数（同时恢复主节点和辅助节点时）或主节点总数（仅恢复主节点时）。
如果您不知道这些详细信息，可以根据公共存储位置的内容来确定这些信息。
如果您不确定哪个版本的 Vertica 创建了存储在公共存储位置中的数据库，请检查 cluster_config.json 文件。此文件存储在名为
metadata/databasename 的文件夹中的公共存储位置。例如，假设您有一个名为 mydb 的数据库存储在公共存储位置 s3://mybucket/mydb 中。然后，您可以下载并检查文件 s3://mybucket/mydb/metadata/mydb/cluster_config.json。
在 cluster_config.json 中，创建数据库的 Vertica 版本存储在文件顶部附近名为 DatabaseVersion 的 JSON 键中：
{
"CatalogTruncationVersion" : 804,
"ClusterLeaseExpiration" : "2020-12-21 21:52:31.005936",
"Database" : {
"branch" : "",
"name" : "verticadb"
},
"DatabaseVersion" : "v10.1.0",
"GlobalSettings" : {
"TupleMoverServices" : -33,
"appliedUpgrades" : [
. . .
在此示例中，您可以使用 Vertica 版本 10.1.0 或更高版本恢复存储位置。
如果您不知道关闭时群集拥有的节点数或主节点数，请使用管理工具的 revive_db 工具的 --display-only 选项。添加此选项可防止管理工具恢复数据库。相反，它会验证公共存储中的文件，并报告组成数据库群集的节点相关详细信息。此报告的部分内容显示群集中的节点总数和主节点数：
$ admintools -t revive_db --display-only --communal-storage-location \
s3://mybucket/verticadb -d verticadb
Attempting to retrieve file: [s3://mybucket/verticadb/metadata/verticadb/cluster_config.json]
Validated 6-node database verticadb defined at communal storage s3://mybucket/verticadb.
Expected layout of database after reviving from communal storage: s3://mybucket/verticadb
== Communal location details: ==
{
"communal_storage_url": "s3://mybucket/verticadb",
"num_shards": "3",
"depot_path": "/vertica/data",
. . .
]
Number of primary nodes: 3
您可以使用 grep 来仅查找报告中的相关行：
$ admintools -t revive_db --display-only --communal-storage-location \
s3://mybucket/verticadb -d verticadb | grep 'Validated\|primary nodes'
Validated 6-node database verticadb defined at communal storage s3://mybucket/verticadb.
Number of primary nodes: 3
创建参数文件
对于不在 AWS 上的 Eon 模式部署，您必须创建一个配置文件以将上一部分的表中列出的参数传递给管理工具。以前，此文件命名为 auth_params.conf，但现在您可以选择所需的任何文件名。
对于本地 Eon 模式数据库，此参数文件与最初安装数据库时使用的参数文件相同。有关为用于数据库的公共存储解决方案创建参数文件的说明，请参阅以下链接：
对于在 Microsoft Azure 上运行的数据库，仅当您的数据库不使用托管标识时才需要参数文件。此文件与您用于手动安装 Eon 模式数据库的格式相同。有关详细信息，请参阅在 Azure 上手动创建 Eon 模式数据库。
要在 GCP 上手动恢复 Eon 模式数据库，请创建一个配置文件来保存 GCSAuth 参数和（可选）GCSEnableHttp 参数。
您必须提供 GCSAuth 参数才能使 Vertica 能够从 GCS 中存储的公共存储位置读取数据。此参数的值是 HMAC 访问密钥和密码：
GCSAuth = HMAC_access_key:HMAC_secret_key
有关 HMAC 密钥的详细信息，请参阅创建 HMAC 密钥。
如果您的 Eon 模式数据库在访问 GCS 上的公共存储时未使用加密，请通过将以下行添加到 auth_params.conf 来禁止访问 HTTPS ：
GCSEnableHttps = 0
运行 revive_db 工具
使用管理工具的 revive_db 工具恢复数据库：
-
使用 SSH 以管理员身份访问群集主机。
-
根据您的环境，运行以下管理工具命令行之一：
-
AWS：
$ admintools -t revive_db \ --communal-storage-location=s3://communal_store_path \ -s host1,... -d database_name -
对于本地和其他环境，请运行以下命令：
$ admintools -t revive_db -x auth_params.conf \ --communal-storage-location=storage-schema://communal_store_path \ -s host1_ip,... -d database_name
-
此示例将恢复六节点本地数据库：
$ admintools -t revive_db -x auth_params.conf \
--communal-storage-location=s3://mybucket/mydir \
-s 172.16.116.27,172.16.116.28,172.16.116.29,172.16.116.30,\
172.16.116.31,172.16.116.32 -d VMart
以下示例演示如何恢复 GCP 上托管的三节点数据库：
$ admintools -t revive_db -x auth_params.conf \
--communal-storage-location gs://mybucket/verticadb \
-s 10.142.0.35,10.142.0.38,10.142.0.39 -d VerticaDB
Attempting to retrieve file:
[gs://mybucket/verticadb/metadata/VerticaDB/cluster_config.json]
Validated 3-node database VerticaDB defined at communal storage
gs://mybucket/verticadb .
Cluster lease has expired.
Preparation succeeded all hosts
Calculated necessary addresses for all nodes.
Starting to bootstrap nodes. Please wait, databases with a large
catalog may take a while to initialize.
>>Calling bootstrap on node v_verticadb_node0002 (10.142.0.38)
>>Calling bootstrap on node v_verticadb_node0003 (10.142.0.39)
Load Remote Catalog succeeded on all hosts
Database revived successfully.
仅恢复主子群集
您可以仅恢复 Eon 模式数据库中的主子群集。使传递给管理工具的 revive_db 工具的 --hosts（或 -s）实参的主机列表与关闭时数据库中的主节点数匹配。例如，如果您的六节点 Eon 模式数据库具有三个主节点，则可以通过在 --hosts 实参中提供三个主机来仅恢复主节点：
$ admintools -t revive_db --communal-storage-location=s3://verticadb -d verticadb \
-x auth_params.conf --hosts node01,node02,node03
Attempting to retrieve file: [s3://verticadb/metadata/verticadb/cluster_config.json]
Consider reviving to only primary nodes: communal storage indicates 6 nodes, while
3 nodes were specified
Validated 3-node database verticadb defined at communal storage s3://verticadb.
Cluster lease has expired.
Preparation succeeded all hosts
Calculated necessary addresses for all nodes.
Starting to bootstrap nodes. Please wait, databases with a large catalog may take a
while to initialize.
>>Calling bootstrap on node v_verticadb_node0002 (192.168.56.103)
>>Calling bootstrap on node v_verticadb_node0003 (192.168.56.104)
Load Remote Catalog succeeded on all hosts
Database revived successfully.
在已仅恢复主节点的数据库中，辅助节点处于关闭状态。请将其 IP 地址设置为 0.0.0.0，因此它们不是数据库的一部分。例如，如果查询上例中恢复的数据库中的 NODES 系统表，则会显示辅助节点均已关闭：
=> SELECT node_name,node_state,node_address,subcluster_name FROM NODES;
node_name | node_state | node_address | subcluster_name
----------------------+------------+----------------+--------------------
v_verticadb_node0001 | UP | 192.168.56.102 | default_subcluster
v_verticadb_node0002 | UP | 192.168.56.103 | default_subcluster
v_verticadb_node0003 | UP | 192.168.56.104 | default_subcluster
v_verticadb_node0004 | DOWN | 0.0.0.0 | analytics
v_verticadb_node0005 | DOWN | 0.0.0.0 | analytics
v_verticadb_node0006 | DOWN | 0.0.0.0 | analytics
注意
如果您的数据库已启用大型群集功能，则尚未恢复的辅助节点可能会导致出现错误消息。（有关大型群集功能的详细信息，请参阅大型群集。）
例如，如果为新节点分配一个尚未恢复的控制节点，则将节点添加到辅助子群集可能会失败。在这种情况下，Vertica 会报告添加节点失败，因为该控制节点的 IP 地址无效。
如果遇到涉及 IP 地址无效的控制节点的错误，请考虑恢复未恢复的辅助子群集，如下所述。
由于 Vertica 将这些未恢复的节点视为已关闭，因此当这些节点处于未恢复状态时，Vertica 可能不允许您将其移除或移除其子群集。移除节点或辅助子群集的最佳方法是先将其恢复。
恢复未恢复的辅助子群集
如果仅恢复了数据库中的主子群集，则可以稍后选择恢复部分或所有辅助子群集。您的群集必须具有不是数据库中的节点的主机，Vertica 可以使用这些主机来恢复未恢复的节点。如果您的群集没有足够的这些非节点主机，则可以添加更多主机。请参阅向群集中添加主机。
您可以使用管理工具的 restart_subcluster 工具来恢复辅助子群集。在将恢复节点的 --hosts 实参中为其提供主机列表。此列表中的主机数必须与子群集中的节点数匹配。您必须同时恢复子群集中的所有节点。如果向 restart_subcluster 传递的列表包含的主机数少于或多于子群集中定义的节点数，则会返回错误。
以下示例演示如何恢复前面的示例中显示的名为 analytics 的辅助子群集。
$ admintools -t restart_subcluster -d verticadb --hosts node04,node05,node06 \
-p 'password' -c analytics
Updating hostnames of nodes in subcluster analytics.
Replicating configuration to all nodes
Generating new configuration information and reloading spread
Hostnames of nodes in subcluster analytics updated successfully.
*** Restarting subcluster for database verticadb ** *
Restarting host [192.168.56.105] with catalog [v_verticadb_node0004_catalog]
Restarting host [192.168.56.106] with catalog [v_verticadb_node0005_catalog]
Restarting host [192.168.56.107] with catalog [v_verticadb_node0006_catalog]
Issuing multi-node restart
Starting nodes:
v_verticadb_node0004 (192.168.56.105)
v_verticadb_node0005 (192.168.56.106)
v_verticadb_node0006 (192.168.56.107)
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)
Node Status: v_verticadb_node0004: (DOWN) v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
Node Status: v_verticadb_node0004: (DOWN) v_verticadb_node0005: (DOWN) v_verticadb_node0006: (DOWN)
Node Status: v_verticadb_node0004: (INITIALIZING) v_verticadb_node0005: (INITIALIZING) v_verticadb_node0006: (INITIALIZING)
Node Status: v_verticadb_node0004: (UP) v_verticadb_node0005: (UP) v_verticadb_node0006: (UP)
Syncing catalog on verticadb with 2000 attempts.
另请参阅
12 - 同步元数据
Eon 模式数据库会在公共存储中保留其编录，其中包含所有数据库元数据。Vertica 在恢复数据库时会使用此元数据，因此编录始终保持最新非常重要。Vertica 会按照配置参数 CatalogSyncInterval 指定的定期时间间隔（默认设置为五分钟）自动同步编录。
一般而言，不需要监控同步过程或更改它。但有一个例外：在关闭打算恢复或复制的数据库之前，最好验证编录是否包含最近进行的所有更改，并在必要时手动同步它。
验证编录状态
您可以通过两种方式验证数据库编录的同步状态，具体取决于数据库是否正在运行。
如果数据库正在运行，则查询并比较这两个系统表：
-
CATALOG_SYNC_STATE：显示每个节点最近将其编录同步到公共存储的方式，以及已同步的版本。
-
CATALOG_TRUNCATION_STATUS：显示数据库编录的最新同步状态。当列
TRUNCATION_CATALOG_VERSION和CURRENT_CATALOG_VERSION相同时，编录同步即为最新的。
如果数据库当前未运行，请检查公共存储上的以下 JSON 文件：
/metadata/database‑name/cluster_config.json
此文件中的编录截断版本和时间戳会指示 Vertica 上次同步数据库编录的时间。
手动同步数据库数据日志
如有必要，请调用 SYNC_CATALOG 以立即将编录与所有节点或特定节点同步：
=> SELECT sync_catalog();
自定义同步时间间隔
默认情况下，Vertica 每五分钟检查一次编录是否更改。有时，您可能希望临时更改此设置 — 例如，将其设置为较高的值以获取当前存储桶内容的快照：
=> ALTER DATABASE DEFAULT SET CatalogSyncInterval = 300;
重要
如果针对特定任务将 CatalogSyncInterval 设置为较高的值，请确保在任务完成后立即将其恢复为默认设置：
=> ALTER DATABASE DEFAULT CLEAR PARAMETER CatalogSyncInterval;