Eon 模式将计算过程与数据库的公共存储层分开。这种分离使您能够将数据存储在单个位置（例如 AWS 上的 S3 或 Pure Storage），并根据您的计算需求弹性地改变连接到该位置的计算节点数。可以在不中断分析工作负载的情况下调整群集的大小，随着工作量的变化添加或移除节点。
以下主题介绍了 Eon 模式的工作原理。
1 - Eon 模式体系结构
Eon 模式将计算资源与数据库的存储层分开。这种分离使您能够将数据存储在单个位置。您可以根据计算需求弹性地改变连接到该位置的节点数。调整群集大小不会中断分析工作负载。
您可以在云环境中创建 Eon 模式数据库，也可以在您自己的系统上本地创建 Eon 模式数据库。
Eon 模式适用于各种需求和数据量。由于计算和存储分开，因此可以单独扩展它们。
公共存储
Eon 模式不将数据存储在本地，而是对所有数据和编录（元数据）使用单个公共存储位置。公共存储是数据库的集中式存储位置，在数据库节点之间共享。公共存储基于对象存储，例如云中的 Amazon S3 或内部部署中的 PureStorage FlashBlade 设备。无论哪种情况，Vertica 都依赖对象存储来维护数据的持久副本。
公共存储具有以下属性：
-
与单个计算机上的磁盘存储相比，云中的公共存储更具弹性，并且不易因存储故障而导致数据丢失。
-
任何节点都可以使用相同的路径读取任何数据。
-
容量不受节点上磁盘空间的限制。
-
由于数据是以公共方式存储的，因此您可以弹性扩展群集以满足不断变化的需求。如果数据本地存储在节点上，则添加或移除节点将需要在节点之间移动大量数据，以将其从要移除的节点上移出，或移动到新创建的节点上。
公共存储位置列在 STORAGE_LOCATIONS 系统表中，其中 SHARING_TYPE 为 COMMUNAL。
在公共存储中，数据被划分到称为 分片的部分。分片是 Vertica 在数据库中的节点之间划分数据的方式。节点订阅特定的分片，在节点之间平衡订阅。当加载或查询数据时，每个节点负责其订阅的分片中的数据。有关详细信息，请参阅分片和订阅。
存储库存储
公共存储的一个潜在缺点是它的速度，特别是在云环境中。从共享云位置访问数据要慢于从本地磁盘读取数据。此外，如果许多节点同时从公共存储中读取数据，则与公共存储的连接可能会成为瓶颈。为了提高数据访问速度，Eon 模式数据库中的节点维护一个称为存储库的本地磁盘数据缓存。当执行查询时，节点首先检查它需要的数据是否在存储库中。如果是，则节点使用数据的本地副本完成查询。如果数据不在存储库中，则节点从公共存储中提取数据，并在存储库中保存副本。
节点将新加载的数据存储在存储库中，然后将其发送到公共存储。有关详细信息，请参阅下面的“加载数据”。
默认情况下，Vertica 将存储库的最大大小设置为存储该存储库的文件系统的总磁盘空间的 60%。如果您愿意，可以调整存储库的大小。Vertica 将存储库的最大大小限制为包含它的文件系统的 80%。此上限可确保有足够的磁盘空间用于其他用途，例如 Vertica 在数据加载期间创建的临时文件。
每个节点还存储数据库编录的本地副本。
加载数据
在 Eon 模式下，COPY 语句通常写入节点存储库中的读取优化存储 (ROS) 文件以提高性能。COPY 语句通过分段、排序和压缩来实现高度优化。在语句提交之前，Vertica 将 ROS 文件传送到公共存储。
因为加载缓冲在执行加载的节点上的存储库中，所以存储库的大小会限制可以在单个操作中加载的数据量。除非在并行会话中执行多个加载，否则不太可能遇到此限制。
注意
如果数据加载确实超出了数据库存储库中的空间量，则可以告知 Vertica 绕过存储库，并将数据直接加载到公共存储中。您可以通过将 UseDepotForWrites 配置参数设置为 0 来启用对公共存储的直接写入。有关详细信息，请参阅Eon 模式参数。完成大数据加载后，将此参数切换回 1 以重新启用向存储库的写入。在加载时，参与节点将文件写入存储库，并将其同步发送到公共存储。还会将数据发送到订阅分片（要将数据加载到其中）的所有节点。这种在加载时向对等节点发送数据的机制可以在节点出现故障时提高性能，因为接管故障节点的对等节点的缓存已经预热。文件压缩机制（合并）将其输出文件放入缓存中，同时将它们上传到公共存储。
下图显示了执行 COPY 语句期间的数据流。
查询数据
在 Eon 模式下，Vertica 使用略有不同的流程计划查询，以合并分片机制和远程存储。Vertica 不使用固定分段方案将数据分发到每个节点，而是使用分片机制将数据分段为至少一个（通常更多）节点订阅的特定数量的分片。当优化器选择投影时，投影的布局由会话的参与订阅确定。优化器生成与企业模式中的查询计划等效的查询计划。它选择订阅每个分片的节点之一来参与查询执行。
Vertica 首先尝试使用存储库中的数据来解决查询。当存储库中的数据无法解决查询时，Vertica 将从公共存储中读取数据。当大量查询从公共存储读取数据时，您可能会看到对查询性能的影响。如果是这种情况，那么您应该考虑调整存储库的大小，或使用存储库系统表来更好地了解导致问题的原因。您可以使用 ALTER_LOCATION_SIZE 来更改存储库大小。
工作负载隔离和扩展
Eon 模式允许您定义子群集，这些子群集划分节点以相互隔离工作负载。您还可以使用子群集来确保缩减群集不会导致 Vertica 进入只读模式，以保持数据完整性。有关详细信息，请参阅子群集。
2 - 分片和订阅
在 Eon 模式下，Vertica 会将数据以公共方式存储在共享数据存储位置（例如，在 AWS 上运行时存储在 S3 中）。所有节点都能够访问公共存储位置中的所有数据。为了让节点划分处理查询的工作，Vertica 必须以某种方式在它们之间划分数据。它会将公共存储中的数据分成称为分片的段。数据库中的每个节点都订阅公共存储位置中的分片子集。公共存储位置中的分片类似于企业模式数据库中的分段投影集合。
当 K-Safety 为 1 或更高（高可用性）时，每个子群集中都有多个节点订阅每个分片。其中一个订户负责执行涉及分片的查询。其他订户充当备份。如果主订户关闭或停止，则另一个订户将取而代之。有关详细信息，请参阅Eon 模式数据库中的数据完整性和高可用性。
数据库中的每个分片都有一个主订户。此订户是 主节点，它通过计划分片上的 Tuple Mover 操作来维护分片中的数据。此节点可以将执行这些操作委派给数据库群集中的另一个节点。有关这些操作的详细信息，请参阅 Tuple mover。如果主订户节点停止或关闭，Vertica 会选择另一个订阅该分片的主节点作为该分片的主订户。如果订阅分片的所有主节点都关闭或停止，则数据库将进入只读模式以保持数据完整性。作为分片唯一订户的任何主节点都是 关键节点。
一种称为副本分片的特殊类型的分片存储未分段投影的元数据。副本分片存在于所有节点上。
您可以在创建数据库时定义分片的数量。为了获得最佳性能，您选择的分片数量不应大于 2× 节点数。您最多应该将分片与节点的比率限制为不大于 3:1。MC 警告您要考虑分片计数的各个方面。分片数应始终是数据库中节点数的倍数（或偶数除数）。有关详细信息，请参阅选择分片数和初始节点计数。
创建数据库后，可以使用 RESHARD_DATABASE 更改数据库中的分片数。有关详细信息，请参阅更改数据库中的分片数。
为了提高效率，Vertica 直接在数据库节点之间传输有关分片的元数据。这种点对点传输仅适用于元数据；存储在每个节点上的实际数据会根据需要从公共存储复制到节点的存储库。
3 - 子群集
由于 Eon 模式将计算和存储分开，因此您可以在群集中创建子群集来隔离工作。例如，您可能希望将一些节点专用于加载数据，而将其他节点专用于执行查询。或者，您可能希望为专门的用户组（他们可能有不同的优先级）创建子群集。您还可以使用子群集将节点组织成组，以便轻松地扩展和收缩群集。
Eon 模式数据库中的每个节点都必须属于一个子群集。这一要求意味着您的数据库必须始终至少有一个子群集。当您创建新的 Eon 模式数据库时，Vertica 会创建一个名为 default_subcluster 的子群集，其中包含您在创建数据库时创建的节点。如果您将节点添加到数据库而不将它们分配给子群集，Vertica 会将它们添加到默认子群集。您可以选择将另一个子群集指定为默认子群集，或者将 default_subcluster 重命名为更具描述性的名称。有关详细信息，请参阅更改子群集设置。
使用子群集进行工作隔离
数据库管理员通常关心工作负载管理。密集的分析查询可能会消耗如此多的资源，以至于它们会干扰其他重要的数据库任务（例如数据加载）。子群集通过将工作负载相互隔离来帮助您防止资源问题。
在 Eon 模式下，默认情况下，查询仅在包含启动程序节点的子群集中的节点上运行。例如，考虑下图中显示的两个子群集。如果您连接到节点 4，您的查询将在节点 4 到节点 9 上运行。
同样，在节点 1 上启动的查询仅在节点 1 到节点 3 上运行。
这种隔离使您可以配置数据库群集以防止工作负载相互干扰。您可以将子群集分配给特定任务，例如加载数据、执行深入分析和短时间运行的仪表板查询。您还可以为组织中的不同组创建子群集，这样他们的工作负载就不会相互干扰。您可以调整每个子群集的设置（例如资源池）以匹配其特定的工作负载。
子群集类型
有两种类型的子群集：主子群集和辅助子群集。
主子群集构成 Vertica 数据库的核心。它们负责规划公共存储中数据的维护。您的主子群集必须始终运行。如果所有主子群集都关闭，您的数据库也会关闭，因为如果没有主子群集，数据库就无法在公共存储中维护数据。
通常，您的数据库中只有一个主子群集。您可以选择拥有多个主子群集。额外的主子群集可以使您的数据库在主节点发生故障时更具弹性。但是，额外的主子群集会降低数据库的可扩展性。您通常不会从主子群集中动态添加或移除节点，也不会关闭它们来扩展数据库。在大多数情况下，一个主子群集就足够了。
辅助子群集专为动态扩展而设计：您可以根据分析需求添加和移除或启动和停止这些子群集。它们对于维护数据库数据不是必需的。因此，您可以轻松地添加、移除和扩展或收缩辅助子群集，而不会影响数据库正常运行的能力。
子群集中的节点从包含它们的子群集继承其主或辅助状态；主子群集包含主节点，辅助子群集包含辅助节点。
子群集类型和弹性扩展
主子群集和辅助子群集之间最重要的区别在于，它们对 Vertica 如何确定数据库是否为 K-Safe 和是否具有 仲裁的影响。当确定数据库中的所有分片是否都有订阅节点时，Vertica 仅考虑主子群集中的节点。当确定数据库中是否有一半以上的节点正在运行时，它也仅考虑主节点（也称为具有主节点的仲裁）。如果不满足上述任一条件，数据库将进入只读模式以防止数据损坏。有关 Vertica 如何维护数据完整性的详细信息，请参阅 Eon 模式数据库中的数据完整性和高可用性。
当确定数据库是否具有分片覆盖率或节点仲裁时，Vertica 不考虑辅助节点。这一事实使得辅助子群集非常适合管理您计划动态扩展和减少的节点组。您可以停止或移除辅助节点的整个子群集，而无需强制数据库进入只读模式。
K-safe 数据库的最小子群集大小
在 K-safe 数据库中，子群集必须至少具有三个节点才能运行。每个子群集都尝试维护对数据库中所有分片的订阅。如果一个子群集的节点少于三个，则它无法保持冗余分片覆盖率，其中每个分片在子群集中至少有两个订户。如果没有冗余覆盖，子群集在丢失节点时将无法继续处理查询。如果您尝试在 K-safe 数据库中具有三个以下节点的子群集中重新平衡分片，Vertica 会返回错误。
另请参阅
4 - 弹性
弹性是指通过添加或移除节点来调整数据库适应不断变化的工作负载需求的能力。当数据库遇到高需求时，可以添加新节点或启动已停止的节点，以增加可用的计算量。当数据库遇到较低需求时（例如在节假日或周末），可以停止或终止节点以节省资金。还可以随着数据库需求的增长而逐渐添加节点。
Eon 模式数据库中的所有节点都属于一个子群集。通过选择哪些子群集获得新节点，可以影响新节点对数据库的影响。将节点添加到数据库时，可以实现两个目标：
-
提高查询吞吐量：更高的吞吐量意味着数据库同时处理更多查询。当您有“仪表板查询”（许多运行时间相对较短的查询）工作负载时，您通常希望提高吞吐量。在这种情况下，加快单个查询的处理速度不如让更多查询并行运行重要。
-
提高查询性能：更高的查询性能意味着复杂的深入分析查询完成得更快。
针对查询吞吐量进行扩展
要针对查询吞吐量进行扩展，请在一个或多个新 子群集中向数据库添加额外的节点。子群集独立处理查询：查询仅在包含启动程序节点的子群集中的节点上运行。通过添加一个或多个子群集，数据库可以同时处理更多查询。为了获得最佳性能，请向每个新子群集中添加与数据库中的分片数量相同的节点数量。例如，如果数据库中有 6 个分片，则向您创建的每个新子群集中添加 6 个节点。
为了利用新子群集提供的更高吞吐量，客户端必须连接到它们。要确保用户利用您为扩展吞吐量而添加的子群集，最佳方法是创建连接负载均衡策略，将客户端连接分散到所有这些子群集中的所有节点上。有关详细信息，请参阅连接负载均衡策略。
子群集还将节点组织到可以轻松地一起停止或启动的组中。此功能使扩展和收缩数据库更加轻松。有关详细信息，请参阅启动和停止子群集。
针对查询性能进行扩展
要提高子群集中单个查询的性能，请向其中添加更多节点。当有更多的计算能力可用于处理查询时，查询的执行速度会更快。
如果子群集中的节点数少于数据库中的分片数，则添加节点特别有效。在这种情况下，节点负责处理多个分片中的数据。当添加更多节点时，新添加的节点会接管一些分片的责任。由于要处理的数据变少，因此每个节点可以更快地完成其查询部分，从而提高整体性能。为了获得最佳性能，请将子群集中的节点数设置为数据库中分片数的偶数除数（或等于分片数）。例如，在 12 分片数据库中，请将子群集中的节点数设置为 3、6 或 12。
您可以通过添加比数据库中的分片更多的节点来进一步提高查询性能。当节点数量超过分片数量时，子群集中的多个节点订阅同一个分片。在这种情况下，当处理查询时，Vertica 使用一种称为弹性处理扩展 (ECS) 的功能让子群集中的所有节点都参与查询。ECS 将每个分片中的数据子集分配给分片的订户。例如，在一个三分片数据库的六节点子群集中，每个分片有两个订户。在查询期间，ECS 为每个订户分配分片中一半的数据进行处理。在大多数情况下，由于要处理的数据更少，节点可以更快地完成查询的执行。当向子群集中添加比分片数更多的节点数时，请将节点数设置为分片数的倍数，以确保均匀分布。例如，在三分片数据库中，将子群集中的节点数设置为 6、9、12，依此类推。
对不同的查询类型使用不同的子群集
您不必在数据库中选择一种弹性形式，而舍弃另一种形式。您可以创建一组子群集用于提高查询吞吐量，并创建一个或多个子群集用于提高查询性能。两种子群集类型之间的区别主要在于您创建的子群集数以及它们包含的节点数。要提高吞吐量，请添加多个子群集，其中包含的节点数等于或小于数据库中的分片数。添加的子群集越多，实现的吞吐量就越大。要提高查询性能，请添加一个或多个子群集，其中节点数是数据库中分片数的倍数。
创建一组子群集后，必须根据将运行的查询类型，让客户端连接到正确的子群集。对于频繁执行简单仪表板查询的客户端，请创建一个连接负载均衡策略，以将客户端连接到吞吐量扩展子群集中的节点。对于运行更复杂分析查询的客户端，请创建另一个负载均衡策略，以将客户端连接到性能扩展子群集中的节点。
有关扩展 Eon 模式数据库的详细信息，请参阅扩展 Eon 模式数据库。
5 - Eon 模式数据库中的数据完整性和高可用性
Eon 模式数据库的 主子群集中的节点负责维护数据库中的数据。这些节点（统称为数据库的 主节点）计划用于管理分片中数据的 Tuple Mover 合并操作。如果它们是执行这些操作的最佳候选者，它们也可以执行这些操作（请参阅 Eon 模式数据库中的 Tuple Mover）。
主节点可以分布在多个主子群集中 - 它们一起协同工作以维护分片中的数据。主节点的运行状况是数据库继续正常运行的关键。
辅助子群集中的节点不计划 Tuple Mover 操作。如果主节点将 Tuple Mover 分配给它们，它们也可以执行 Tuple Mover 合并操作。您的数据库群集可能会丢失其所有辅助节点，但仍会维护分片中的数据。
维护数据完整性是数据库的首要目标。如果数据库丢失了太多主节点，将无法安全地处理数据。在这种情况下，它会进入只读模式，以防止数据不一致或损坏。
高可用性（即使个别节点丢失，数据库也能继续运行）是 Vertica 的另一个目标。它具有多种冗余功能，可帮助其防止停机。启用这些功能后，即使数据库丢失一个或多个主节点，它仍会继续运行。
数据库继续正常运行有两个要求：维护仲裁和维护分片覆盖率。
维护仲裁
对于 Eon 模式数据库中的主节点，基本要求是维护主节点的 仲裁始终运行。为了维护仲裁，必须有一半以上的主节点（50% 加 1）处于运行状态。例如，在具有 6 个主节点的数据库中，必须至少有 4 个主节点处于运行状态。如果一半或更多主节点关闭，数据库将进入只读模式，以防止潜在的数据完整性问题。在具有 6 个主节点的数据库中，如果数据库丢失 3 个或更多主节点，则数据库将进入只读状态。请参阅下面的只读模式。
Vertica 在确定数据库是否具有仲裁时，仅对当前属于数据库的主节点进行计数。移除主节点不会导致仲裁丢失。在移除过程中，Vertica 会调整节点计数以防止丢失仲裁。
Eon 模式数据库必须至少有一个主节点才能运行。在大多数情况下，它需要多个主节点。请参阅下面的 Eon 模式数据库操作的最低节点要求。
维护分片覆盖率
为了继续处理数据，数据库必须能够维护其分片中的数据。要维护数据，每个分片必须有一个订阅主节点，负责在其上运行 Tuple Mover。此要求称为具有分片覆盖率。如果一个或多个分片没有主节点维护其数据，则数据库将丢失分片覆盖率并进入只读模式（如下所述），以防止可能出现数据完整性问题。
衡量 Eon 模式数据库对主节点丢失有多大弹性的度量指标称为 K-safety 级别。K 值是 Eon 模式数据库群集维护的冗余分片订阅数。它还表示数据库中可以发生故障但仍能够安全运行的主节点的数量。在许多情况下，数据库可能会丢失超过 K 个节点，但仍然可以继续正常运行，只要它维护分片覆盖率。
Vertica 建议始终将数据库的 K-safety 值设置为 1 (K=1)。在 K=1 的数据库中，每个分片都有两个订户：一个负责分片的主订户，另一个是在主订户丢失时可以补位的辅助订户。主订户负责对分片中的数据运行 Tuple Mover。辅助订户维护分片编录元数据的副本。以便在主订户丢失时可以补位。
如果分片的主订户失败，则辅助订户会补位主订户。因为它没有为其辅助订阅维护单独的存储库，所以辅助订户始终直接访问公共存储中的分片数据。在辅助订户补位主订户时，这种直接访问会影响数据库的性能。因此，请始终尽快重新启动或替换已关闭的主节点。
对于 K=1 数据库中的主订户和辅助订户，丢失单个主节点不会影响数据库处理和维护数据的能力。但是，如果辅助订户在补位主订户时失败，则数据库将丢失分片覆盖率，并被迫进入只读模式。
弹性 K-safety
Vertica 使用一种称为弹性 K-safety 的功能来帮助限制分片覆盖率丢失的可能性。默认情况下，如果分片的主订户或辅助订户失败，Vertica 会为该分片订阅一个额外的主节点。建立此订阅需要一些时间，因为新订阅的节点必须获取分片元数据的副本。如果分片的唯一订户在新订户获取分片元数据时失败，则数据库将丢失分片覆盖率并可能关闭。一旦新订阅的节点获得元数据的副本，它就能够在另一个订户失败时接管分片的维护。此时，您的数据库再次拥有两个分片订户。
一旦关闭的节点恢复并重新加入子群集，Vertica 便会移除它为弹性 K-safety 添加的订阅。所有节点重新加入群集后，分片订阅将与节点丢失之前相同。
借助弹性 K-safety，您的数据库便可以在逐渐丢失主节点直至丢失仲裁的过程中设法维护分片覆盖率。只要新订阅的节点有足够的时间收集分片的元数据，您的数据库便能够维护分片覆盖率。但是，如果在新的主节点完成订阅分片的过程之前，数据库失去了分片的主订户和辅助订户，那么数据库仍然可能由于分片覆盖率丢失而被迫进入只读模式。
注意
当数据库即将丢失仲裁时，Vertica 会停止添加新订阅。如果群集有超过 N ÷ 2 + K + 1 个主节点正在运行（其中 N 是数据库中的主节点总数），它会继续添加新订阅。例如，如果 K=1 数据库中有 10 个主节点，只要正在运行的主节点数大于 7 (10 ÷ 2 + 1 + 1)，Vertica 便会添加新订阅。如果此数据库中正在运行的主节点数降至 6，则添加额外的订阅将没有意义。再失去一个主节点将迫使数据库由于丢失仲裁而关闭。数据库只读模式
如果数据库丢失仲裁或主分片覆盖率，它将进入只读模式。此模式可防止当太多节点关闭或无法访问数据库中的其他节点时可能导致的潜在数据损坏。只读模式可防止对数据库进行需要更新全局编录的更改。
只读模式下的 DML 和 DDL
在只读模式下，更改全局编录的语句（例如大多数 DML 和 DDL 语句）会失败，并显示错误消息。例如，当数据库处于只读模式时执行 CREATE TABLE 等 DDL 语句会导致以下错误：
=> CREATE TABLE t (a INTEGER, b VARCHAR);
ERROR 10428: Transaction commit aborted since the database is currently in read-only mode
HINT: Commits will be restored when the database restores the quorum
COPY 等 DML 语句返回不同的错误。Vertica 会在它们执行任何工作之前停止它们的执行：
=> COPY warehouse_dimension from stdin;
ERROR 10422: Running DML statements is not possible in read-only mode
HINT: Running DMLs will be restored when the database restores the quorum
通过提前返回错误，Vertica 可避免执行加载数据所需的所有工作，在尝试提交事务时便会失败。
不影响全局编录的 DDL 和 DML 语句仍然有效。例如，在数据库处于只读模式时，可以创建一个本地临时表并将数据加载到其中。
只读模式下的查询
查询可以在具有分片覆盖率的任何子群集上运行。例如，假设您有一个 Eon 模式数据库，其中包含一个 3 节点主子群集和一个 3 节点辅助子群集。如果两个主节点出现故障，数据库将丢失仲裁并进入只读模式。主子群集也会丢失分片覆盖率，因为它的两个节点已关闭。剩余的一个节点没有订阅至少部分分片。在这种情况下，剩余主节点上的查询（某些系统表查询除外）始终会失败：
=> SELECT * FROM warehouse_dimension;
ERROR 9099: Cannot find participating nodes to run the query
辅助子群集仍然具有分片覆盖率，因此可以对其执行查询。
监控只读模式
除了注意到 DML 和 DDL 语句返回错误之外，还可以通过监控系统表来确定数据库是否已进入只读模式：
-
NODES 系统表具有一个名为 is_readonly 的列，当数据库处于只读模式时，该列对所有节点都变为 true。
=> SELECT node_name, node_state, is_primary, is_readonly, subcluster_name FROM nodes; node_name | node_state | is_primary | is_readonly | subcluster_name ----------------------+------------+------------+-------------+-------------------- v_verticadb_node0001 | UP | t | t | default_subcluster v_verticadb_node0002 | DOWN | t | t | default_subcluster v_verticadb_node0003 | DOWN | t | t | default_subcluster v_verticadb_node0004 | UP | f | t | analytics v_verticadb_node0005 | UP | f | t | analytics v_verticadb_node0006 | UP | f | t | analytics (6 rows) -
当数据库进入只读模式时，数据库中仍在运行的每个节点都会记录一个群集只读事件（事件代码 20）。您可以通过查询事件监控系统表（例如 ACTIVE_EVENTS）找到这些事件：
=> \x Expanded display is on. => SELECT * FROM ACTIVE_EVENTS WHERE event_code = 20; -[ RECORD 1 ]-------------+-------------------------------------------------------------------------- node_name | v_verticadb_node0001 event_code | 20 event_id | 0 event_severity | Critical event_posted_timestamp | 2021-11-22 15:57:24.514475+00 event_expiration | 2089-12-10 19:11:31.514475+00 event_code_description | Cluster Read-only event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried reporting_node | v_verticadb_node0001 event_sent_to_channels | Vertica Log event_posted_count | 1 -[ RECORD 2 ]-------------+-------------------------------------------------------------------------- node_name | v_verticadb_node0004 event_code | 20 event_id | 0 event_severity | Critical event_posted_timestamp | 2021-11-22 15:57:24.515022+00 event_expiration | 2089-12-10 19:11:31.515022+00 event_code_description | Cluster Read-only event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried reporting_node | v_verticadb_node0004 event_sent_to_channels | Vertica Log event_posted_count | 1 -[ RECORD 3 ]-------------+-------------------------------------------------------------------------- node_name | v_verticadb_node0005 event_code | 20 event_id | 0 event_severity | Critical event_posted_timestamp | 2021-11-22 15:57:24.515019+00 event_expiration | 2089-12-10 19:11:31.515019+00 event_code_description | Cluster Read-only event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried reporting_node | v_verticadb_node0005 event_sent_to_channels | Vertica Log event_posted_count | 1 -[ RECORD 4 ]-------------+-------------------------------------------------------------------------- node_name | v_verticadb_node0006 event_code | 20 event_id | 0 event_severity | Critical event_posted_timestamp | 2021-11-22 15:57:24.515172+00 event_expiration | 2089-12-10 19:11:31.515172+00 event_code_description | Cluster Read-only event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried reporting_node | v_verticadb_node0006 event_sent_to_channels | Vertica Log event_posted_count | 1请参阅监控事件。
从只读模式恢复
要从只读模式恢复，请重新启动关闭的节点。重新启动节点即可解决导致数据库进入只读模式的仲裁丢失或主分片覆盖率丢失的问题。
一旦关闭的节点重新启动并重新加入数据库，Vertica 便会在处于只读模式的节点上重新启动。为了让节点能够重新订阅其分片，必须执行此步骤。在此重新启动期间，与这些节点的客户端连接将断开。例如，通过 vsql 连接到 Vertica 正在重新启动的节点之一的用户会看到以下消息：
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
在 Vertica 重新启动时，使用 vsql 连接到节点的用户会看到以下消息：
vsql: FATAL 4149: Node startup/recovery in progress. Not yet ready
to accept connections
Vertica 在节点上重新启动后，数据库将恢复正常运行。
当 Vertica 在 Eon 模式数据库中设置 K-safety 值时
当您的数据库中有三个或更多主节点时，Vertica 会自动将数据库的 K-safety 设置为 1 (K=1)。它还会自动配置分片订阅，以便每个节点都可以充当另一个节点的备份，如维护分片覆盖率中所述。
此行为与企业模式数据库不同，在企业模式数据库中，您必须设计数据库的物理架构以满足多个标准，然后才能让 Vertica 将数据库标记为 K-safe。有关详细信息，请参阅下面的企业模式和 Eon 模式 K-safe 设计之间的差异。
注意
少于三个主节点的数据库没有数据冗余 (K=0)。Vertica 建议您仅使用少于三个主节点的数据库进行测试。Eon 模式数据库操作的最低节点要求
数据库的 K-safety 级别决定了它必须具有的最小主节点数：
- 当 K=0 时，数据库必须至少具有 1 个主节点。将 K 设置为 0 允许您拥有单节点 Eon 模式数据库。请注意，在 K=0 数据库中，主节点丢失将导致数据库进入只读模式。
- 当 K=1（最常见的情况）时，数据库必须至少具有三个主节点。此数量的主节点让 Vertica 能够在主节点出现故障时维护数据完整性。
- 如果要手动将 K-safe 值设置为 2（请参阅下面的企业模式和 Eon 模式 K-safe 设计之间的差异），则必须至少具有 5 个主节点。
如果群集将会低于数据库 K-safety 设置的下限，Vertica 会阻止您移除主节点。如果要移除处于此下限的数据库中的节点，则必须使用 MARK_DESIGN_KSAFE 函数降低 K-safety 级别，然后调用 REBALANCE_SHARDS。
关键节点和子群集
Vertica 将数据库中丢失便会导致数据库进入只读模式的任何节点或子群集指定为关键节点或子群集。例如，在 Eon 模式数据库中，当主节点出现故障时，对其分片具有辅助订阅的节点将接管分片的数据维护。这些节点变为关键节点。它们的丢失将导致数据库丢失分片覆盖率，并被迫进入只读模式。
注意
启用弹性 K-safety（这是默认设置）时，Vertica 会为故障主节点的分片订阅其他主节点。在这些节点通过获取分片元数据的副本完成订阅后，如果辅助订户也出现故障，它们就可以补位。发生这种情况时，补位故障节点的节点不再被视为关键节点。Vertica 在两个系统表中维护关键节点和子群集列表： CRITICAL_NODES 和 CRITICAL_SUBCLUSTERS。在停止节点或子群集之前，请检查这两个表以确保要停止的节点或子群集不是关键节点或子群集。
企业模式和 Eon 模式 K-safe 设计之间的差异
在企业模式数据库中，可以使用 MARK_DESIGN_KSAFE 函数在数据库中启用高可用性。在设计了数据库的物理架构以满足 K-safe 设计的所有要求（通常，通过运行 Database Designer）之后，便可以调用此函数。如果在物理架构不支持传递给 MARK_DESIGN_KSAFE 的 K-safety 级别时尝试将数据库标记为 K-safe，则会返回错误。有关详细信息，请参阅为 K-safety 安全设计分段投影。
在 Eon 模式下，您不需要使用 MARK_DESIGN_KSAFE，因为当您具有三个或更多主节点时，Vertica 会自动将数据库设置为 K-safe。您可以使用此函数更改数据库的 K-safety 级别。在 Eon 模式数据库中，此函数更改 Vertica 配置分片订阅的方式。您可以使用所需的任何 K-safety 级别调用 MARK_DESIGN_KSAFE。仅当您调用 REBALANCE_SHARDS 来更新数据库中节点的分片订阅时，它才会生效。
注意
通常，在基于云的 Eon Mode 数据库中，不使用大于 1 的 K-safety 值。在云环境中，可以轻松地将替换节点添加到群集。6 - 停止、启动、终止和恢复 Eon 模式数据库群集
如果您在一段时间内不需要 Eon 模式数据库，则可以选择停止或终止其群集。当在云环境中运行时，停止或终止群集可以为您节省资金。
停止和启动数据库群集
当您停止数据库群集时，会关闭群集中的节点。关闭群集是除了仅关闭数据库之外的额外步骤。当您在云环境中关闭群集时，节点的实例不再运行，但仍在云平台中定义。当需要再次使用群集和数据库时，可以快速重新启动它。
当您在中短期内不需要数据库群集时，停止它是最好的选择。例如，如果在周末或节假日没有人访问您的数据库，则可以考虑停止群集。
当在云环境中关闭数据库群集时，可以节省资金。停止的群集不会消耗昂贵的 CPU 资源。但是，停止的群集仍然会花费您的资金。如果您为节点配置了永久性本地存储，您的云提供商通常仍会收取少量费用来维护该存储空间。
终止和恢复数据库群集
终止数据库群集会释放数据库群集节点使用的资源。
在云平台上，终止数据库群集会删除节点的虚拟机实例。数据库的数据和编录仍然存储在公共存储中。您可以通过恢复数据库来重新启动它。当恢复数据库时，您需要配置一个新的数据库群集，并将其配置为使用存储在公共存储中的数据库数据和元数据。
在内部部署 Eon 模式数据库中，终止数据库群集通常意味着关闭数据库，然后重新调整运行节点的硬件的用途。
当您长时间不需要数据库时（或者如果您不确定是否会再次需要数据库），终止数据库群集是最佳选择。只要您不删除公共存储位置，您就可以通过恢复数据库来让它再次运行。
要恢复数据库，您需要创建一个新的 Vertica Eon 模式群集，并将其配置为使用数据库的公共存储位置。在云中恢复数据库的最简单方法是，使用管理控制台。它可以为您配置一个新的 Eon 模式群集，然后在其中恢复数据库。
恢复数据库比启动停止的数据库需要更长的时间。即使您使用 MC 自动执行该过程，配置一组新节点所需的时间也比重新启动停止的节点要长得多。当新节点首次启动时，它们必须从头开始从公共存储中加载数据。
当数据库的节点具有永久性本地存储时，终止数据库群集可以比简单地停止数据库节省更多资金。云提供商通常会针对节点上的永久性本地存储所占用的空间向您收取少量经常性费用。