将 DynamoDB 全局表从版本 2017.11.29(旧版)升级到 2019.11.21(当前版)
注意
DynamoDB 全局表有两个版本:全局表版本 2019.11.21(当前版)和全局表版本 2017.11.29(旧版)。客户应尽可能使用版本 2019.11.21(当前版),因为与 2017.11.29(旧版)相比,它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。要确定您所使用的版本,请参阅确定您正在使用的 DynamoDB 全局表版本。
本部分介绍如何使用 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。
下表显示两个区域中 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 个 AWS 区域中可用。但是,版本 2019.11.21(当前版)在所有 AWS 区域中都可用。
-
要创建版本 2017.11.29(旧版)全局表,请首先创建一组空的区域表,然后调用 CreateGlobalTable API 来创建全局表。您可以通过调用 UpdateTable API 来将副本添加到现有区域表,以此创建版本 2019.11.21(当前版)全局表。
-
版本 2017.11.29(旧版)要求您在新区域中添加副本之前(包括创建期间)清空表中的所有副本。版本 2019.11.21(当前版)支持您在区域内的已包含数据的表中添加和删除副本。
-
版本 2017.11.29(旧版)通过以下一组专用的控制面板 API 来管理副本:
版本 2019.11.21(当前版)使用 DescribeTable 和 UpdateTable API 来管理副本。
-
版本 2017.11.29(旧版)针对每次写入操作发布两条 DynamoDB Streams 记录。版本 2019.11.21(当前版)针对每次写入操作仅发布一条 DynamoDB Streams 记录。
-
版本 2017.11.29(旧版)填充和更新
aws:rep:deleting
、aws:rep:updateregion
和aws:rep:updatetime
属性。版本 2019.11.21(当前版)不填充或更新这些属性。 -
版本 2017.11.29(旧版)不在副本间同步在 DynamoDB 中使用生存时间(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(当前版)全局表之前,您必须满足以下先决条件:
-
各区域副本间 在 DynamoDB 中使用生存时间(TTL) 设置是一致的。
-
各区域副本上的全局二级索引(GSI)定义是一致的。
-
各区域副本间的静态加密设置是一致的。
-
为所有副本的 WCU 启用 DynamoDB Auto Scaling,或为所有副本启用按需容量模式。
-
应用程序不要求表项目中有
aws:rep:deleting
、aws:rep:updateregion
和aws: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。 | ||
ReplicationLatency 和 PendingReplicationCount 指标在 CloudWatch 中发布。 |
ReplicationLatency 和 PendingReplicationCount 指标在 CloudWatch 中发布。 |
ReplicationLatency 指标在 CloudWatch 中发布。 |
||
目标位置 |
使用 PutItem 进行复制。 | 使用 PutItem 进行复制。 | 使用 PutItem 进行复制。 | |
生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 |
生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 |
生成一条 Streams 记录,其中仅包含客户写入的属性,不包含复制属性。 | ||
如果项目位于目标区域中,则消耗一个 rWCU。如果目标区域中不存在项目,则消耗两个 rWCU。 | 如果项目位于目标区域中,则消耗一个 rWCU。如果目标区域中不存在项目,则消耗两个 rWCU。 | 每次客户写入消耗一个 rWCU。 | ||
ReplicationLatency 和 PendingReplicationCount 指标在 CloudWatch 中发布。 |
ReplicationLatency 和 PendingReplicationCount 指标在 CloudWatch 中发布。 |
ReplicationLatency 指标在 CloudWatch 中发布。 |
||
删除 |
源 |
使用 DeleteItem 删除任何时间戳较小的项目。 | 使用 DeleteItem 删除任何时间戳较小的项目。 | 使用 DeleteItem 删除任何时间戳较小的项目。 |
生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 |
生成一条 Streams 记录,其中既包含客户写入的属性,又包含 aws:rep:* 属性。 |
生成一条 Streams 记录,其中包含客户写入属性。 | ||
每次客户删除消耗一个 rWCU。 | 每次客户删除消耗一个 rWCU。 | 每次客户删除消耗一个 rWCU。 | ||
ReplicationLatency 和 PendingReplicationCount 指标在 CloudWatch 中发布。 |
ReplicationLatency 和 PendingReplicationCount 指标在 CloudWatch 中发布。 |
ReplicationLatency 指标在 CloudWatch 中发布。 |
||
目标位置 |
删除分为两个阶段:
|
使用 DeleteItem 删除项目。 | 使用 DeleteItem 删除项目。 | |
生成两条 Streams 记录。第一条记录包含对 aws:rep:deleting 字段的更改。第二条记录包含客户写入属性和 aws:rep:* 属性。 |
生成一条 Streams 记录,其中包含客户写入的属性。 | 生成一条 Streams 记录,其中包含客户写入的属性。 | ||
每次客户删除消耗两个 rWCU。 | 每次客户删除消耗一个 rWCU。 | 每次客户删除消耗一个 rWCU。 | ||
ReplicationLatency 和 PendingReplicationCount 指标在 CloudWatch 中发布。 |
ReplicationLatency 指标在 CloudWatch 中发布。 |
ReplicationLatency 指标在 CloudWatch 中发布。 |
升级到版本 2019.11.21(当前版)
请按照以下步骤,使用 AWS Management Console升级您的 DynamoDB 全局表版本。
将全局表升级到版本 2019.11.21(当前版)
-
打开 DynamoDB 控制台:https://console.aws.amazon.com/dynamodb/home
。 -
在控制台左侧的导航窗格中,选择表,然后选择要升级到版本 2019.11.21(当前版)的全局表。
-
选择全局表选项卡。
-
选择更新版本。
-
阅读并同意新要求,然后选择更新版本。
-
升级过程完成后,控制台上显示的全局表版本将更改为 2019.11.21。