本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 执行灾难恢复 Amazon Neptune
<a name="neptune-gdb-disaster-recovery"></a>

Neptune 全球数据库提供的失效转移功能比独立 Neptune 数据库集群提供的失效转移功能更全面。使用全球数据库，您可以对灾难进行规划并很快地从灾难中恢复。通常使用对恢复时间目标 (RTO) 和恢复点目标 (RPO) 的评测来评测灾难恢复：
+ **恢复时间目标 (RTO) **— 灾难后系统恢复工作状态的速度。换言之，RTO 用于衡量停机时间。对于 Neptune 全球数据库，RTO 大约为数分钟。
+ **恢复点目标 (RPO)** — 数据丢失的时间段。对于 Neptune 全球数据库，RPO 通常以秒为单位进行测量（请参阅[执行 Neptune 全球数据库的托管式计划内失效转移](#neptune-gdb-managed-failover)）。

对于 Neptune 全球数据库，失效转移方法有两种不同的方法：
+ **Detach-and-promote （手动计划外恢复）**— 要从计划外中断中恢复或进行灾难恢复测试（灾难恢复测试），请在全局数据库中的一个辅助数据库集群 detach-and-promote上执行跨区域操作。此手动过程的 RTO 取决于您执行 [分离并提升](#neptune-gdb-detach-and-promote) 中列出的任务的速度。RPO 通常为数秒，但这取决于发生故障时整个网络的存储复制滞后时间。
+ **托管式计划内失效转移** — 此方法适用于操作维护和其它计划内操作过程，例如将全球数据库的主数据库集群迁移到辅助区域之一。由于此过程会在进行任何其它更改之前将辅助数据库集群与主数据库集群同步，因此 RPO 实际上为 0（也即不会造成数据丢失）。请参阅[执行 Neptune 全球数据库的托管式计划内失效转移](#neptune-gdb-managed-failover)。

## Detach-and-promote 计划外停机时使用 Neptune 全球数据库
<a name="neptune-gdb-detach-and-promote"></a>

在极少数情况下，您的 Neptune 全局数据库在主数据库中出现意外中断 AWS 区域，您的主 Neptune 数据库集群及其写入节点将不可用，并且主集群和辅助集群之间的复制将停止。要最大限度地减少由此产生的停机时间 (RTO) 和数据丢失 (RPO)，请快速执行跨区域 detach-and-promote重建全球数据库。

**提示**  
在使用此过程之前，最好先了解一下该过程，并制定一个计划，以便在出现区域范围问题的第一个迹象时迅速采取行动。  
 CloudWatch 定期使用 Amazon 跟踪辅助集群的延迟时间，以便在需要进行故障转移时可以确定延迟时间最小的辅助区域。
确保测试您的计划，以检查过程是否完整和准确。
使用模拟环境以确保您的员工接受过培训，准备好在必要时快速执行灾难恢复失效转移。

**在主区域发生计划外停机后失效转移到辅助集群**

1. 停止在主数据库集群上发出突变查询和其它写入操作。

1. 在辅助数据库中标识一个数据库集群 AWS 区域 以用作全局数据库的新主数据库集群。如果全球数据库有两个或更多辅助 AWS 区域，请选择滞后时间最小的辅助集群。

1. 从 Neptune 全球数据库中分离您选择的辅助数据库集群。

   从 Neptune 全局数据库中移除辅助数据库集群会立即停止将数据从主数据库群集复制到该辅助数据库群集，并将其提升为具有完整 read/write 功能的独立数据库集群。全球数据库中的任何其它辅助集群仍可用，并且可以接受来自应用程序的读取调用。

   在重新创建 Neptune 全球数据库之前，您还必须分离其它辅助集群，以避免集群间的数据不一致（请参阅[移除集群](neptune-gdb-detaching.md)）。

1. 重新配置应用程序，以使用新的端点将所有写入操作发送到您选择成为新主集群的独立 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 全球数据库的主集群。

1. 向 AWS 区域 数据库集群添加。执行此操作后，从主数据库集群到辅助数据库集群的复制过程将会开始。请参阅[在 Amazon Neptune 中向主区域添加辅助全球数据库区域](neptune-gdb-setup.md#neptune-gdb-attaching)。

1. 根据需要添加更多内容 AWS 区域 ，以重新创建支持您的应用程序所需的拓扑。

确保在进行这些更改之前、期间和之后，将应用程序写入发送到正确的 Neptune 数据库集群。这样做可以避免 Neptune 全球数据库中数据库集群之间的数据不一致（这些问题称为脑裂问题）。

## 执行 Neptune 全球数据库的托管式计划内失效转移
<a name="neptune-gdb-managed-failover"></a>

托管计划内故障转移允许您随时将 Neptune 全局数据库的主群集迁移到 AWS 区域 其他群集。一些组织希望定期轮换其主集群位置。

**注意**  
此处介绍的托管式计划内失效转移适合在运行正常的 Neptune 全球数据库上使用。要从计划外停机中恢复或进行灾难恢复 (DR) 测试，请改为按照[分离并提升](#neptune-gdb-detach-and-promote)过程进行操作。

在托管式计划内失效转移期间，主集群会将失效转移到您选择的辅助区域，同时保留全球数据库的现有复制拓扑。在托管式计划内失效转移过程开始之前，全球数据库会将所有辅助集群与其主集群同步。确保所有集群都同步后，托管的计划内故障转移才会开始。主区域中的数据库集群变为只读的，所选辅助集群将其一个只读实例提升为完全写入器状态，从而允许该集群担任主集群的角色。由于所有辅助集群在过程开始时都与主集群同步，因此新的主集群将继续执行全球数据库的操作，而不会丢失任何数据。数据库仅在短时间内不可用，而主集群和所选的辅助集群将担任其新角色。

要优化应用程序可用性，您可以在非高峰时间段（向主数据库集群写入操作最少的时候）执行失效转移。此外，在开始失效转移之前，请采取以下步骤：
+ 尽可能使应用程序离线，以减少对主集群的写入。
+ 检查全球数据库中所有辅助 Neptune 数据库集群的滞后时间，然后选择总体滞后时间最少的辅助集群成为主集群。使用 Amazon CloudWatch 查看所有辅助`NeptuneGlobalDBProgressLag`指标的指标。此指标会指出辅助数据库集群滞后于主数据库集群的时间（以毫秒为单位）。它的值与 Neptune 完成失效转移所需的时间成正比。换言之，滞后值越大，失效转移停机时间越长，因此请选择滞后值最小的辅助数据库集群。请参阅[Neptun CloudWatch e 指标](cw-metrics.md)了解更多信息。

在托管式计划内失效转移期间，所选的辅助数据库集群将提升为新角色（即主数据库集群），但它不会继承主数据库集群的完全配置。配置不匹配可能会导致性能问题、工作负载不兼容和其他异常行为。要避免此类问题，请在失效转移之前解决全球数据库集群之间的以下几种配置差异：
+ **在新的主数据库集群中配置参数以匹配当前主数据库集群**。
+ **配置监控工具、选项和警报** — 配置将成为新的主数据库集群的数据库集群，该集群与当前主数据库具有相同的日志记录功能、警报等。
+ **配置与其他 AWS 服务的集成** — 如果您的 Neptune 全球数据库 AWS 与 (IAM)、Amazon S3 AWS Lambda或 AWS Identity and Access Management 等服务集成，请确保根据需要配置这些服务以与新的主数据库集群集集成。

当失效转移过程完成并且提升的数据库集群已准备好处理全球数据库的写入操作时，请确保更改您的应用程序以使用新的主数据库的新端点。

### 使用启动 AWS CLI 托管计划内故障转移
<a name="neptune-gdb-managed-failover-cli"></a>

使用 [failover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-global-cluster.html)CLI 命令（包装 [FailoverGlobalCluster](api-global-dbs.md#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)
```