# DynamoDB 全局表的准备核对清单
<a name="bp-global-table-design.prescriptive-guidance.checklist-and-faq"></a>

在部署全局表时，请使用下面的决策和任务核对清单。
+ 确定您的使用案例是否从 MRSC 或 MREC 一致性模式中受益更多。即使延迟较高以及存在其他方面的不足，您是否也需要强一致性？
+ 确定全局表应涉及多少个区域以及哪些区域。如果您计划使用 MRSC，请决定希望第三个区域成为副本区域还是见证区域。
+ 确定应用程序的写入模式。这与一致性模式不同。有关更多信息，请参阅 [使用 DynamoDB 全局表的写入模式](bp-global-table-design.prescriptive-guidance.writemodes.md)。
+ 根据写入模式规划您的[DynamoDB 中的路由策略](bp-global-table-design.prescriptive-guidance.request-routing.md)策略。
+ 根据您的一致性模式、写入模式和路由策略，定义[ 撤离过程  使用全局表撤离区域   撤离区域是指将活动（通常是读取和写入活动，也可能是读取活动）从该区域迁移出去的过程。  撤离实时区域实时区域  撤离实时区域   您可能会出于多种原因决定撤离活动区域：作为日常业务活动的一部分（例如，如果您使用“跟随太阳”、“写入一个区域”模式），由于业务决策需要更改当前主动的区域，为了应对 DynamoDB 外部软件堆栈中的故障，或者因为您遇到了一般问题，例如区域内的延迟高于正常水平。 在*写入任何区域*模式下，撤出实时区域很简单。您可以使用任何路由系统将流量路由到备用区域，并让已撤离区域中的写入操作照常复制。 “写入一个区域”模式和“写入您的区域”模式通常与 MREC 表一起使用。因此，在新的主动区域中开始写入操作之前，您必须确保对主动区域的所有写入操作都已完全记录、流处理并全局传播，以确保将来的写入操作是针对最新版本的数据进行处理的。 假设区域 A 处于主动状态，区域 B 处于被动状态（无论是对于整个表，还是对于以区域 A 为主区域的项目）。执行撤离的典型机制是暂停对 A 的写入操作，等待足够长的时间让这些操作完全传播到 B，更新架构堆栈以识别 B 处于主动状态，然后恢复对 B 的写入操作。没有任何指标可以绝对肯定地表明区域 A 已将其数据完全复制到区域 B。如果区域 A 运行状况正常，暂停对区域 A 的写入操作并等待 `ReplicationLatency` 指标的最近最大值的 10 倍，通常足以确定复制完成。如果区域 A 运行状况不佳且显示延迟增加的其他区域，则应为等待时间选择更大的倍数。   撤离离线区域离线区域  撤离离线区域   有一个特殊情况需要考虑：如果区域 A 在没有通知的情况下完全离线，会怎样？ 这种情况发生的可能性极低，但仍应考虑在内。  

撤离离线 MRSC 表  
如果 MRSC 表发生这种情况，您无需执行任何特殊操作。MRSC 表支持恢复点目标（RPO）为零。对离线区域中的 MRSC 表进行的所有成功写入操作都将在所有其他区域表中可用，因此即使区域在未发出通知的情况下完全离线，也不会出现数据缺失的情况。业务可以继续使用位于其他区域的副本。 

撤离离线 MREC 表  
如果 MREC 表发生这种情况，则区域 A 中尚未传播的任何写入操作都将保留，并在区域 A 恢复在线后进行传播。写入操作不会丢失，但它们的传播会被无限期延迟。  
在这种情况下，如何继续操作将由应用程序决定。为了实现业务连续性，写入操作可能需要继续指向新的主区域 B。但是，如果区域 B 中的某个项目收到更新，而针对该项目的写入操作有来自区域 A 的挂起传播，则在*以最后写入者为准*模型下，该传播将被抑制。区域 B 中的任何更新都可能抑制传入的写入请求。  
在*写入任何区域*模式下，可以在区域 B 中继续读取和写入操作，同时相信区域 A 中的项目最终会传播到区域 B，并认识到在区域 A 恢复在线之前可能会丢失项目。如果可能，例如对于幂等的写入操作，您应考虑重播新近的写入流量（例如，使用上游事件源），以填补任何可能缺失的写入操作的空白，并让以最后写入者为准冲突解决方案来抑制传入写入操作的最终传播。  
对于其他写入模式，您必须考虑在多大程度上可以继续工作，而对工作环境的看法稍微过时。在区域 A 恢复在线之前，将丢失一些持续时间很短的写入操作（由 `ReplicationLatency` 跟踪）。业务能否向前推进？ 在某些使用案例中可以向前推进，但在另一些使用案例中，如果没有额外的缓解机制，则可能不行。  
例如，假设即使某个区域完全中断服务，您也必须保持可用的抵扣金余额，不得中断。您可以将余额拆分为两个不同的项目，一个位于主区域 A 中，另一个位于区域 B 中，每个项目从可用余额的一半开始。这将使用*写入您的区域*模式。在每个区域中处理的事务性更新将写入余额的本地副本。如果区域 A 变为完全离线，则仍然可以在区域 B 中继续进行事务处理，写入操作将仅限于区域 B 中持有的余额部分。当余额变低或必须重新计算信贷余额时，像这样拆分余额会带来复杂性，但它确实提供了一个安全业务恢复的示例，即使存在不确定的待处理写入操作。  
再举一个例子，假设您正在捕获 Web 表单数据。您可以使用[乐观并发控制（OCC）](DynamoDBMapper.OptimisticLocking.md)为数据项目分配版本，并将最新版本作为隐藏字段嵌入到 Web 表单中。在每次提交时，只有当数据库中的版本仍然与构建表单所依据的版本相匹配时，写入操作才会成功。如果版本不匹配，则可以根据数据库中的当前版本刷新（或谨慎合并）Web 表单，然后用户可以再次继续。OCC 模型通常可以防止其他客户端覆盖并生成新版本的数据，但它也可以在失效转移期间提供帮助，此时客户端可能会遇到更旧版本的数据。假设您使用时间戳作为版本。表单最初是在 12:00 针对区域 A 构建的，但是（失效转移后）尝试写入区域 B 并注意到数据库中的最新版本是 11:59。在这种情况下，客户端可以等待 12:00 版本传播到区域 B，然后在该版本之上进行写入；也可以在 11:59 上构建并创建新的 12:01 版本（写入后，该版本将在区域 A 恢复后抑制传入版本）。  
第三个例子是，一家金融服务公司在 DynamoDB 数据库中保存有关客户账户及其金融交易的数据。如果区域 A 完全中断，他们希望确保与其账户相关的任何写入活动在区域 B 中完全可用，或者希望将他们的账户作为已知的部分账户进行隔离，直到区域 A 恢复在线。他们没有暂停所有业务，而是决定只对他们确定有未传播交易的一小部分账户暂停业务。为了实现这一点，他们使用了第三个区域，我们称为区域 C。在他们处理区域 A 中的任何写入操作之前，他们在区域 C 中简要地汇总了那些待处理的操作（例如，一个账户的新交易数量）。这个摘要足以让区域 B 确定其视图是否完全是最新的。从在区域 C 中写入操作，到区域 A 接受写入操作并且区域 B 收到写入操作之前，此操作实际上锁定了该账户。除非作为失效转移过程的一部分，否则不会使用区域 C 中的数据，之后，区域 B 可以将其数据与区域 C 进行交叉核对，以检查其账户是否已过期。在区域 A 恢复将部分数据传播到区域 B 之前，这些账户将标记为已隔离。如果区域 C 出现故障，则可以启动一个新的区域 D 以供使用。区域 C 中的数据非常短暂，几分钟后，区域 D 将具有足够新的动态写入操作记录，这将非常有用。如果区域 B 出现故障，区域 A 可以继续接受与区域 C 合作的写入请求。这家公司愿意接受延迟更高的写入（写入到两个区域：C，然后是 A），并且很幸运有了一个可以简洁汇总账户状态的数据模型。   ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title)[撤离过程](bp-global-table-design.prescriptive-guidance.evacuation.md)。
+ 捕获有关每个区域的运行状况、延迟和错误的指标。有关 DynamoDB 指标的列表，请参阅 AWS 博客文章[监控 Amazon DynamoDB 的操作感知](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)，以获取需要观察的指标列表。您还应该使用 [Synthetics Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)（合成金丝雀，旨在检测故障的人工请求，以煤矿中的金丝雀命名），以及实时观察客户流量。并非所有问题都会出现在 DynamoDB 指标中。
+ 如果您使用的是 MREC，请在 `ReplicationLatency` 中为任何持续增长设置警报。增加可能表示意外配置错误，即全局表在不同区域中具有不同的写入设置，这会导致复制请求失败和延迟增加。这也可能表明存在区域中断。一个[很好的例子](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)是，如果最近的平均值超过 180000 毫秒，则生成警报。您可能还会观察到 `ReplicationLatency` 降至 0，这表示复制已停止。
+ 为每个全局表分配足够的最大读取和写入设置。
+ 提前确定撤离某个区域的原因。如果决定涉及人为判断，请记录所有考虑因素。这项工作应该事先仔细完成，而不是在压力下匆匆了事。
+ 为撤离某个区域时必须采取的每项措施制定一份运行手册。通常，全局表所涉及的工作非常少，但是移动堆栈的其余部分可能很复杂。
**注意**  
使用失效转移过程，最佳做法是仅依赖数据面板操作，而不依赖控制面板操作，因为在区域故障期间，某些控制面板操作可能会降级。

   有关更多信息，请参阅 AWS 博客文章[使用 Amazon DynamoDB 全局表构建弹性应用程序：第 4 部分](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/)。
