旧版与当前版的行为差异升级先决条件所需的权限升级期间的情况 DynamoDB Streams 行为升级到版本 2019.11.21（当前版）

将 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 个 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（当前版）使用 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 控制台中的表视图来查看表的状态。
在升级全局表期间，自动扩缩不会调整全局表的预置容量设置。强烈建议您在升级期间将表设置为按需容量模式。
如果您选择在升级时使用预置容量模式和自动扩缩，则必须增加策略的最小读写吞吐量，以适应升级期间流量的预期增加，避免节流。
ReplicationLatency 指标可以在升级过程中临时报告延迟峰值或停止报告指标数据。有关更多信息，请参阅ReplicationLatency。
升级过程完成后，表状态将变为 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 中发布。
	目标位置	删除分为两个阶段：在第 1 阶段，UpdateItem 设置删除标志。在第 2 阶段，DeleteItem 删除项目。	使用 DeleteItem 删除项目。	使用 DeleteItem 删除项目。
		生成两条 Streams 记录。第一条记录包含对 `aws:rep:deleting` 字段的更改。第二条记录包含客户写入属性和 `aws:rep:*` 属性。	生成一条 Streams 记录，其中包含客户写入的属性。	生成一条 Streams 记录，其中包含客户写入的属性。
		每次客户删除消耗两个 rWCU。	每次客户删除消耗一个 rWCU。	每次客户删除消耗一个 rWCU。
		`ReplicationLatency` 和 `PendingReplicationCount` 指标在 CloudWatch 中发布。	`ReplicationLatency` 指标在 CloudWatch 中发布。	`ReplicationLatency` 指标在 CloudWatch 中发布。

升级到版本 2019.11.21（当前版）

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

将全局表升级到版本 2019.11.21（当前版）

打开 DynamoDB 控制台：https://console.aws.amazon.com/dynamodb/home。
在控制台左侧的导航窗格中，选择表，然后选择要升级到版本 2019.11.21（当前版）的全局表。
选择全局表选项卡。
选择更新版本。
阅读并同意新要求，然后选择更新版本。
升级过程完成后，控制台上显示的全局表版本将更改为 2019.11.21。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

确定版本

全局表计费