本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
在 Neptune 全球数据库中使用失效转移
Neptune 全球数据库提供的失效转移功能比独立 Neptune 数据库集群提供的失效转移功能更全面。使用全球数据库，您可以对灾难进行规划并很快地从灾难中恢复。通常使用对恢复时间目标 (RTO) 和恢复点目标 (RPO) 的评测来评测灾难恢复：
恢复时间目标 (RTO) — 灾难后系统恢复工作状态的速度。换言之，RTO 用于衡量停机时间。对于 Neptune 全球数据库，RTO 大约为数分钟。
恢复点目标 (RPO) — 数据丢失的时间段。对于 Neptune 全球数据库，RPO 通常以秒为单位进行测量（请参阅执行 Neptune 全球数据库的托管式计划内失效转移）。
对于 Neptune 全球数据库，失效转移方法有两种不同的方法：
分离并提升（手动计划外恢复）— 要从计划外停机中恢复或进行灾难恢复测试（DR 测试），您可以对全球数据库中的辅助数据库集群之一执行跨区域分离并提升。此手动过程的 RTO 取决于您执行 分离并提升 中列出的任务的速度。RPO 通常为数秒，但这取决于发生故障时整个网络的存储复制滞后时间。
托管式计划内失效转移 — 此方法适用于操作维护和其它计划内操作过程，例如将全球数据库的主数据库集群迁移到辅助区域之一。由于此过程会在进行任何其它更改之前将辅助数据库集群与主数据库集群同步，因此 RPO 实际上为 0（也即不会造成数据丢失）。请参阅执行 Neptune 全球数据库的托管式计划内失效转移。
在计划外停机时分离并提升 Neptune 全球数据库
在极少数情况下，Neptune 全球数据库在主 Amazon Web Services 区域中发生意外中断，主 Neptune 数据库集群及其写入器节点将变得不可用，且主集群和辅助集群之间的复制将停止。为了最大限度地减少由此产生的停机时间 (RTO) 和数据丢失 (RPO)，请快速执行跨区域分离和提升以重建全球数据库。
提示
在使用此过程之前，最好先了解一下该过程，并制定一个计划，以便在出现区域范围问题的第一个迹象时迅速采取行动。
定期使用 Amazon CloudWatch 来跟踪辅助集群的滞后时间，以便在需要失效转移时，您可以确定滞后时间最小的辅助区域。
确保测试您的计划，以检查过程是否完整和准确。
使用模拟环境以确保您的员工接受过培训，准备好在必要时快速执行灾难恢复失效转移。
在主区域发生计划外停机后失效转移到辅助集群
停止在主数据库集群上发出突变查询和其它写入操作。
在辅助 Amazon Web Services 区域中确定一个数据库集群，以用作全球数据库的新主数据库集群。如果全球数据库有两个或更多辅助 Amazon Web Services 区域，请选择滞后时间最小的辅助集群。
-
从 Neptune 全球数据库中分离您选择的辅助数据库集群。
从 Neptune 全球数据库中移除辅助数据库集群会立即停止将数据从主数据库集群复制到该辅助数据库集群的过程，并会将其提升为拥有完全读/写功能的独立数据库集群。全球数据库中的任何其它辅助集群仍可用，并且可以接受来自应用程序的读取调用。
在重新创建 Neptune 全球数据库之前，您还必须分离其它辅助集群，以避免集群间的数据不一致（请参阅移除集群）。
-
重新配置应用程序，以使用新的端点将所有写入操作发送到您选择成为新主集群的独立 Neptune 数据库集群。如果您在创建 Neptune 全球数据库时接受了默认名称，则可以在应用程序中从集群的端点字符串中移除
-ro以更改端点。例如，辅助集群的端点
my-global.cluster-ro-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com将在该集群从全球数据库分离时变为my-global.cluster-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com。在下一步中，当您开始向此 Neptune 数据库集群添加区域时，该 Neptune 数据库集群将成为新的 Neptune 全球数据库的主集群。
向数据库集群添加 Amazon Web Services 区域。执行此操作后，从主数据库集群到辅助数据库集群的复制过程将会开始。请参阅在 Amazon Neptune 中向主区域添加辅助全球数据库区域 。
根据需要添加更多 Amazon Web Services 区域，以重新创建为了支持应用程序所需的拓扑。
确保在进行这些更改之前、期间和之后，将应用程序写入发送到正确的 Neptune 数据库集群。这样做可以避免 Neptune 全球数据库中数据库集群之间的数据不一致（这些问题称为脑裂问题）。
执行 Neptune 全球数据库的托管式计划内失效转移
托管式计划内失效转移允许您将 Neptune 全球数据库的主集群重新定位到您选择的不同 Amazon Web Services 区域。一些组织希望定期轮换其主集群位置。
注意
此处介绍的托管式计划内失效转移适合在运行正常的 Neptune 全球数据库上使用。要从计划外停机中恢复或进行灾难恢复 (DR) 测试，请改为按照分离并提升过程进行操作。
在托管式计划内失效转移期间，主集群会将失效转移到您选择的辅助区域，同时保留全球数据库的现有复制拓扑。在托管式计划内失效转移过程开始之前，全球数据库会将所有辅助集群与其主集群同步。确保所有集群都同步后，托管的计划内故障转移才会开始。主区域中的数据库集群变为只读的，所选辅助集群将其一个只读实例提升为完全写入器状态，从而允许该集群担任主集群的角色。由于所有辅助集群在过程开始时都与主集群同步，因此新的主集群将继续执行全球数据库的操作，而不会丢失任何数据。数据库仅在短时间内不可用，而主集群和所选的辅助集群将担任其新角色。
要优化应用程序可用性，您可以在非高峰时间段（向主数据库集群写入操作最少的时候）执行失效转移。此外，在开始失效转移之前，请采取以下步骤：
尽可能使应用程序离线，以减少对主集群的写入。
检查全球数据库中所有辅助 Neptune 数据库集群的滞后时间，然后选择总体滞后时间最少的辅助集群成为主集群。使用 Amazon CloudWatch 查看所有辅助数据库集群的
NeptuneGlobalDBProgressLag指标。此指标会指出辅助数据库集群滞后于主数据库集群的时间（以毫秒为单位）。它的值与 Neptune 完成失效转移所需的时间成正比。换言之，滞后值越大，失效转移停机时间越长，因此请选择滞后值最小的辅助数据库集群。参阅 Neptun CloudWatch e 指标 了解更多信息。
在托管式计划内失效转移期间，所选的辅助数据库集群将提升为新角色（即主数据库集群），但它不会继承主数据库集群的完全配置。配置不匹配可能会导致性能问题、工作负载不兼容和其他异常行为。要避免此类问题，请在失效转移之前解决全球数据库集群之间的以下几种配置差异：
在新的主数据库集群中配置参数以匹配当前主数据库集群。
配置监控工具、选项和警报 — 配置将成为新的主数据库集群的数据库集群，该集群与当前主数据库具有相同的日志记录功能、警报等。
配置与其它 Amazon 服务的集成 — 如果 Neptune 全球数据库与 Amazon 服务集成，如 Amazon Identity and Access Management (IAM)、Amazon S3 或 Amazon Lambda，请确保根据需要配置这些服务，以便与新的主数据库集群集成。
当失效转移过程完成并且提升的数据库集群已准备好处理全球数据库的写入操作时，请确保更改您的应用程序以使用新的主数据库的新端点。
使用 Amazon CLI 启动托管式计划内失效转移
使用 failover-global-cluster CLI 命令（封装 FailoverGlobalCluster API）对您的 Neptune 全球数据库进行失效转移：
aws neptune failover-global-cluster \ --region(the region where the primary cluster is located)\ --global-cluster-identifier(global database ID)\ --target-db-cluster-identifier(the ARN of the secondary DB cluster to promote)
注意
failover-global-cluster API 在预览版中不可用。它将成为 GA 版本的一部分。