+ 定期测试运行手册的各个方面，包括区域撤离。未经测试的运行手册是不可靠的。
+ 考虑使用 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)来评估整个应用程序（包括全局表）的韧性。通过韧性监测中心的控制面板，您可以全面查看应用程序产品组合的整体弹性状态。
+ 考虑使用 ARC 就绪检查功能来评估应用程序的当前配置，并跟踪与最佳实践的任何偏差。
+ 在编写用于 Route 53 或 Global Accelerator 的运行状况检查时，进行一组覆盖整个数据库流的调用。如果您将检查限制为仅确认 DynamoDB 端点已启动，则无法涵盖许多故障模式，例如 AWS Identity and Access Management（IAM）配置错误、代码部署问题、DynamoDB 外部的堆栈故障、高于平均读取或写入延迟等。

## 有关部署全局表的常见问题解答（FAQ）
<a name="bp-global-table-design.prescriptive-guidance.faq"></a>

**全局表的定价是多少？**
+ 对传统 DynamoDB 表的写入操作按写入容量单位（WCU，用于预调配表）或写入请求单位（WRU，用于按需表）定价。如果您写入一个 5KB 项目，则会产生 5 个单位的费用。对全局表的写入按复制写入容量单位（rWCU，用于预调配表）或复制写入请求单位（rWRU，用于按需表）定价。rWCU 和 rWRU 的价格与 WGU 和 WRU 的价格相同。
+ 在其中直接写入或通过复制写入项目的每个区域都会产生 rWCU 和 rWRU 费用。跨区域数据传输费用适用。
+ 写入全局二级索引（GSI）被视为本地写入操作，使用常规写入单位。
+ 目前 rWCU 或 rWRU 没有可用的预留容量。对于 GSI 消耗写入单位的表，为 WCU 购买预留容量可能仍有好处。
+ 当您将新区域添加到全局表时，DynamoDB 会自动引导新区域，并根据表的大小（GB）向您收取费用，就像表还原一样。还会收取跨区域数据传输费用。

