调整集群大小 - Amazon Redshift
弹性调整大小经典调整大小

调整集群大小

随着您的数据仓库容量和性能需求的变化，您可以调整集群大小，以便充分利用 Amazon Redshift 的计算和存储选项。

调整大小操作有两种类型：

  • 弹性调整大小：您可以向集群添加节点，或从集群中移除节点。您还可以更改节点类型，如从 DS2 节点更改为 RA3 节点。弹性调整大小通常会很快完成，平均约需十分钟。因此，我们建议将其作为首选项。当您执行弹性调整大小时，它会重新分发数据切片，这些数据切片是在每个节点中分配内存和磁盘空间的分区。弹性调整大小适用于以下情况：

    • 增加或减少现有集群中的节点，但不更改节点类型：这通常被称为就地调整大小。当您执行这种调整大小时，一些正在运行的查询会成功完成，但其他查询可能会作为该操作的组成部分而被删除。

    • 更改集群的节点类型：当您更改节点类型时，将创建快照，并将数据从源集群重新分发到由新节点类型组成的集群。完成后，将删除正在运行的查询。与就地调整大小一样，它很快即可完成。

  • 经典调整大小：您可以更改节点类型、节点数量或此两者，其方式与弹性调整大小相似。经典调整大小需要更多时间才能完成，但在节点计数发生变化或要迁移到的节点类型不在弹性调整大小范围内的情况下，它会很有用。例如，当节点计数的变化非常大时，此调整大小类型可能适用。

弹性调整大小

当您添加或移除相同类型的节点时，弹性调整大小操作包括以下阶段：

  1. 弹性调整大小操作将为集群制作快照。此快照始终包括节点的无备份表（如果适用）。（某些节点类型（如 RA3）没有无备份表。） 如果您的集群因禁用了自动快照而没有最近的快照，则备份操作可能会花费更长时间。（要最大程度地减少调整大小操作开始前的时间，我们建议您在开始调整大小操作之前启用自动快照或创建手动快照。） 如果在您启动弹性调整大小时，系统正在执行快照操作，若该快照操作未能在数分钟内完成，则调整大小可能会失败。有关更多信息，请参阅 Amazon Redshift 快照和备份。

  2. 该操作将迁移集群元数据。集群将在数分钟内不可用。大多数查询将暂停，并且连接将保持打开状态。但是，某些查询可能会被删除。此阶段很短。

  3. 会话连接将恢复，并且查询将继续。

  4. 弹性调整大小操作会在后台将数据重新分发到节点切片。集群可用于读取和写入操作，但是某些查询可能需要更长的时间来运行。

  5. 在该操作完成后，Amazon Redshift 会发送一个事件通知。

当您使用弹性调整大小来更改节点类型时，它的工作方式与您增加或减少相同类型的节点时相似。首先，创建一个快照。使用该快照中的最新数据预调配新的目标集群，并在后台将数据传输到新集群。在此期间，数据是只读的。在大小调整接近完成时，Amazon Redshift 会将端点更新为指向新集群，并断开与源集群的所有连接。

弹性调整大小操作不太可能失败。但如果失败，在大多数情况下会自动进行回滚，无需任何手动干预。

如果您有预留节点，例如 DS2 预留节点，则您可以在执行调整大小时升级到 RA3 预留节点。您可以在执行弹性调整大小或者使用控制台从快照还原时执行此操作。控制台将引导您完成此过程。有关升级到 RA3 节点的更多信息，请参阅升级到 RA3 节点类型。

弹性调整大小操作不会对表进行排序或回收磁盘空间，因此，它不能替代 vacuum 操作。有关更多信息，请参阅对表执行 vacuum 操作。

