将全局表从旧版(2017.11.29)升级为当前版(2019.11.21) - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

将全局表从旧版(2017.11.29)升级为当前版(2019.11.21)

DynamoDB 全局表有两个版本:全局表版本 2019.11.21(当前版)全局表版本 2017.11.29(旧版)。客户应尽可能使用版本 2019.11.21(当前版),因为与 2017.11.29(旧版)相比,它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。要确定您所使用的版本,请参阅确定您正在使用的全局表版本

本部分介绍如何使用 DynamoDB 控制台将全局表升级为版本 2019.11.21(当前版)。从版本 2017.11.29(旧版)升级为版本 2019.11.21(当前版)是一次性操作,无法撤销。目前,只能使用控制台升级全局表。

旧版与当前版之间的行为差异

以下列表介绍了全局表的旧版和当前版之间的行为差异。

  • 与版本 2017.11.29(旧版)相比,版本 2019.11.21(当前版)在执行某些 DynamoDB 操作时消耗的写入容量更少,因此,对于大部分客户而言,更具有成本效益。这些 DynamoDB 操作的差异如下:

    • 在 2017.11.29(旧版)中,针对一个区域的 1 KB 项目调用 PutItem,然后复制到其它区域时,每个区域需要 2 个 rWRU;但在 2019.11.21(当前版)中,仅需要 1 个 rWRU。

    • 在 2017.11.29(旧版)中,针对 1 KB 项目调用 UpdateItem 时,源区域需要 2 个 rWRU,每个目标区域需要 1 个 rWRU,但在 2019.11.21(当前版)中,源区域和目标区域都只需要 1 个 rWRU。

    • 在 2017.11.29(旧版)中,针对 1 KB 项目调用 DeleteItem 时,源区域需要 1 个 rWRU,每个目标区域需要 2 个 rWRU,但在 2019.11.21(当前版)中,源区域或目标区域都只需要 1 个 rWRU。

    下表显示了 2017.11.29(旧版)和 2019.11.21(当前版)表的 rWRU 消耗量。

    针对两个区域中 1 KB 项目 2017.11.29(旧版)和 2019.11.21(当前版)表的 rWRU 消耗量
    操作 2017.11.29(旧版) 2019.11.21(当前版) 节省成本
    PutItem 4 个 rWRU 2 个 rWRU 50%
    UpdateItem 3 个 rWRU 2 个 rWRU 33%
    DeleteItem 3 个 rWRU 2 个 rWRU 33%
  • 版本 2017.11.29(旧版)仅在 11 个 Amazon Web Services 区域可用。但是,版本 2019.11.21(当前版)在所有 Amazon Web Services 区域都可用。

  • 要创建版本 2017.11.29(旧版)全局表,请首先创建一组空的区域表,然后调用 CreateGlobalTable API 来创建全局表。您可以通过调用 UpdateTable API 来将副本添加到现有区域表,以此创建版本 2019.11.21(当前版)全局表。

  • 版本 2017.11.29(旧版)要求您在新区域中添加副本之前(包括创建期间)清空表中的所有副本。版本 2019.11.21(当前版)支持您向区域已包含数据的表上添加和删除副本。

  • 版本 2017.11.29(旧版)通过以下一组专用的控制面板 API 来管理副本:

    版本 2019.11.21(当前版)使用 DescribeTableUpdateTable API 管理副本。

  • 版本 2017.11.29(旧版)针对每次写入操作发布两条 DynamoDB Streams 记录。版本 2019.11.21(当前版)针对每次写入操作仅发布一条 DynamoDB Streams 记录。

  • 版本 2017.11.29(旧版)填充并更新 aws:rep:deletingaws:rep:updateregionaws:rep:updatetime 属性。版本 2019.11.21(当前版)则不填充或更新这些属性。

  • 版本 2017.11.29(旧版)不在副本间同步 生存时间 (TTL) 设置。版本 2019.11.21(当前版)在副本间同步 TTL 设置。

  • 版本 2017.11.29(旧版)不将 TTL 删除操作复制到其它副本。版本 2019.11.21(当前版)会将 TTL 删除操作复制到所有副本。

  • 版本 2017.11.29(旧版)不在副本间同步自动扩缩设置。版本 2019.11.21(当前版)会在副本间同步自动扩缩设置。

  • 版本 2017.11.29(旧版)不在副本间同步全局二级索引(GSI)设置。版本 2019.11.21(当前版)在副本间同步 GSI 设置。

  • 版本 2017.11.29(旧版)不在副本间同步静态加密设置。版本 2019.11.21(当前版)在副本间同步静态加密设置。

  • 版本 2017.11.29(旧版)发布了 PendingReplicationCount 指标。版本 2019.11.21(当前版)则未发布此指标。

升级先决条件

在开始升级为版本 2019.11.21(当前版)全局表之前,您必须满足以下先决条件:

  • 各区域副本间 生存时间 (TTL) 设置是一致的。

  • 各区域副本上的全局二级索引(GSI)定义是一致的。

  • 各区域副本间的静态加密设置是一致的。

  • 为所有副本的 WCU 启用 DynamoDB Auto Scaling,或为所有副本启用按需容量模式。

  • 应用程序不要求表项目中有 aws:rep:deletingaws:rep:updateregionaws:rep:updatetime 属性。

全局表升级所需的权限