**全局表支持哪些区域？**

[全局表版本 2019.11.21（当前）](GlobalTables.md)对于 MREC 表支持所有 AWS 区域，对于 MRSC 表支持以下区域集：
+ 美国区域集：美国东部（弗吉尼亚州北部）、美国东部（俄亥俄州）、美国西部（俄勒冈州）
+ 欧洲区域集：欧洲地区（爱尔兰）、欧洲地区（伦敦）、欧洲地区（巴黎）、欧洲地区（法兰克福）
+ 亚太地区区域集：亚太地区（东京）、亚太地区（首尔）和亚太地区（大阪）

**如何使用全局表处理 GSI？**

在[全局表版本 2019.11.21（当前版）](GlobalTables.md)中，当您在一个区域中创建 GSI 时，它会在其它参与区域中自动创建并自动回填。

**如何停止复制全局表？** 
+ 您可以像删除任何其他表一样删除副本表。删除全局表将停止复制到该区域，并删除保留在该区域中的表副本。但是，不能在将表的副本保留为独立实体时停止复制，也不能暂停复制。
+ MRSC 表必须部署在恰好三个区域中。要删除副本，您必须删除所有副本和见证者，以使 MRSC 表成为本地表。

**DynamoDB Streams 如何与全局表交互？**
+ 每个全局表都基于其所有写入操作生成一个独立的流，而无论这些写入是从何处开始的。您可以选择在一个区域或在所有区域中（独立）使用 DynamoDB 流。如果您想要处理本地而不是复制的写入操作，则可以向每个项目添加您自己的区域属性，以确定写入区域。然后，您可以使用 Lambda 事件筛选条件，以便只调用 Lambda 函数来处理本地区域中的写入操作。这有助于执行插入和更新操作，但不能执行删除操作。
+ 配置为多区域最终一致性的全局表（MREC 表）可通过从副本表上的 DynamoDB 流读取这些更改，并将该更改应用于所有其他副本表，从而复制更改。因此，默认情况下，对 MREC 全局表中的所有副本都启用了 DynamoDB，并且无法在这些副本上禁用。MREC 复制过程可能会在短时间内将多项更改合并到单个复制写入操作中。因此，每个副本的流均可能包含略有不同的记录。MREC 副本上的 DynamoDB Streams 记录始终按每个项目排序，但项目间的排序可能在副本之间有所不同。
+ 配置为多区域强一致性的全局表（MRSC 表）不使用 DynamoDB Streams 进行复制，因此默认情况下不在 MRSC 副本上启用此功能。您可以在 MRSC 副本上启用 DynamoDB Streams。MRSC 副本上的 DynamoDB Streams 记录对于每个副本都是相同的，并且始终按项目排序，但项目之间的排序在副本之间可能有所不同。