弹性调整大小操作具有以下限制：

  • 弹性大小调整和数据共享集群 - 如果您在作为数据共享创建者的集群上添加或缩减节点，则当 Amazon Redshift 迁移集群元数据时，您无法从使用者连接到该集群。同样，如果您执行弹性大小调整并选择新的节点类型，则当连接断开并转移到新的目标集群时，数据共享将不可用。在这两种类型的弹性大小调整中，创建者会有几分钟时间不可用。

  • 从共享快照传输数据：要在从共享快照传输数据的集群上运行弹性调整大小，必须至少有一个备份可供该集群使用。您可以在 Amazon Redshift 控制台快照列表中或通过 describe-cluster-snapshots CLI 命令或 DescribeClusterSnapshots API 操作查看备份。

  • 平台限制：弹性调整大小仅可用于使用 EC2-VPC 平台的集群。有关更多信息，请参阅 在创建集群时使用 EC2-VPC。

  • 存储注意事项：确保新的节点配置有足够的存储空间来存储现有数据。您可能需要添加其他节点或更改配置。

  • 源与目标集群大小 – 可以通过弹性调整大小来调整大小的节点的数量和节点类型由源集群中的节点的数量和为已调整大小的集群所选的节点类型来确定。可以使用控制台确定可能的配置。您也可以运行带 action-type resize-cluster 选项的 describe-node-configuration-options AWS CLI 命令。有关使用 Amazon Redshift 控制台进行大小调整的更多信息，请参阅调整集群大小。

    以下示例 CLI 命令描述了可用的配置选项。在此示例中，名为 mycluster 的集群是一个 8 节点的 dc2.large 集群。

    aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster

    此命令会返回一个选项列表，包括每个选项的建议节点类型、节点数和磁盘利用率。返回的配置根据特定的输入集群而不同。指定 resize-cluster CLI 命令的选项时，可以选择其中一种返回的配置。

  • 其他节点的上限：弹性调整大小对您可以添加到集群的节点有限制。例如，dc2 集群支持弹性调整大小，最大可将节点数量增加一倍。为了说明，您可以将一个节点添加到 4 节点 dc2.8xlarge 集群中，使其成为 5 节点集群，或者添加更多节点，直到达到 8 个为止。

    注意

    增长和减少限制基于原始节点类型，以及原始集群中的节点数量或其上次经典大小调整。如果弹性调整大小将超过增长或减少限制，则使用经典大小调整。

    使用某些 ra3 节点类型，您最多可以将节点数增加到现有计数的四倍。具体来说，假设您的集群由 ra3.4xlarge 或 ra3.16xlarge 节点组成。然后，您可以使用弹性调整大小将 8 节点集群中的节点数增加到 32。或者，您可以选择低于限制的值。（请记住，将集群增长 4 倍的能力取决于源集群的大小。） 如果您的集群具有 ra3.xlplus 节点，则限制为双倍。

    所有 ra3 节点类型都支持将节点数减少到现有计数的四分之一。例如，您可以将包含 ra3.4xlarge 节点的集群的大小从 12 个节点减少到 3 个节点，或者减少到高于最小值的数字。

    下表列出了支持弹性调整大小的每个节点类型的增长和减少限制。

    原始节点类型 增长限制 减少限制

    ra3.16xlarge

    		 4 倍（例如，从 4 个节点到 16 个节点）

    到数量的四分之一（例如，从 16 个节点到 4 个节点）

    ra3.4xlarge

    4 倍

    		 到数量的四分之一

    ra3.xlplus

    2 倍（例如，从 4 个节点到 8 个节点）

    到数量的四分之一

    dc2.8xlarge

    2 倍

    到数量的一半（例如，从 16 个节点到 8 个节点）

    dc2.large

    2 倍

    到数量的一半

    ds2.8xlarge

    2 倍

    到数量的一半

    ds2.xlarge

    2 倍

    到数量的一半
    注意

    调整 RA3 集群大小时选择传统节点类型 – 如果您尝试将包含 RA3 节点的集群的大小调整为另一种节点类型，例如 DC2 或 DS2，则控制台中会显示一条验证警告消息，调整大小操作将无法完成。之所以会出现这种情况，是因为不支持将大小调整为传统节点类型。这是为了防止客户将大小调整为已过时或即将弃用的节点类型。这同时适用于弹性大小调整和经典大小调整。

