本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 執行災難復原 Amazon Neptune
Neptune 全球資料庫提供的容錯移轉功能比獨立 Neptune 資料庫叢集提供的更加全面。使用全球資料庫，您可以相當快速地規劃並從災難復原。評估災難復原的方式通常會使用復原時間點目標 (RTO) 和復原點目標 (RPO) 的評估：
+ **復原時間點目標 (RTO)** — 這是系統在災難發生後回到工作狀態的速度。換言之，RTO 會測量停機時間。對於 Neptune 全球資料庫，RTO 可能需要幾分鐘。
+ **復原點目標 (RPO)** — 遺失資料期間的時間量。對於 Neptune 全球資料庫，RPO 通常以秒為單位進行測量 (請參閱 [執行 Neptune 全球資料庫的受管計劃容錯移轉](#neptune-gdb-managed-failover))。
對於 Neptune 全球資料庫，有兩種不同的容錯移轉方法：
+ **分離並提升 (手動非計劃復原)** — 若要從非計畫中斷復原或執行災難復原測試 (DR 測試)，請對全球資料庫中的其中一個次要資料庫叢集執行跨區域分離並提升。此手動程序的 RTO 取決於您在 [分離並提升](#neptune-gdb-detach-and-promote) 中執行所列任務的速度。RPO 通常為幾秒，但這取決於發生故障時網路上的儲存體複寫延遲。
+ **受管計劃容錯移轉** — 此方法適用於操作維護和其他計劃操作程序，例如將全球資料庫的主要資料庫叢集重新放置到其中一個次要區域。由於此程序會將次要資料庫叢集與主要資料庫叢集同步，再做出任何其他變更，因此 RPO 實際為 0 (亦即，不會遺失任何資料)。請參閱 [執行 Neptune 全球資料庫的受管計劃容錯移轉](#neptune-gdb-managed-failover)。
## 在發生非計劃中斷時分離並提升 Neptune 全球資料庫
在極少數情況下，您的 Neptune 全球資料庫在其主要資料庫發生意外中斷時 AWS 區域，您的主要 Neptune 資料庫叢集及其寫入器節點將無法使用，且主要叢集與次要叢集之間的複寫會停止。若要將產生的停機時間 (RTO) 和資料遺失 (RPO) 減至最低，請快速執行跨區域分離並提升，以重建全球資料庫。
**提示**
最好在使用此程序之前先對其有所了解，並制定一個適當的計劃，以在全區域問題第一次出現時便立即快速進行該計劃。
定期使用 Amazon CloudWatch 追蹤次要叢集的延遲時間，以便您可以在需要容錯移轉時，識別延遲時間最短的次要區域。
請務必測試您的計畫，以檢查您的程序是否完整且準確。
使用模擬環境來確保您的員工受過訓練，並準備好在必要時快速執行 DR 容錯移轉。
**在主要區域發生非計劃中斷之後容錯移轉至次要叢集**
1. 停止在主資料庫叢集上發出變動查詢和其他寫入操作。
1. 識別次要 中的資料庫叢集 AWS 區域 ，以用作全域資料庫的新主要資料庫叢集。如果全球資料庫有兩個以上的次要 AWS 區域，請選擇延遲時間最低的次要叢集。
1. 從 Neptune 全球資料庫中分離您選擇的次要資料庫叢集。
從 Neptune 全球資料庫中移除次要資料庫叢集，會立即停止將資料從主要資料庫叢集複寫到該次要資料庫叢集，並將其提升為具有完整讀取/寫入功能的獨立資料庫叢集。全球資料庫中的任何其他次要叢集仍可供使用，而且可以接受來自您應用程式的讀取呼叫。
在重新建立 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 全球資料庫的主要叢集。
1. 將 AWS 區域 新增至資料庫叢集。當您執行這項操作時，從主要到次要的複寫程序即會開始。請參閱 [將次要全球資料庫區域新增至 Amazon Neptune 的主要區域](neptune-gdb-setup.md#neptune-gdb-attaching)。
1. AWS 區域 視需要新增更多 ，以重新建立支援應用程式所需的拓撲。
請確定應用程式寫入會在做出這些變更之前、期間和之後，傳送至正確的 Neptune 資料庫叢集。這樣可以避免 Neptune 全球資料庫中的資料庫叢集之間出現資料不一致的情況 (這些稱為核心分裂問題)。
## 執行 Neptune 全球資料庫的受管計劃容錯移轉
受管計劃容錯移轉可讓您 AWS 區域 隨時將 Neptune 全域資料庫的主要叢集重新定位為不同的叢集。有些組織會想要定期輪換其主要叢集位置。
**注意**
這裡描述的受管計劃容錯移轉旨在用於運作狀態良好的 Neptune 全球資料庫。若要從非計劃中斷復原或執行災難復原 (DR) 測試，請改為遵循[分離並提升](#neptune-gdb-detach-and-promote)程序。
在受管計劃容錯移轉期間，您的主要叢集會容錯移轉至您選擇的次要區域，同時保留全球資料庫現有的複寫拓撲。在受管計劃容錯移轉程序開始之前，全球資料庫會將所有次要叢集與其主要叢集同步。確保所有叢集都已同步之後，受管計劃容錯移轉即會開始。主要區域中的資料庫叢集會變成唯讀，而選擇的次要叢集會將其中一個唯讀執行個體提升為完整寫入器狀態，從而允許叢集擔任主要叢集的角色。由於所有次要叢集都在程序開始時與主要叢集同步，因此新的主要叢集會繼續執行全球資料庫的操作，而不會遺失任何資料。此資料庫在短時間內無法使用，因為同時間主要叢集和選取的次要叢集會擔任其新角色。
若要最佳化應用程式可用性，請在寫入主要資料庫叢集最少的非尖峰時段執行容錯移轉。此外，在開始容錯移轉之前採取下列步驟：
+ 盡可能讓應用程式離線，以減少對主要叢集的寫入。
+ 檢查全球資料庫中所有次要 Neptune 資料庫叢集的延遲時間，並選擇整體延遲時間最低的次要叢集成為主要叢集。使用 Amazon CloudWatch 來檢視所有次要資料庫叢集的 `NeptuneGlobalDBProgressLag` 指標。此指標會告訴您，次要資料庫叢集與主要資料庫叢集的差距 (以毫秒為單位)。其值直接與 Neptune 完成容錯移轉所需的時間成正比。換言之，延遲值越大，容錯移轉中斷時間就越長，因此請選擇延遲最低的次要叢集。如需詳細資訊，請參閱[Neptune CloudWatch 指標](cw-metrics.md)。
在受管計劃容錯移轉期間，選擇的次要資料庫叢集會提升為作為主要資料庫叢集的新角色，但其不會繼承主要資料庫叢集的完整組態。組態不相符可能會導致效能問題、工作負載不相容，以及其他異常行為。若要避免這類問題，請在容錯移轉之前先解決全球資料庫叢集之間下列種類的組態差異：
+ **在新的主要叢集中設定參數以符合目前的主要叢集**。
+ **設定監控工具、選項和警示** — 設定將成為新主要叢集的資料庫叢集，其具有的記錄功能、警示等等與目前主要叢集具有的相同。
+ **設定與其他 AWS 服務的整合** — 如果您的 Neptune 全域資料庫與 AWS 服務整合，例如 AWS Identity and Access Management (IAM)、Amazon S3 或 AWS Lambda，請確定這些服務已視需要設定為與新的主要資料庫叢集整合。
當容錯移轉程序完成且提升的資料庫叢集已準備好處理全球資料庫的寫入操作時，請務必變更您的應用程式，以將新的端點用於新的主要叢集。
### 使用 AWS CLI 啟動受管計劃容錯移轉
使用 [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)
```