# 全局表版本 2017.11.29（旧版）
**重要**
本文档适用于版本 2017.11.29（旧版）的全局表，对于新的全局表，应避免使用该版本。客户应尽可能使用[全局表版本 2019.11.21（当前版）](GlobalTables.md)，因为相比 2017.11.29（旧版），它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。
要确定正在使用的版本，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。要将现有全局表从版本 2017.11.29（旧版）更新到版本 2019.11.21（当前版），请参阅[DynamoDB 全局表版本](V2globaltables_versions.md)。
**Topics**
+ [
# 全局表：工作原理
](globaltables_HowItWorks.md)
+ [
# 管理全局表的最佳实践和要求
](globaltables_reqs_bestpractices.md)
+ [
# 创建全局表（版本 2017.11.29）
](globaltables.tutorial.md)
+ [
# 监控全局表
](globaltables_monitoring.md)
+ [
# 将 IAM 与全局表结合使用
](gt_IAM.md)
# 全局表：工作原理
**重要**
本文档适用于版本 2017.11.29（旧版）的全局表，对于新的全局表，应避免使用该版本。客户应尽可能使用[全局表版本 2019.11.21（当前版）](GlobalTables.md)，因为相比 2017.11.29（旧版），它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。
要确定正在使用的版本，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。要将现有全局表从版本 2017.11.29（旧版）更新到版本 2019.11.21（当前版），请参阅[DynamoDB 全局表版本](V2globaltables_versions.md)。
以下部分可帮助您了解 Amazon DynamoDB 中全局表的概念和行为。
## 版本 2017.11.29（旧版）的全局表概念
*全局表*是一个或多个副本表的集合，它们都由单个 AWS 账户所有。
*副本表*（或*副本*）是单个 DynamoDB 表，它作为全局表的一部分发挥作用。每个副本都存储相同的数据项目集。任何给定的全局表在每个 AWS 区域只能有一个副本表。
以下是如何创建全局表的概念概述。
1. 在 AWS 区域中启用 DynamoDB Streams 的情况下创建一个普通的 DynamoDB 表。
1. 对要复制数据的每个其他区域重复步骤 1。
1. 根据您创建的表定义 DynamoDB 全局表。
这些区域有：AWS 管理控制台 会自动执行这些任务，因此您可以更快、更轻松地创建全局表。有关更多信息，请参阅 [创建全局表（版本 2017.11.29）](globaltables.tutorial.md)。
生成的 DynamoDB 全局表包含多个副本表（每个区域一个），DynamoDB 将这些表视为一个单元。每个副本都具有相同的表名和相同的主键架构。当应用程序将数据写入一个区域中的副本表时，DynamoDB 会自动将写操作传播到其他 AWS 区域的其他副本表。
**重要**
为使表数据保持同步，全局表会自动为每个项目创建以下属性：
`aws:rep:deleting`
`aws:rep:updatetime`
`aws:rep:updateregion`
请勿修改这些属性或创建具有相同名称的属性。
您可以将副本表添加到全局表中，以便在其他区域中可用。（为此，全局表必须为空。换句话说，任何副本表都不能包含任何数据。）
您还可以从全局表中删除副本表。如果执行此操作，则表与全局表完全断开关联。此新独立表不再与全局表交互，并且数据不再传播到全局表或从全局表传播。
**警告**
请注意，删除副本不是原子过程。为确保行为的一致性和已知状态，您可能需要考虑提前将应用程序写入流量从要删除的副本移开。删除副本后，请等到所有副本区域端点显示副本已取消关联，然后再将其作为自己的隔离区域表对其进行任何进一步的写入。
## 常见任务
全局表的常见任务如下所示。
您可以像删除常规表一样删除全局表的副本表。这将停止复制到该区域并删除保留在该区域的表副本。您无法在切断复制后，让表的副本作为独立实体存在。
**注意**
在使用源表启动新区域后的至少 24 小时之内，您无法删除该源表。如果您尝试过早将其删除，则会收到错误。
如果应用程序大约在同一时间更新不同区域中的同一项目，则可能会发生冲突。为了帮助确保最终一致性，DynamoDB 全局表使用“最后一个写入方为准”方法来协调并发更新。所有副本都将同意最新的更新，并收敛到它们都具有相同数据的状态。
**注意**
避免冲突的方法有几种，其中包括：
使用 IAM 策略以便仅允许写入一个区域中的表。
使用 IAM 策略将用户仅路由到一个区域，而将另一个区域留作空闲备用区域，或者交替地将奇数用户路由到一个区域，而将偶数用户路由到另一个区域。
避免使用诸如 Bookmark = Bookmark \$1 1 之类的非幂等更新，转而使用诸如 Bookmark=25 之类的静态更新。
## 监控全局表
您可以使用 CloudWatch 来观察指标 `ReplicationLatency`。该指标跟踪从 DynamoDB 流显示副本表的更新项目，到该项目出现在全局表的另一个副本中之间经过的时间。`ReplicationLatency` 以毫秒表示，并针对每个源区域和目标区域对发出。这是 Global Tables v2 提供的唯一 CloudWatch 指标。
观察到的延迟取决于所选区域之间的距离以及其他变量。在同一地理区域内，各区域的延迟常常在 0.5 到 2.5 秒范围内。
## 生存时间（TTL）
您可以使用生存时间（TTL）来指定一个属性名称，其值表示项目的过期时间。此值以自 Unix 纪元开始以来的秒数指定。
在旧版全局表中，TTL 删除不会自动复制到其它副本中。通过 TTL 规则删除项目时，删除工作是在不消耗写入单位的情况下执行的。
请注意，如果源表和目标表的预调配写入容量非常低，这可能会导致节流，因为 TTL 删除需要写入容量。
## 使用全局表的流和事务
每个全局表都基于其所有写入生成一个独立的流，而不考虑这些写入的起点。您可以选择在一个区域或在所有区域中单独使用此 DynamoDB 流。
如果您想要已处理的本地写入而不是复制的写入，则可以为每个项目添加您自己的区域属性。然后，您可以使用 Lambda 事件筛选条件，以仅调用 Lambda 在本地区域中进行写入。
事务操作仅在最初进行写入的区域内提供 ACID（原子性、一致性、隔离性和持久性）保证。全局表中不支持跨区域的事务。
例如，如果您有一个全局表，该表在美国东部（俄亥俄州）和美国西部（俄勒冈州）区域中具有副本，并且在美国东部（俄亥俄州）区域中执行 TransactWriteItems 操作，则在复制更改时，可能会在美国西部（俄勒冈州）区域观察到部分完成的事务。更改仅在源区域中提交后才会复制到其他区域。
**注意**
全局表通过直接更新 DynamoDB 来“绕过”DynamoDB Accelerator。因此，DAX 不会意识到它持有的是陈旧的数据。DAX 缓存只有在缓存的 TTL 过期时才会刷新。
全局表上的标签不会自动传播。
## 读写吞吐量
全局表通过以下方式管理读写吞吐量。
+ 跨区域的所有表实例上的写入容量必须相同。
+ 在版本 2019.11.21（当前版）中，如果表设置为支持自动扩缩或处于按需模式，则写入容量会自动保持同步。在这些同步的自动扩缩设置中，每个区域中预调配的当前写入容量将独立上升和下降。如果表处于按需模式，则该模式将同步到其他副本。
+ 读取容量可能因区域而异，因为读取量可能不相等。在向表添加全局副本时，会传播源区域的容量。创建后，您可以调整一个副本的读取容量，而且此新设置不会传输到另一端。
## 一致性和冲突解决
对任何副本表中任何项目所做的任何更改都将复制到同一全局表中的所有其他副本中。在全局表中，新写入的项目通常会在几秒钟内传播到所有副本表。
对于全局表，每个副本表都存储相同的数据项集。DynamoDB 不支持仅部分项目的部分复制。
应用程序可以读取数据和将数据写入任何副本表。DynamoDB 支持跨区域的最终一致读取，但不支持跨区域的强一致性读取。如果您的应用程序只使用最终一致性读取，并且仅针对一个 AWS 区域，它将无需任何修改工作。但是，如果您的应用程序需要强一致性读取，它必须在同一区域中执行其所有强一致性读取和写入。否则，如果您写入一个区域并从另一个区域读取，则读取响应可能包含过时的数据，这些数据不反映最近在另一个区域中完成的写入的结果。
如果应用程序大约在同一时间更新不同区域中的同一项目，则可能会发生冲突。为了帮助确保最终的一致性，DynamoDB 全局表使用*最后一个写入方为准*协调并发更新，DynamoDB 会尽最大努力确定最后一个写入方。使用此冲突解决机制，所有副本都将同意最新的更新，并收敛到它们都具有相同数据的状态。
## 可用性与持久性
如果单个 AWS 区域变得孤立或降级，您的应用程序可以重定向到不同的区域，并对其他副本表执行读取和写入操作。您可以应用自定义业务逻辑来确定何时将请求重定向到其他区域。
如果某个区域被隔离或降级，DynamoDB 会跟踪已执行但尚未传播到所有副本表的任何写入操作。当区域恢复联机时，DynamoDB 将继续将任何挂起的写入从该区域传播到其他区域中的副本表。它还会继续将写入从其他副本表传播到现在重新联机的区域。无论该区域被隔离多长时间，所有以前成功的写入都将最终得到传播。
# 管理全局表的最佳实践和要求
**重要**
本文档适用于版本 2017.11.29（旧版）的全局表，对于新的全局表，应避免使用该版本。客户应尽可能使用[全局表版本 2019.11.21（当前版）](GlobalTables.md)，因为相比 2017.11.29（旧版），它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。
要确定正在使用的版本，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。要将现有全局表从版本 2017.11.29（旧版）更新到版本 2019.11.21（当前版），请参阅[DynamoDB 全局表版本](V2globaltables_versions.md)。
使用 Amazon DynamoDB 全局表，您可以跨 AWS 区域复制表数据。全局表中的副本表和二级索引必须具有相同的写入容量设置，以确保正确复制数据。
**Topics**
+ [
## 全局表版本
](#globaltables_version.tables)
+ [
## 添加新副本表的要求
](#globaltables_reqs_bestpractices.requirements)
+ [
## 管理容量的最佳实践和要求
](#globaltables_reqs_bestpractices.tables)
## 全局表版本
DynamoDB 全局表有两个版本：[全局表版本 2019.11.21（当前版）](GlobalTables.md)和[全局表版本 2017.11.29（旧版）](globaltables.V1.md)。客户应尽可能使用全局表版本 2019.11.21（当前版），因为相比 2017.11.29（旧版），它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。
要确定正在使用的版本，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。要将现有全局表从版本 2017.11.29（旧版）更新到版本 2019.11.21（当前版），请参阅[升级全局表](V2globaltables_versions.md#upgrading-to-current-version)。
## 添加新副本表的要求
如果要将新副本表添加到全局表中，则必须满足以下每个条件：
+ 表必须与其他所有副本具有相同的分区键。
+ 表必须具有指定的写入容量管理设置。
+ 表必须与其他所有副本同名。
+ 表必须启用 DynamoDB Streams，而流同时包含项目的新旧映像。
+ 全局表中的任何新副本或现有副本表都不能包含任何数据。
如果指定了全局二级索引，则必须满足以下条件：
+ 全局二级索引必须具有相同的名称。
+ 全局二级索引必须具有相同的分区键和排序键（如果有）。
**重要**
写入容量设置应在所有全局表的副本表和匹配的二级索引之间设置一致。要更新全局表的写入容量设置，我们强烈建议使用 DynamoDB 控制台或 `UpdateGlobalTableSettings` API 操作。`UpdateGlobalTableSettings` 将写入容量设置的更改应用于所有副本表，并自动匹配全局表中的二级索引。如果您使用 `UpdateTable`、`RegisterScalableTarget` 或者 `PutScalingPolicy` 操作，则应将更改应用于每个副本表并分别匹配二级索引。有关此操作的更多信息，请参见 [Amazon DynamoDB API 参考](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/)的 [UpdateGlobalTableSettings](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateGlobalTableSettings.html)。
我们强烈建议您启用 Auto Scaling 以管理预置的写入容量设置。如果您希望手动管理写入容量设置，则应为所有副本表配置相同的复制写入容量单位。另外，在全局表中配置相同的复制写入容量单位，以匹配二级索引。
您还必须拥有适当的 AWS Identity and Access Management (IAM) 权限。有关更多信息，请参阅 [将 IAM 与全局表结合使用](gt_IAM.md)。
## 管理容量的最佳实践和要求
在 DynamoDB 中管理副本表的容量设置时，请考虑以下事项。
### 使用 DynamoDB Auto Scaling
建议使用 DynamoDB Auto Scaling 管理使用预置模式的副本表的吞吐容量设置的方法。DynamoDB Auto Scaling 会自动调整每个副本表的读取容量单位 (RCU) 和写入容量单位 (WCU)。有关更多信息，请参阅 [使用 DynamoDB Auto Scaling 自动管理吞吐能力](AutoScaling.md)。
如果使用 AWS 管理控制台 创建副本表，默认情况下会为每个副本表启用自动扩缩，并使用默认的自动扩缩设置来管理读取容量单位和写入容量单位。
通过 DynamoDB 控制台或使用 `UpdateGlobalTableSettings` 调用对副本表或二级索引的自动扩缩设置进行的更改将自动应用于所有副本表并匹配全局表中的二级索引。这些更改将覆盖所有现有的自动扩缩设置。这可确保预置的写入容量设置在全局表中的副本表和二级索引之间保持一致。如果您使用 `UpdateTable`、`RegisterScalableTarget` 或者 `PutScalingPolicy` 调用，则应将更改应用于每个副本表并分别匹配二级索引。
**注意**
如果自动扩缩不能满足应用程序的容量更改（不可预测的工作负载），或者您不想配置其设置（最小、最大或利用率阈值的目标设置），则可以使用按需模式管理全局表的容量。有关更多信息，请参阅 [按需模式](capacity-mode.md#capacity-mode-on-demand)。
如果在全局表上启用按需模式，则对复制写请求单元 (RWCU) 的使用将与 RWCU 的预置方式一致。例如，如果您对在另外两个区域中复制的本地表执行 10 次写入操作，则将占用 60 个写入请求单位 (10 \$1 10 \$1 10 = 30; 30 x 2 = 60)。使用的 60 个写入请求单位包括全局表版本 2017.11.29（旧版）用于更新 `aws:rep:deleting`、`aws:rep:updatetime` 和 `aws:rep:updateregion` 属性的额外写入。
### 手动管理容量
如果您决定不使用 DynamoDB Auto Scaling，则必须在每个副本表和二级索引上手动设置读取容量和写入容量设置。
每个副本表上的预置的复制写入容量单位 (RWCU) 应设置为跨所有区域的应用程序写入所需的 RWCU 总数乘以 2。这适用于在本地区域发生的应用程序写入和来自其他区域的复制应用程序写入操作。例如，假设您期望每秒对俄亥俄州的副本表进行 5 次写入，并且每秒对北弗吉尼亚州的副本表进行 5 次写入。在本例中，您应该为每个副本表配置 20 个 rWCU（5 \$1 5 = 10；10 x 2 = 20）。
要更新全局表的写入容量设置，我们强烈建议使用 DynamoDB 控制台或 `UpdateGlobalTableSettings` API 操作。`UpdateGlobalTableSettings` 将写入容量设置的更改应用于所有副本表，并自动匹配全局表中的二级索引。如果您使用 `UpdateTable`、`RegisterScalableTarget` 或 `PutScalingPolicy` 操作，则应将更改应用于每个副本表并分别匹配二级索引。有关更多信息，请参阅 [Amazon DynamoDB API 参考](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/)。
**注意**
更新设置 (`UpdateGlobalTableSettings`），则必须在 DynamoDB 中安装 `dynamodb:UpdateGlobalTable`、`dynamodb:DescribeLimits`、`application-autoscaling:DeleteScalingPolicy` 和 `application-autoscaling:DeregisterScalableTarget` 权限。有关更多信息，请参阅 [将 IAM 与全局表结合使用](gt_IAM.md)。
# 创建全局表（版本 2017.11.29）
**重要**
本文档适用于版本 2017.11.29（旧版）的全局表，对于新的全局表，应避免使用该版本。客户应尽可能使用[全局表版本 2019.11.21（当前版）](GlobalTables.md)，因为相比 2017.11.29（旧版），它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。
要确定正在使用的版本，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。要将现有全局表从版本 2017.11.29（旧版）更新到版本 2019.11.21（当前版），请参阅[DynamoDB 全局表版本](V2globaltables_versions.md)。
本节介绍如何使用 Amazon DynamoDB 控制台或 AWS Command Line Interface (AWS CLI) 创建全局表。
**Topics**
+ [
## 创建全局表（控制台）
](#creategt_console)
+ [
## 创建全局表（AWS CLI）
](#creategt_cli)
## 创建全局表（控制台）
按照以下步骤，使用控制台创建全局表。以下示例创建一个全局表，其副本表位于美国和欧洲。
1. 打开 DynamoDB 控制台：[https://console.aws.amazon.com/dynamodb/home](https://console.aws.amazon.com/dynamodb/home)。对于本示例，请选择 us-east-2（美国东部俄亥俄州）区域。
1. 在控制台左侧的导航窗格中，选择**表**。
1. 选择**创建表**。
对于 **表名称**，输入 **Music**。
对于**主键**，输入 **Artist**。选择**添加排序键**，然后输入 **SongTitle**。（**Artist** 和 **SongTitle** 均应为字符串。）
要创建表，请选择**创建**。此表在新全局表中用作第一个副本表。这是您稍后添加的其他副本表的原型。
1. 选择**全局表**选项卡，然后选择**创建版本 2017.11.29（旧版）副本**。
![\[显示“创建版本 2017.11.29（旧版）副本”按钮的控制台屏幕截图。\]](http://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/images/GlobalTables-old.png)
1. 从**可用复制区域**下拉菜单，选择**美国西部（俄勒冈州）**。
控制台将进行检查，以确保所选区域中不存在同名的表。如果有同名的表，则必须删除现有表，然后才能在该区域创建新的副本表。
1. 选择**创建副本**。这将启动美国西部（俄勒冈州）的表创建过程。
选定表（以及任何其他副本表）的**全局表**选项卡将显示该表已在多个区域中复制。
1. 现在，添加另一个区域，以便您跨美国和欧洲复制并同步您的全局表。为此，请重复步骤 5，不过这次指定**欧洲地区（法兰克福）**而非**美国西部（俄勒冈州）**。
1. 在美国东部（俄亥俄）区域，您应仍使用 AWS 管理控制台。选择左侧导航菜单中的**项目**，选择 **Music** 表，然后选择**创建项目**。
1. 对于 **Artist**，输入 **item\$11**。
1. 对于 **SongTitle**，输入 **Song Value 1**。
1. 要写入该项目，请选择**创建项目**。
1. 稍后，该项目将跨您的全局表的所有三个区域复制。要验证这一点，请在控制台中，转到右上角的区域选择器，并选择**欧洲地区（法兰克福）**。欧洲地区（法兰克福）的 `Music` 表应包含新的项目。
1. 重复步骤 9，然后选择**美国西部（俄勒冈州）**以验证该区域中的复制。
## 创建全局表（AWS CLI）
按照以下步骤，使用 AWS CLI 创建全局表 `Music`。以下示例创建一个全局表，其副本表位于美国和欧洲。
1. 创建新表 (`Music`)，并启用 DynamoDB Streams (`NEW_AND_OLD_IMAGES`)。
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions \
AttributeName=Artist,AttributeType=S \
AttributeName=SongTitle,AttributeType=S \
--key-schema \
AttributeName=Artist,KeyType=HASH \
AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region us-east-2
```
1. 在美国东部（弗吉尼亚州北部）创建相同 `Music` 表。
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions \
AttributeName=Artist,AttributeType=S \
AttributeName=SongTitle,AttributeType=S \
--key-schema \
AttributeName=Artist,KeyType=HASH \
AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region us-east-1
```
1. 创建全局表 (`Music`)，由副本表组成 `us-east-2` 和 `us-east-1` 区域。
```
aws dynamodb create-global-table \
--global-table-name Music \
--replication-group RegionName=us-east-2 RegionName=us-east-1 \
--region us-east-2
```
**注意**
全局表名称 (`Music`) 必须与每个副本表的名称匹配 (`Music`)。有关更多信息，请参阅 [全局表的最佳实践](globaltables-bestpractices.md)。
1. 在欧洲地区（爱尔兰）中创建另一个表，其设置与您在步骤 1 和步骤 2 中创建的设置相同。
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions \
AttributeName=Artist,AttributeType=S \
AttributeName=SongTitle,AttributeType=S \
--key-schema \
AttributeName=Artist,KeyType=HASH \
AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region eu-west-1
```
执行此步骤后，将新表添加到 `Music` 全局表。
```
aws dynamodb update-global-table \
--global-table-name Music \
--replica-updates 'Create={RegionName=eu-west-1}' \
--region us-east-2
```
1. 要验证复制是否正常工作，请将一个新项添加到美国东部（俄亥俄）的 `Music` 表。
```
aws dynamodb put-item \
--table-name Music \
--item '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
--region us-east-2
```
1. 等待几秒钟，然后检查该项目是否已成功复制到美国东部（弗吉尼亚州北部）和欧洲地区（爱尔兰）。
```
aws dynamodb get-item \
--table-name Music \
--key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
--region us-east-1
```
```
aws dynamodb get-item \
--table-name Music \
--key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
--region eu-west-1
```
# 监控全局表
**重要**
本文档适用于版本 2017.11.29（旧版）的全局表，对于新的全局表，应避免使用该版本。客户应尽可能使用[全局表版本 2019.11.21（当前版）](GlobalTables.md)，因为相比 2017.11.29（旧版），它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。
要确定正在使用的版本，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。要将现有全局表从版本 2017.11.29（旧版）更新到版本 2019.11.21（当前版），请参阅[DynamoDB 全局表版本](V2globaltables_versions.md)。
您可以使用 Amazon CloudWatch 监控全局表的行为和性能。Amazon DynamoDB 发布全局表中每个副本的 `ReplicationLatency` 和 `PendingReplicationCount` 指标。
+ **`ReplicationLatency`**—从 DynamoDB 流显示副本表的更新项目，到该项目出现在全局表的另一个副本中之间经过的时间。`ReplicationLatency` 以毫秒表示，并针对每个源区域和目标区域对发出。
在正常操作期间，`ReplicationLatency` 应相当恒定。`ReplicationLatency` 值上升可能表明来自一个副本的更新没有及时传播到其他副本表。随着时间的推移，这会导致其他副本表*落后*，因为它们不能再一致地收到更新。在这种情况下，应验证每个副本表的读取容量单位 (RCU) 和写入容量单位 (WCU) 是否相同。此外，选择 WCU 设置时，应遵循 [全局表版本管理容量的最佳实践和要求](globaltables_reqs_bestpractices.md#globaltables_reqs_bestpractices.tables) 中的建议。
如果某个 AWS 区域降级，并且您在该区域有一个副本表，则 `ReplicationLatency` 会增加。在这种情况下，可以临时将应用程序的读取和写入活动重定向到不同的 AWS 区域。
+ ** `PendingReplicationCount`**-写入一个副本表但尚未写入全局表中另一个复制副本的项目更新数。`PendingReplicationCount`以项目数表示，并针对每个源-和目的地-区域对发射。
在正常运行期间，`PendingReplicationCount` 应该非常低。如果 `PendingReplicationCount` 增加延期时，请调查副本表的预配写入容量设置是否足以满足当前工作负载。
如果某个 AWS 区域降级，并且您在该区域有一个副本表，则 `PendingReplicationCount` 会增加。在这种情况下，可以临时将应用程序的读取和写入活动重定向到不同的 AWS 区域。
有关更多信息，请参阅 [DynamoDB 指标与维度](metrics-dimensions.md)。
# 将 IAM 与全局表结合使用
**重要**
本文档适用于版本 2017.11.29（旧版）的全局表，对于新的全局表，应避免使用该版本。客户应尽可能使用[全局表版本 2019.11.21（当前版）](GlobalTables.md)，因为相比 2017.11.29（旧版），它提供了更大的灵活性、更高的效率并且消耗的写入容量更少。
要确定正在使用的版本，请参阅[确定全局表的版本](V2globaltables_versions.md#globaltables.DetermineVersion)。要将现有全局表从版本 2017.11.29（旧版）更新到版本 2019.11.21（当前版），请参阅[DynamoDB 全局表版本](V2globaltables_versions.md)。
当您首次创建全局表时，Amazon DynamoDB 会自动为您创建一个 AWS Identity and Access Management (IAM) 服务相关角色。该角色名为 [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBReplicationServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBReplicationServiceRolePolicy)，使得 DynamoDB 能够代表您管理全局表的跨区域复制。不要删除该服务相关角色。否则，所有全局表都将无法继续工作。
有关服务相关角色的更多信息，请参见 *IAM 用户指南*中的[使用服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)。
要在 DynamoDB 中创建和维护全局表，您必须具有 `dynamodb:CreateGlobalTable` 权限访问以下各项：
+ 要添加的副本表。
+ 已经是全局表一部分的每个现有副本。
+ 全局表本身。
要为 DynamoDB 的全局表更新设置 (`UpdateGlobalTableSettings`)，必须具有 `dynamodb:UpdateGlobalTable`、`dynamodb:DescribeLimits`、`application-autoscaling:DeleteScalingPolicy` 和 `application-autoscaling:DeregisterScalableTarget` 权限。
更新现有扩展策略时需要 `application-autoscaling:DeleteScalingPolicy` 和 `application-autoscaling:DeregisterScalableTarget` 权限。这样，全局表服务可以在将新策略附加到表或二级索引之前删除旧的扩展策略。
如果您使用 IAM 策略来管理对一个副本表的访问，则应将相同的策略应用于该全局表中的所有其他副本。此做法可帮助您在所有副本表中维护一致的权限模型。
通过对全局表中的所有副本使用相同的 IAM 策略，您还可以避免授予对全局表数据的意外读取和写入访问权限。例如，假设只能访问全局表中一个副本的用户。如果该用户可以写入此副本，则 DynamoDB 会将写操作传播到所有其他副本表。实际上，用户可以（间接）写入全局表中的所有其他副本。通过对所有副本表使用一致的 IAM 策略，可以避免这种情况。
## 示例：允许 CreateGlobalTable 操作
在将副本添加到全局表之前，您必须先拥有全局表及其每个副本表的 `dynamodb:CreateGlobalTable` 权限。
下面的 IAM 策略授予允许对所有表执行 `CreateGlobalTable` 操作的权限。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["dynamodb:CreateGlobalTable"],
"Resource": "*"
}
]
}
```
------
## 示例：允许 UpdateGlobalTable、DescribeLimits、application-autoscaling:DeleteScalingPolicy 和 application-autoscaling:DeregisterScalableTarget 操作
要为 DynamoDB 的全局表更新设置 (`UpdateGlobalTableSettings`)，必须具有 `dynamodb:UpdateGlobalTable`、`dynamodb:DescribeLimits`、`application-autoscaling:DeleteScalingPolicy` 和 `application-autoscaling:DeregisterScalableTarget` 权限。
下面的 IAM 策略授予允许对所有表执行 `UpdateGlobalTableSettings` 操作的权限。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:UpdateGlobalTable",
"dynamodb:DescribeLimits",
"application-autoscaling:DeleteScalingPolicy",
"application-autoscaling:DeregisterScalableTarget"
],
"Resource": "*"
}
]
}
```
------
## 示例：允许对只允许在某些区域中使用副本的特定全局表名执行 CreateGlobalTable 操作
下面的 IAM 策略授予允许 `CreateGlobalTable` 操作创建名为，`Customers`在两个区域中具有副本的全局表的权限。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dynamodb:CreateGlobalTable",
"Resource": [
"arn:aws:dynamodb::123456789012:global-table/Customers",
"arn:aws:dynamodb:us-east-1:123456789012:table/Customers",
"arn:aws:dynamodb:us-west-1:123456789012:table/Customers"
]
}
]
}
```
------