经典调整大小

经典调整大小操作用于处理集群大小或节点类型的更改不受弹性调整大小支持的应用场景。当您执行经典调整大小时，Amazon Redshift 会创建一个目标集群，并将您的数据和元数据从源集群迁移到该集群。

对 RA3 进行经典调整大小可以提供更好的可用性

当目标节点类型为 RA3 时，经典调整大小功能已得到增强。它通过在源集群与目标集群之间使用备份和还原操作来实现这一目标。开始调整大小时，源集群将重新启动并在数分钟内不可用。在此之后，集群可用于读取和写入操作，同时继续在后台调整大小。

检查集群

为确保在对 RA3 集群执行经典调整大小时获得最佳性能和结果，请完成此清单。如果您不遵循检查表，则可能无法获得使用 RA3 节点进行经典调整大小的一些好处，例如可以执行读写操作。

  1. 数据的大小必须小于 2 PB。（1 PB 等于 1000 TB。） 要验证数据的大小，请创建快照并检查其大小。您还可以运行以下查询来检查大小：

    SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;

    svv_table_info 表仅对超级用户可见。

  2. 在发起经典调整大小操作之前，请确保您拥有的手动快照是新鲜的，未久于 10 个小时。否则，请创建快照。

  3. 用于执行经典调整大小的快照不能用于表还原或其他用途。

  4. 集群必须位于 VPC 中。

对 RA3 进行经典调整大小产生的排序和分配操作

在对 RA3 进行经典大小调整期间，对于具有 KEY 分配但以 EVEN 分配方式迁移的表，会将其转换回其原始分配方式。此过程的持续时间取决于数据的大小和集群的繁忙程度。为查询工作负载分配更高的优先级，使其优先于数据迁移。有关更多信息，请参阅分配方式。在此迁移过程中，数据库可以读取和写入，但查询可能需要更长的时间才能完成。但在此期间，并发扩展可以通过为查询工作负载添加资源来提升性能。您可以查看 SYS_RESTORE_STATE 和 SYS_RESTORE_LOG 视图的结果来了解数据迁移的进度。有关监控的更多信息如下所示。

完全调整集群大小后，会出现以下排序行为：

  • 如果调整大小导致集群有更多切片，则 KEY 分配的表将变为部分未排序状态，但 EVEN 分配的表将保持已排序状态。此外，调整大小之后立即显示的已排序数据量信息可能不是最新的。恢复密钥后，自动 vacuum 会随着时间的推移对表进行排序。

  • 如果调整大小导致集群拥有的切片减少，则 KEY 分配的表和 EVEN 分配的表都将变为部分未排序状态。自动 vacuum 会随着时间的推移对表进行排序。

有关自动表 vacuum 的更多信息，请参阅对表执行 vacuum 操作。有关计算节点中的切片的更多信息，请参阅数据仓库系统架构。

目标集群为 RA3 时的经典调整大小步骤

当目标集群类型为 RA3 并且您已满足上一节中详述的先决条件时，经典调整大小包含以下步骤。

  1. 从源集群发起到目标集群的迁移。当预调配新的目标集群时，Amazon Redshift 发送一个事件通知，告知大小调整已开始。它会重新启动现有集群，这会关闭所有连接。如果您的现有集群是数据共享创建者集群，则与使用者集群的连接也会关闭。重新启动需要几分钟时间。

    请注意，在经典调整大小期间，不会保留使用 BACKUP NO 创建的任何数据库关系，例如表或实体化视图。有关更多信息，请参阅 CREATE MATERIALIZED VIEW。

  2. 重新启动后，数据库可用于读取和写入。此外，数据共享恢复，这又需要几分钟的时间。

  3. 数据迁移到目标集群。当目标节点类型为 RA3 时，在数据迁移期间可以进行读取和写入。

  4. 在调整大小过程即将完成时，Amazon Redshift 会将端点更新到目标集群，并将删除与源集群的所有连接。目标集群成为数据共享的创建者。

  5. 调整大小的过程完成。Amazon Redshift 发送事件通知。

