自动化 DR 策略

您可以选择实现完全或部分自动化，以更好地控制灾难恢复。如果您使用的是备份和还原 DR 选项，则可以使用 AWS Backup 自动进行备份，它支持所有 Amazon RDS 数据库以及 DynamoDB、Amazon DocumentDB 和 Amazon Neptune 表。

灾难事件检测

为了缩短恢复时间，您可以考虑自动检测区域范围的事件，然后就能启用至 DR 区域的失效转移。要实施自动检测以实现更积极的 RTO，您可以根据运行状况检查构建解决方案。这些运行状况检查不只停留于检测信号（也就是检查网络中的控制面板和数据面板模块是否可以相互通信），而是更深入地评估应用程序组件的相互关联性质，以实现准确的预测。但是，自动化解决方案可能会带来误报的风险，从而导致不必要的失效转移。在这种情况下，您应该谨慎行事，因为不必要的失效转移会给您的业务带来可用性问题。您还可以在工作流程中构建手动覆盖，以确认已执行失效转移。您可以订阅服务运行状况控制面板 RSS 源，随时了解服务级别中断情况。此外，您还可以使用主区域和 AWS 账户中的 AWS Health Dashboard（需要账户）来随时了解可能影响您账户的事件。这可以帮助您做出明智的决定，以便在发生区域范围的活动时进行失效转移。

失效转移

无论您选择哪种 DR 策略，您都可以构建自定义 DR 自动化解决方案，来执行至 DR 区域的失效转移。这种自动化可以最大限度地减少对手动干预的需求，并在测试 DR 解决方案时提供更好的控制。您可以根据组织的偏好从该AWS 服务中进行选择 APIs，该服务 AWS 提供多种语言 JavaScript，例如 Python、PHP、.NET、Ruby、Java、Go、Node.js 和 C++。要构建使用这些 AWS 服务的自动化 APIs，您应该首先专注于将数据库基础架构转换为我们的 Terraf AWS CloudFormation orm 模板形式的代码。这些模板可以帮助您自动化多个数据库的失效转移，还可以保持应用程序和数据库组件在 DR 区域中的备份顺序。

出于 DR 的需要，我们建议您专注于以下两个目标：

• 现有CloudFormation 堆栈应导出有关您的数据库的相关信息，包括实例名称和终端节点。您的自动化流程可以参考区域内的这些导出值，并执行有助于 DR 操作的操作。

• 如果您的资源已投入生产但没有关联 CloudFormation堆栈，则应专注于为这些资源创建堆栈。还要确保这些堆栈覆盖正确的导出值，如前面所述。

当你实现了这两个目标后，你可以用组织选择的语言构建自动化解决方案，以利用 CloudFormation 导出的优势，并在发生灾难时自动执行所需的切换操作。例如，如果您有一个 ElastiCache （Redis OSS）全球数据存储作为 CloudFormation 模板部署，则自动化代码可以访问提供有关全局数据存储详细信息的 CloudFormation 导出。发生灾难时，代码可以使用 ElastiCache (Redis OSS) 服务自动将辅助数据存储升级为主数据存储，而无需任何手动干预。 APIs

在一般场景中，自动化应当可以针对组织内的多个数据库进行扩展。您可以使用 AWS Step Functions 或 AWS Batch 扩展多个数据库的自动化解决方案。