旧版本和当前版本的行为差异升级先决条件所需的权限升级期间会发生什么 DynamoDB Streams 行为正在升级到 2019.11.21 版本（当前）

将全局表从旧版 (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（旧版）中，在一个地区调用 PutItem1KB 的项目并复制到其他区域需要每个区域 2 个 RWRU，但在 2019.11.21（当前）中只需要一个 rwRU。
在 2017.11.29（旧版）中，要调用 UpdateItem1KB 的项目，源区域中需要 2 个 rwRU，每个目标区域 1 个 rwRU，但在 2019.11.21（当前），源和目标区域都只有 1 个 rwRU（当前）。
在 2017.11.29（旧版）中，要调用 DeleteItem1KB 的项目，源区域中需要 1 个 rwRU，每个目标区域 2 个 rwRU，但在 2019.11.21（当前），源区域或目标区域只有 1 个 rwRU（当前）。

下表显示了 2017.11.29（旧版）和 2019.11.21（当前）表的 rwRU 消耗量。

两个地区一个 1KB 项目的 rwRU 消耗量为 2017.11.29（旧版）和 2019.11.21（当前）表
操作	2017.11.29（Legacy）	2019.11.21（当前）	Savings (节省成本)
PutItem	4 rwRU	2 rwRU	50%
UpdateItem	3 rwRU	2 rwRU	33%
DeleteItem	3 rwRU	2 rwRU	33%

版本 2017.11.29（Legacy）仅在 11 版本中可用。 Amazon Web Services 区域但是，版本 2019.11.21（当前）在所有版本中都可用。 Amazon Web Services 区域
要创建版本 2017.11.29（旧版）全局表，首先要创建一组空的区域表，然后调用 CreateGlobalTableAPI 来形成全局表。您可以通过调用 UpdateTableAPI 向现有区域表添加副本来创建版本 2019.11.21（当前）全局表。
版本 2017.11.29（Legacy）要求您在新区域中添加副本之前（包括在创建期间）清空表中的所有副本。版本 2019.11.21（当前）支持您在已包含数据的表上向区域添加和删除副本。
版本 2017.11.29（旧版）使用以下一组专用的控制平面 API 来管理副本：
版本 2019.11.21（当前）使用DescribeTable和 UpdateTableAPI 来管理副本。
版本 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（旧版）不跨副本同步生存时间 (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 自动缩放，或者为所有副本启用按需容量模式。
应用程序不要求表格项中存在aws:rep:deletingaws: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。您可以通过调用 DescribeTableAPI 或在 Dynamo DB 控制台中使用表格视图来查看表的状态。
在升级全局表期间，Auto Scaling 不会调整全局表的预配置容量设置。我们强烈建议您在升级期间将表设置为按需容量模式。
如果您在升级期间选择使用带有 auto Scaling 的预配置容量模式，则必须提高策略的最低读取和写入吞吐量，以适应任何预期的流量增长，从而避免在升级期间出现限制。
升级过程完成后，您的表格状态将更改为ACTIVE。

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

操作	副本区域	升级前的行为	升级期间的行为	升级后的行为
放置或更新	源	时间戳填充发生在使用UpdateItem。	时间戳填充发生在使用PutItem。	未生成客户可见的时间戳。
		生成了两条直播记录。第一条记录包含客户写入的属性。第二条记录包含`aws:rep:*`属性。	生成了两条直播记录。第一条记录包含客户写入的属性。第二条记录包含`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。
		生成了两条直播记录。第一条记录包含对该`aws:rep:deleting`字段的更改。第二条记录包含客户编写的属性和`aws:rep:*`属性。	生成了一条 Stream 记录，其中包含客户编写的属性。	生成了一条 Stream 记录，其中包含客户编写的属性。
		每次删除客户都会消耗两个 RWCU。	每次删除客户都会消耗一个 rwCu。	每次删除客户都会消耗一个 rwCu。
		`ReplicationLatency`并在中发布了`PendingReplicationCount`指标 CloudWatch。	`ReplicationLatency`指标发布于 CloudWatch。	`ReplicationLatency`指标发布于 CloudWatch。

正在升级到 2019.11.21 版本（当前）

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

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

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

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

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

确定版本

使用读取和写入操作