全局表的准备情况核对清单和常见问题解答
在部署全局表时，请使用下面的决策和任务核对清单。
确定全局表应涉及多少个区域以及哪些区域。
确定应用程序的写入模式。有关更多信息，请参阅 使用全局表的写入模式。
根据写入模式规划您的全局表的请求路由策略。
捕获有关每个区域的运行状况、延迟和错误的指标。有关 DynamoDB 指标的列表，请参阅 Amazon 博客文章监控 Amazon DynamoDB 的操作感知
，以获取需要观察的指标列表。您还应该使用 Synthetics Canary（合成金丝雀，旨在检测故障的人工请求，以煤矿中的金丝雀命名），以及实时观察客户流量。并非所有问题都会出现在 DynamoDB 指标中。 在
ReplicationLatency中为任何持续增加设置警报。增加可能表示意外配置错误，即全局表在不同区域中具有不同的写入设置，这会导致复制请求失败和延迟增加。这也可能表明存在区域中断。一个很好的例子是，如果最近的平均值超过 180000 毫秒，则生成警报。您可能还会观察到 ReplicationLatency降至 0，这表示复制已停止。为每个全局表分配足够的最大读取和写入设置。
提前确定撤离某个区域的原因。如果决定涉及人为判断，请记录所有考虑因素。这项工作应该事先仔细完成，而不是在压力下匆匆了事。
为撤离某个区域时必须采取的每项措施制定一份运行手册。通常，全局表所涉及的工作非常少，但是移动堆栈的其余部分可能很复杂。
注意
最佳做法是仅依赖数据面板操作，而不依赖控制面板操作，因为在区域故障期间，某些控制面板操作可能会降级。
有关更多信息，请参阅 Amazon 博客文章使用 Amazon DynamoDB 全局表构建弹性应用程序：第 4 部分
。 定期测试运行手册的各个方面，包括区域撤离。未经测试的运行手册是不可靠的。
考虑使用韧性监测中心来评估整个应用程序（包括全局表）的弹性。通过韧性监测中心的控制面板，您可以全面查看应用程序产品组合的整体弹性状态。
考虑使用 Route 53 ARC 就绪检查来评估应用程序的当前配置，并跟踪与最佳实践的任何偏差。
在编写用于 Route 53 或 Global Accelerator 的运行状况检查时，仅通过 ping 来确认 DynamoDB 端点已启动是不够的。这未包括许多故障模式，例如 IAM 配置错误、代码部署问题、DynamoDB 外部的堆栈故障、高于平均读取或写入延迟等等。最好执行一组实施完整数据库流的调用。
有关部署全局表的常见问题解答（FAQ）
对于 DynamoDB 全局表的总体使用情况，有哪些有用的原则？
DynamoDB 全局表的控制旋钮非常少，但仍需要注意一些事项。您必须确定您的写入模式、路由模型和撤离过程。您必须针对每个区域对应用程序进行检测，并准备好调整路由或执行撤离，以维护全局运行状况。您获得的回报是拥有一个具有低延迟读写和 99.999% 服务水平协议的全局分布式数据集。
全局表的定价是多少？
对传统 DynamoDB 表的写入按写入容量单位（WCU，用于预调配表）或写入请求单位（WRU，用于按需表）定价。如果您写入一个 5KB 项目，则会产生 5 个单位的费用。对全局表的写入按复制写入容量单位（rWCU，用于预调配表）或复制写入请求单位（rWRU，用于按需表）定价。
rWCU 和 rWRU 包括管理复制所需的流媒体基础设施的成本。因此，它们的价格比 WCU 和 WRU 高出 50%。跨区域数据传输费用确实适用。
在其中直接写入或复制写入项目的每个区域都会产生复制写入单位费用。
写入全局二级索引（GSI）被视为本地写入，使用常规写入单位。
目前没有可用 rWCU 的预留容量。对于具有 GSI 且消耗写入单位的表，购买预留容量可能仍有好处。
向全局表中添加新区域时的初始引导的收费方式类似于每 GB 还原数据的还原操作，外加跨区域数据传输费用。
全局表支持哪些区域？
全局表版本 2019.11.21（当前版）可在大多数区域使用。添加副本时，您可以在 DynamoDB 控制台的“区域”下拉列表中看到最新的列表。
如何使用全局表处理 GSI？
在全局表版本 2019.11.21（当前版）中，当您在一个区域中创建 GSI 时，它会在其它参与区域中自动创建并自动回填。
如何停止复制全局表？
您可以像删除任何其他表一样删除副本表。删除全局表将停止复制到该区域，并删除保留在该区域中的表副本。但是，不能在将表的副本保留为独立实体时停止复制，也不能暂停复制。
DynamoDB Streams 如何与全局表交互？
每个全局表都基于其所有写入生成一个独立的流，而无论这些写入是从何处开始的。您可以选择在一个区域或在所有区域中（独立）使用 DynamoDB 流。如果您想要处理本地而不是复制的写入操作，则可以向每个项目添加您自己的区域属性，以确定写入区域。然后，您可以使用 Lambda 事件筛选条件，以便只调用 Lambda 函数来处理本地区域中的写入操作。这有助于执行插入和更新操作，但遗憾的是，不能执行删除操作。
全局表如何处理事务？
事务操作仅在最初发生写入操作的区域内提供原子性、一致性、隔离性和持久性（ACID）保证。全局表中不支持跨区域的事务。例如，如果您有一个全局表，该表在美国东部（俄亥俄州）和美国西部（俄勒冈州）区域中具有副本，并且在美国东部（俄亥俄州）区域中执行 TransactWriteItems 操作，则在复制更改时，可能会在美国西部（俄勒冈州）区域观察到部分完成的事务。更改仅在源区域中提交后才复制到其他区域。
全局表如何与 DynamoDB Accelerator 缓存（DAX）交互？
全局表通过直接更新 DynamoDB 绕过 DAX，因此 DAX 并不知道它保存的是陈旧数据。DAX 缓存只有在缓存的 TTL 过期时才会刷新。
表上的标签会传播吗？
不，标签不会自动传播。
我应该备份所有区域中的表，还是只备份一个区域中的表？
答案取决于备份的目的。如果您想确保数据的耐久性，DynamoDB 已经提供了这种保护措施。该服务可确保耐久性。如果您想保留历史记录的快照（例如，为了符合法规要求），备份一个区域中的表就应该足够了。您可以使用 Amazon Backup 将备份复制到其他区域。如果您想恢复错误删除或修改的数据，请在一个区域中使用时间点故障恢复（PITR）。
如何使用 Amazon CloudFormation 部署全局表？
CloudFormation 将 DynamoDB 表和全局表表示为两个独立的资源：AWS::DynamoDB::Table 和 AWS::DynamoDB::GlobalTable。一种方法是通过使用 GlobalTable 构造来创建所有可能为全局的表。然后，您最初可以将它们保留为独立的表，以后在需要时添加区域。
在 CloudFormation 中，每个全局表都由单个区域中的单个堆栈控制，而与副本的数量无关。部署模板时，CloudFormation 将创建和更新所有副本（作为单个堆栈操作的一部分）。您不应在多个区域中部署相同的 AWS::DynamoDB::GlobalTable 资源。这样做会导致错误，不受支持。如果在多个区域中部署应用程序模板，则可以使用条件在单个区域中创建 AWS::DynamoDB::GlobalTable 资源。或者，您可以选择在独立于应用程序堆栈的堆栈中定义 AWS::DynamoDB::GlobalTable 资源，并确保仅将该资源部署到单个区域。
如果您有一个常规表，并且想要将其转换为全局表，同时保持它由 CloudFormation 管理，则将删除策略设置为“保留”，从堆栈中删除该表，在控制台中将该表转换为全局表，然后将该全局表作为新资源导入到堆栈中。
目前不支持跨账户复制。