管理 DynamoDB 全局表的最佳实践和要求

使用 Amazon DynamoDB 全局表，您可以跨 AWS 区域复制表数据。全局表中的副本表和二级索引必须具有相同的写入容量设置，以确保正确复制数据。

为了将来不出现混乱，对于有朝一日可能会变成全局表的任何表，最好不要在名称中加上区域。

全局表版本

要确定您所使用的全局表版本，请参阅确定您正在使用的 DynamoDB 全局表版本。

管理容量的要求

全局表必须通过以下两种方式之一配置吞吐能力：

使用具有自动扩缩的预调配容量模式或按需容量模式，可帮助确保全局表始终有足够的容量来执行对该全局表的所有区域的复制写入操作。

部署全局表

在 AWS CloudFormation 中，每个全局表都由单个区域中的单个堆栈控制。这与副本的数量无关。部署模板时，CloudFormation 将创建/更新所有副本作为单个堆栈操作的一部分。出于这一原因，您不应在多个区域中部署相同的 AWS::DynamoDB::GlobalTable 资源。这样做不受支持，而会导致错误。

如果您在多个区域中部署应用程序模板，则可以使用条件仅在一个区域中创建资源。或者，您可以选择在独立于应用程序堆栈的堆栈中定义 AWS::DynamoDB::GlobalTable 资源，并确保仅将其部署到单个区域。有关更多信息，请参阅 CloudFormation 中的全局表

DynamoDB 表由 AWS::DynamoDB::Table 表示，而全局表为 AWS::DynamoDB::GlobalTable。就 CloudFormation 而言，这本质上让它们成为两种不同的资源。因此，一种方法是通过使用 GlobalTable 构造来创建所有可能为全局的表。然后，您可以先将它们保留为独立的表，以后在需要时将其添加到区域中。

如果您有一个常规表并且想要在使用 CloudFormation 时对其进行转换，则建议的方法是：

使用全局表帮助处理潜在的区域中断

首先应该拥有或能够在备用区域中快速创建执行堆栈的独立副本，而每个副本都可访问其本地 DynamoDB 端点。

使用 Route53 或 AWS Global Accelerator 路由到距离最近的运行状况正常的区域。或者，让客户端知道它可能使用多个端点。

在每个区域中使用运行状况检查，这能够可靠地确定堆栈是否存在任何问题，包括 DynamoDB 是否降级。例如，不要只是通过 ping 来确定 DynamoDB 端点是否运行，而是实际执行一个调用，以确保能够成功完成一个完整的数据库流。

如果运行状况检查失败，流量可以路由到其他区域（通过使用 Route53 更新 DNS 条目，或者让 Global Accelerator 以不同方式路由，又或者让客户端选择不同的端点）。因为数据是连续同步的，所以全局表具有良好的 RPO（恢复点目标）；而且，因为两个区域始终为表的读写流量做好了准备，所以全局表也具有良好的 RTO（恢复时间目标）。

有关运行状况检查的更多信息，请参阅运行状况检查类型。

备份全局表

备份全局表时，备份一个区域中的表应该就足够了，不需要备份所有区域中的所有表。如果是为了能够恢复错误删除或修改的数据，那么一个区域中的 PITR 就应该足够了。同样，当出于历史记录目的（例如监管要求）保留快照时，备份一个区域中的表就应该足够了。备份的数据可以通过 AWS Backup 复制到多个区域。

副本和计算写入单位

在进行规划时，您需要计算一个区域中将执行的写入次数，然后将其与所有其他区域将发生的写入次数相加。这一点至关重要，因为在一个区域中执行的每一次写入也必须在每个副本区域中执行。如果您没有足够的容量来处理所有写入操作，则会出现容量异常。此外，区域间的复制等待时间也将增加。

例如，假设您预计每秒会对俄亥俄州区域的副本表进行 5 次写入，每秒对弗吉尼亚州北部区域的副本表进行 10 次写入，并且每秒对爱尔兰区域的副本表进行 5 次写入。在这种情况下，您需要预计以下每个区域都将消耗 20 个 rWCU 或 rWRU：俄亥俄州、弗吉尼亚州北部和爱尔兰。换言之，您需要预计在所有三个区域共消耗 60 个 rWCU。

有关将具有自动扩缩功能的预调配容量模式与 DynamoDB 结合使用的详细信息，请参阅使用 DynamoDB Auto Scaling 自动管理吞吐能力。