您可以在 Amazon Redshift 控制台上查看调整大小的进度。调整集群大小所用的时间取决于数据量。

注意

调整 RA3 集群大小时选择传统节点类型 – 如果您尝试将包含 RA3 节点的集群的大小调整为另一种节点类型，例如 DC2 或 DS2，则控制台中会显示一条验证警告消息，调整大小操作将无法完成。之所以会出现这种情况，是因为不支持将大小调整为传统节点类型。这是为了防止客户将大小调整为已过时或即将弃用的节点类型。这同时适用于弹性大小调整和经典大小调整。

当目标集群为 RA3 时监控经典调整大小

要监控预置集群正在进行的经典调整大小，包括 KEY 分配，请使用 SYS_RESTORE_STATE。它显示了正在转换的表的完成百分比。您必须是超级用户才能访问数据。

删除在执行经典调整大小时不需要的表。这样做时，可以更快地分配现有的表。

目标集群不是 RA3 时的经典调整大小步骤

当目标节点类型为 RA3 以外的任何类型（例如 DS2）时，经典调整大小包含以下步骤。

  1. 从源集群发起到目标集群的迁移。当预调配新的目标集群时，Amazon Redshift 发送一个事件通知，告知大小调整已开始。它会重新启动现有集群，这会关闭所有连接。如果您的现有集群是数据共享创建者集群，则与使用者集群的连接也会关闭。重新启动需要几分钟时间。

    请注意，在经典调整大小期间，不会保留使用 BACKUP NO 创建的任何数据库关系，例如表或实体化视图。有关更多信息，请参阅 CREATE MATERIALIZED VIEW。

  2. 重新启动后，数据库以只读形式可用。数据共享恢复，这又需要几分钟的时间。

  3. 数据迁移到目标集群。数据库保持只读状态。

  4. 在调整大小过程即将完成时，Amazon Redshift 会将端点更新到目标集群，并将删除与源集群的所有连接。目标集群成为数据共享的创建者。

  5. 调整大小的过程完成。Amazon Redshift 发送事件通知。

您可以在 Amazon Redshift 控制台上查看调整大小的进度。调整集群大小所用的时间取决于数据量。

注意

如果目标集群不是 RA3，或者它不符合上一节中详述的 RA3 目标集群的先决条件，则可能需要几天甚至几周的时间才能调整包含大量数据的集群的大小。

另请注意，在进行了经典调整大小后，集群的已用存储容量可能会增加。当集群有由于经典调整大小而产生的额外数据切片时，这是正常的系统行为。即使集群中的节点数量保持不变，也可能会发生这种使用额外容量的情况。

弹性调整大小与经典调整大小的对比

下表对比了两种调整大小类型之间的行为。

弹性调整大小与经典调整大小的对比
行为 弹性调整大小 经典调整大小 注释
系统数据留存 弹性调整大小将保留系统日志数据。 经典调整大小不会保留系统表和数据。 如果您在源集群中启用了审计日志记录，则您可以在调整大小后继续访问 Amazon S3 或 CloudWatch 中的日志。您可以根据数据策略的规定保留或删除这些日志。
更改节点类型

当节点类型不变时弹性调整大小：就地调整大小，并将保留大多数查询。

在选择新节点类型的情况下弹性调整大小：将创建新集群。在调整大小过程完成后，将删除查询。

 经典调整大小：将创建新集群。在调整大小过程中将删除查询。
会话和查询留存 当源集群和目标集群中的节点类型相同时，弹性调整大小将保留会话和查询。如果您选择新的节点类型，则将删除查询。 经典调整大小不会保留会话和查询。将删除查询。 在删除查询后，预计会出现某种性能下降的情况。最好是在轻度使用期间执行调整大小操作。
取消调整大小操作

您无法取消弹性调整大小。

您可以在经典调整大小操作完成之前取消该操作，方法是在 Amazon Redshift 控制台中从集群详细信息中选择取消调整大小。