要升级到版本 2019.11.21(当前版),您必须在包含副本的所有区域具有 dynamodb:UpdateGlobalTableVersion 权限。除了访问 DynamoDB 控制台和查看表所必需的权限之外,还需要这些权限。

下面的 IAM 策略授予将任何全局表升级到版本 2019.11.21(当前版)的权限。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "dynamodb:UpdateGlobalTableVersion", "Resource": "*" } ] }

下面的 IAM 策略授予仅将在两个区域中具有副本的 Music 全局表升级为版本 2019.11.21(当前版)的权限。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "dynamodb:UpdateGlobalTableVersion", "Resource": [ "arn:aws:dynamodb::123456789012:global-table/Music", "arn:aws:dynamodb:ap-southeast-1:123456789012:table/Music", "arn:aws:dynamodb:us-east-2:123456789012:table/Music" ] } ] }

升级期间的情况

  • 升级时,所有全局表副本将继续处理读取和写入流量。

  • 升级过程需要几分钟到几小时不等,具体取决于表大小和副本数量。

  • 在升级过程中,TableStatus 的值将从 ACTIVE 变为 UPDATING。您可以通过调用 DescribeTable API 或使用 DynamoDB 控制台中的视图来查看表的状态。

  • 在升级全局表期间,自动扩缩不会调整全局表的预置容量设置。强烈建议您在升级期间将表设置为按需容量模式。

  • 如果您选择在升级时使用预置容量模式和自动扩缩,则必须增加策略的最小读写吞吐量,以适应升级期间流量的预期增加,避免节流。

  • 升级过程完成后,表状态将变为 ACTIVE

DynamoDB Streams 在升级之前、期间和之后的行为

操作 副本区域 升级前的行为 升级期间的行为 升级后的行为

放置或更新

时间戳填充使用 UpdateItem 时间戳填充使用 PutItem 未生成客户可见的时间戳。
生成两条 Streams 记录。第一条记录包含客户写入的属性。第二条记录包含 aws:rep:* 属性。 生成两条 Streams 记录。第一条记录包含客户写入的属性。第二条记录包含 aws:rep:* 属性。 生成包含客户写入属性的一条 Streams 记录。
每次客户写入消耗两个 rWCU。 每次客户写入消耗两个 rWCU。 每次客户写入消耗一个 rWCU。
ReplicationLatencyPendingReplicationCount 指标在 CloudWatch 中发布。 ReplicationLatencyPendingReplicationCount 指标在 CloudWatch 中发布。 ReplicationLatency 指标在 CloudWatch 中发布。

目标位置

使用 PutItem 进行复制。 使用 PutItem 进行复制。 使用 PutItem 进行复制。
生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 生成一条 Streams 记录,其中仅包含客户写入的属性,不包含复制属性。
如果项目位于目标区域中,则消耗一个 rWCU。如果目标区域中不存在项目,则消耗两个 rWCU。 如果项目位于目标区域中,则消耗一个 rWCU。如果目标区域中不存在项目,则消耗两个 rWCU。 每次客户写入消耗一个 rWCU。
ReplicationLatencyPendingReplicationCount 指标在 CloudWatch 中发布。 ReplicationLatencyPendingReplicationCount 指标在 CloudWatch 中发布。 ReplicationLatency 指标在 CloudWatch 中发布。

删除

使用 DeleteItem 删除任何时间戳较小的项目。 使用 DeleteItem 删除任何时间戳较小的项目。 使用 DeleteItem 删除任何时间戳较小的项目。
生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 生成一条 Streams 记录,其中包含客户写入属性。
每次客户删除消耗一个 rWCU。 每次客户删除消耗一个 rWCU。 每次客户删除消耗一个 rWCU。
ReplicationLatencyPendingReplicationCount 指标在 CloudWatch 中发布。 ReplicationLatencyPendingReplicationCount 指标在 CloudWatch 中发布。 ReplicationLatency 指标在 CloudWatch 中发布。

目标位置

删除分为两个阶段:

  • 在第 1 阶段,UpdateItem 设置删除标志。

  • 在第 2 阶段,DeleteItem 删除项目。

使用 DeleteItem 删除项目。 使用 DeleteItem 删除项目。
生成两条 Streams 记录。第一条记录包含对 aws:rep:deleting 字段的更改。第二条记录包含客户写入属性和 aws:rep:* 属性。 生成一条 Streams 记录,其中包含客户写入的属性。 生成一条 Streams 记录,其中包含客户写入的属性。
每次客户删除消耗两个 rWCU。 每次客户删除消耗一个 rWCU。 每次客户删除消耗一个 rWCU。
ReplicationLatencyPendingReplicationCount 指标在 CloudWatch 中发布。 ReplicationLatency 指标在 CloudWatch 中发布。 ReplicationLatency 指标在 CloudWatch 中发布。

升级到版本 2019.11.21(当前版)

请按照以下步骤,使用 Amazon Web Services Management Console升级您的 DynamoDB 全局表版本。

将全局表升级到版本 2019.11.21(当前版)
  1. 打开 DynamoDB 控制台:https://console.aws.amazon.com/dynamodb/home

  2. 在控制台左侧的导航窗格中,选择,然后选择要升级到版本 2019.11.21(当前版)的全局表。

  3. 选择全局表选项卡。

  4. 选择更新版本

    显示“更新版本”按钮的控制台屏幕截图。
  5. 阅读并同意新要求,然后选择更新版本

  6. 升级过程完成后,控制台上显示的全局表版本将更改为 2019.11.21