**全局表如何处理事务？** 
+ 对 MRSC 表的事务操作会生成错误。
+ 对 MREC 表的事务操作，仅在最初发生写入操作的区域内提供原子性、一致性、隔离性和持久性（ACID）保证。全局表中不支持跨区域的事务。例如，如果您有一个 MREC 全局表，该表在美国东部（俄亥俄州）和美国西部（俄勒冈州）区域中具有副本，并且在美国东部（俄亥俄州）区域中执行 `TransactWriteItems` 操作，则在复制更改时，可能会在美国西部（俄勒冈州）区域观察到部分完成的事务。更改仅在源区域中提交后才复制到其他区域。

**全局表如何与 DynamoDB Accelerator 缓存（DAX）交互？**

全局表通过直接更新 DynamoDB 绕过 DAX，因此 DAX 并不知道它保存的是陈旧数据。DAX 缓存只有在缓存的 TTL 过期时才会刷新。

**表上的标签会传播吗？**

不，标签不会自动传播。

**我应该备份所有区域中的表，还是只备份一个区域中的表？**

答案取决于备份的目的。
+ 如果您想确保数据的耐久性，DynamoDB 已经提供了这种保护措施。该服务可确保耐久性。
+ 如果您想保留历史记录的快照（例如，为了符合法规要求），备份一个区域中的表就应该足够了。您可以使用 将备份复制到其他区域AWS Backup
+ 如果您想恢复错误删除或修改的数据，请在一个区域中使用 [DynamoDB 时间点故障恢复（PITR）](PointInTimeRecovery_Howitworks.md)。

**如何使用 CloudFormation 部署全局表？**
+ CloudFormation 将 DynamoDB 表和全局表表示为两个独立的资源：`AWS::DynamoDB::Table` 和 `AWS::DynamoDB::GlobalTable`。一种方法是使用 `GlobalTable` 构造来创建所有可能成为全局表的表，最初将其保留为独立的表，然后在以后需要时再添加区域。
+ 在 CloudFormation 中，每个全局表都由单个区域中的单个堆栈控制，而与副本的数量无关。部署模板时，CloudFormation 将创建和更新所有副本（作为单个堆栈操作的一部分）。您不应在多个区域中部署相同的 [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) 资源。这样做会导致错误，不受支持。如果在多个区域中部署应用程序模板，则可以使用条件在单个区域中创建 `AWS::DynamoDB::GlobalTable` 资源。或者，您可以选择在独立于应用程序堆栈的堆栈中定义 `AWS::DynamoDB::GlobalTable` 资源，并确保仅将该资源部署到单个区域。
+ 如果您有一个常规表，并且想要将其转换为全局表，同时保持它由 CloudFormation 管理，则将删除策略设置为 `Retain`，从堆栈中删除该表，在控制台中将该表转换为全局表，然后将该全局表作为新资源导入到堆栈中。有关更多信息，请参阅 [AWS GitHub 存储库](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk)。
+ 目前不支持跨账户复制。