取消调整大小操作所需的时间取决于取消时调整大小操作所处的阶段。在取消操作完成前，如果您这样做，集群将不可用。如果调整大小操作处于最后阶段，您将无法取消。

对 RA3 集群进行经典调整大小时，您无法取消。

计划调整大小

您可以为集群制定调整大小操作计划，使其纵向扩展以满足预期高使用率的要求，或者缩减其规模以节约成本。计划适用于弹性调整大小和经典调整大小。您可以在 Amazon Redshift 控制台上设置计划。有关更多信息，请参阅使用控制台管理集群下的 调整集群大小。还可以使用 AWS CLI 或 Amazon Redshift API 操作来设置调整大小计划。有关更多信息，请参阅 AWS CLI 命令参考中的 create-scheduled-action 和 Amazon Redshift API 参考中的 CreateScheduledAction。

快照、还原和调整大小

弹性调整大小是调整 Amazon Redshift 集群大小的最快方法。如果弹性调整大小操作不适合您，并且您需要对集群进行近乎恒定的写入访问，则可以使用下一部分中所述的快照和还原操作以及经典调整大小。如果采用此方法，在切换后，您必须手动将在制作快照后写入源集群的所有数据都复制到目标集群中。根据复制用时，您可能需要重复执行此操作多次，直到两个集群中的数据相同。然后，您可以切换到目标集群。在目标集群拥有完整数据集之前，此过程可能会对现有查询产生负面影响。不过，它能最大程度地缩短您无法写入数据库的时间。

快照、还原和调整大小方法使用以下流程：

  1. 为您的现有集群制作快照。现有集群就是源集群。

  2. 记下制作快照的时间。这样做意味着，您稍后可确定需要重新运行提取、事务处理和加载 (ETL) 流程的时间点，从而将制作快照后写入的所有数据都加载到目标数据库中。

  3. 将快照还原到新集群中。这个新集群就是目标集群。验证目标集群中包含示例数据。

  4. 调整目标集群的大小。为目标集群选择新的节点类型、节点数和其他设置。

  5. 查看为源集群制作快照后通过 ETL 流程加载的数据。请确保按相同顺序将相同的数据重新加载到目标集群中。如果您的数据正在不断加载，请重复执行此流程多次，直到源集群和目标集群中的数据相同为止。

  6. 停止在源集群上运行的所有查询。为此，您可以重启集群，或以超级用户的身份登录并使用 PG_CANCEL_BACKEND 和 PG_TERMINATE_BACKEND 命令。重启集群是确保集群不可用的最简单方法。

  7. 重命名源集群。例如，将其从 examplecluster 重命名为 examplecluster-source。

  8. 重命名目标集群，使用源集群在重命名之前的名称。例如，将目标集群从之前的名称重命名为 examplecluster。此后，使用包含 examplecluster 的端点的所有应用程序都会连接到目标集群。

  9. 在切换到目标集群后删除源集群，并验证所有流程均可按预期正常工作。

或者，您可以在将数据重新加载到目标集群之前重命名源集群和目标集群。如果您不要求任何关联系统和报告立即与目标集群中的相应内容保持同步，则此方法有效。在这种情况下，步骤 6 将移至前述流程的最后。

仅当您希望应用程序继续使用相同的端点连接到集群时，才需要执行重命名流程。如果您没有此要求，则可以更新连接到集群的任何应用程序，以使用目标集群的端点，而无需重命名集群。

重新使用集群名称具有诸多优势。首先，您无需更新应用程序的连接字符串，因为端点始终保持不变，即使基础集群发生改变也是如此。其次，相关项（例如 Amazon CloudWatch 警报和 Amazon Simple Notification Service (Amazon SNS) 通知）与集群名称相关联。这种关联意味着，您可以继续使用已为集群设置的相同警报和通知。在您希望灵活调整集群大小而无需重新配置相关项目（如警报和通知）的生产环境中，继续使用集群名称关系重大。