在 Amazon Aurora Global Database 中使用切換或容錯移轉 - Amazon Aurora

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

在 Amazon Aurora Global Database 中使用切換或容錯移轉

Aurora Global Database 功能比 Aurora 資料庫叢集在單一叢集中提供的標準高可用性提供更多的業務持續性和災難復原 (BCDR) 保護 AWS 區域。透過使用 Aurora Global Database,您可以計劃更快地從罕見、意外的區域災難復原,或快速完成服務層級中斷。

您可以使用 Aurora Global Database 功能,參閱下列指引和程序來規劃、測試和實作BCDR策略。

規劃業務持續性和災難復原

若要規劃您的業務持續性和災難復原策略,了解下列產業術語以及這些術語與 Aurora Global Database 功能有何關聯會很有幫助。

災難復原通常是由以下兩個業務目標推動:

  • 復原時間目標 (RTO) – 在災難或服務中斷後,系統返回工作狀態所需的時間。換句話說, RTO會測量停機時間。對於 Aurora Global Database, RTO可以按分鐘的順序排列。

  • 復原點目標 (RPO) – 災難或服務中斷後可能遺失的資料量 (按時間測量)。此資料遺失通常是因為非同步複寫延遲所致。對於 Aurora 全域資料庫, RPO 通常以秒為單位。使用 Aurora Postgre SQL型全域資料庫,您可以使用 rds.global_db_rpo 參數來設定和追蹤 的上限RPO,但這樣做可能會影響主要叢集寫入器節點上的交易處理。如需詳細資訊,請參閱RPOs 管理SQL以 Aurora Postgre 為基礎的全域資料庫

使用 Aurora Global Database 執行切換或容錯移轉需要將次要資料庫叢集提升為主要資料庫叢集。「區域中斷」一詞通常用來描述各種故障情況。最壞的情況可能是影響數百平方英里的災難性事件導致大規模中斷。不過,大多數中斷都較侷限在本地,只會影響一小部分的雲端服務或客戶系統。請考量完整的中斷範圍,以確定跨區域容錯移轉是適當的解決方案,並選擇適當的容錯移轉方法來因應此情況。應該使用容錯移轉或轉換方法,取決於特定中斷案例:

  • 容錯移轉 - 使用此方法從意外中斷的情況復原。使用此方法時,您會以 Aurora 全球資料庫中的次要資料庫叢集之一為目標,進行跨區域容錯移轉。此方法RPO的 通常是以秒為單位測量的非零值。資料遺失量取決於發生故障 AWS 區域 時跨 的 Aurora 全域資料庫複寫延遲。如需進一步了解,請參閱 從計劃外中斷復原 Amazon Aurora 全域資料庫

  • 切換 – 此操作先前稱為「受管計劃容錯移轉」。將此方法用於受控案例,例如操作維護和其他規劃的操作程序,其中所有與之互動的 Aurora 叢集和其他服務都處於良好狀態。由於此功能會在進行任何其他變更之前,先將次要資料庫叢集與主要叢集同步,因此 RPO為 0 (不會遺失資料)。如需進一步了解,請參閱 針對 Amazon Aurora 全球資料庫執行轉換

注意

您必須先新增資料庫執行個體,才能執行無周邊次要 Aurora 資料庫叢集的切換或容錯移轉。如需無周邊資料庫叢集的詳細資訊,請參閱 在次要區域中建立無周邊 Aurora 資料庫叢集

針對 Amazon Aurora 全球資料庫執行轉換

注意

切換先前稱為受管計劃容錯移轉

透過使用切換,您可以定期變更主要叢集的區域。此方法適用於受控情況,例如操作維護及其他計劃內操作程序。

有三種常見的轉換使用案例。

  • 對於特定行業強制實施的「區域輪換」需求。例如,金融服務法規可能希望第 0 層系統切換到不同的區域數個月時間,以確保定期演練災難復原程序。

  • 對於多區域「follow-the-sun」應用程式。例如,某家公司可能希望根據不同時區的營業時間,在不同區域提供較低的延遲寫入。

  • 作為 zero-data-loss容錯移轉後容錯移轉回原始主要區域的方法。

注意

切換旨在用於 Aurora 全域資料庫,其中與之互動的所有 Aurora 叢集和其他服務都處於良好狀態。若要從意外中斷復原,請依照 從計劃外中斷復原 Amazon Aurora 全域資料庫 中適當的程序進行。

只有在主要和次要資料庫叢集具有相同的主要和次要引擎版本時,才能使用 Aurora Global Database 執行受管跨區域切換。根據引擎和引擎版本,修補層級可能需要相同,或者修補層級可能不同。如需允許具有不同修補程式層級之主要和次要叢集之間這些操作的引擎和引擎版本清單,請參閱 受管跨區域轉換和容錯移轉的修補程式等級相容性。開始轉換之前,請先檢查全域叢集中的引擎版本,以確定它們可支援受管跨區域轉換,並視需要進行升級。

在切換期間,Aurora 會讓所選次要區域中的叢集成為您的主要叢集。切換機制會維護您全域資料庫的現有複寫拓撲:它在相同區域中仍具有相同數量的 Aurora 叢集。在 Aurora 開始切換程序之前,它會等待所有次要區域叢集與主要區域叢集完全同步。然後,主要區域中的資料庫叢集會變成唯讀。所選的次要叢集會將其中一個唯讀節點提升為完整寫入器狀態,讓該次要叢集擔任主要叢集的角色。由於所有次要叢集都在處理程序開始時與主要叢集同步,因此新的主要叢集會繼續執行 Aurora 全域資料庫的操作,而不會遺失任何資料。您的資料庫在短時間內無法使用,因為同時間主要叢集和選取的次要叢集會承擔其新角色。

若要最佳化應用程式可用性,建議您在使用此功能之前先執行下列動作:

  • 在非尖峰時段或在寫入主要資料庫叢集最少時,執行此操作。

  • 檢查 Aurora 全域資料庫中所有次要 Aurora 資料庫叢集的延遲時間。對於所有 Aurora Postgre SQL型全域資料庫,以及從引擎 3.04.0 版及更新版本或 2.12.0 版及更新版本開始的 Aurora My SQL型全域資料庫,請使用 Amazon CloudWatch 來檢視所有次要資料庫叢集的AuroraGlobalDBRPOLag指標。如需 Aurora My SQL型全域資料庫的次要版本,請改為檢視 AuroraGlobalDBReplicationLag 指標。這些指標顯示複寫至次要資料庫叢集與複寫至主要資料庫叢集之間的差距 (以毫秒為單位)。此值與 Aurora 完成轉換所需的時間成正比。因此,延遲值越大,轉換所需的時間越長。當您檢查這些指標時,請從目前的主要叢集執行此操作。

    如需 Aurora CloudWatch 指標的詳細資訊,請參閱Amazon Aurora 的叢集層級指標

  • 在切換期間提升的次要資料庫叢集,其組態設定可能與舊的主要資料庫叢集不同。我們建議您在 Aurora 全域資料庫叢集中的所有叢集中,保持下列類型的組態設定一致。這樣做有助於將切換後的效能問題、工作負載不相容和其他異常行為降至最低。

    • 視需要為新的主要伺服器設定 Aurora 資料庫叢集參數群組 – 當您提升次要資料庫叢集以接管主要角色時,次要伺服器的參數群組的設定可能會與主要伺服器不同。如果是這樣,請修改提升的次要資料庫叢集的參數群組,以符合主要叢集的設定。若要瞭解如何操作,請參閱修改 Aurora 全域資料庫的參數

    • 設定監控工具和選項,例如 Amazon CloudWatch Events 和警示 – 視需要為提升的資料庫叢集設定相同的記錄功能、警示等。與參數群組一樣,在轉換程序期間,這些功能的組態不會從主要叢集繼承。有些 CloudWatch 指標,例如複寫延遲,僅適用於次要區域。因此,轉換會改變檢視這些指標並對其設定警示的方式,而且可能需要變更任何預先定義的儀表板。如需 Aurora 資料庫叢集和監控的詳細資訊,請參閱 使用 監控 RDS Amazon Aurora 指標 CloudWatch

    • 設定與其他 AWS 服務的整合 – 如果您的 Aurora 全域資料庫與 AWS 服務整合 AWS Secrets Manager AWS Identity and Access Management,例如 Amazon S3 AWS Lambda,並確定視需要設定您與這些服務的整合。如需將 Aurora 全域資料庫與 IAM、Amazon S3 和 Lambda 整合的詳細資訊,請參閱 將 Amazon Aurora 全域資料庫與其他 AWS 服務搭配使用。若要進一步了解 Secrets Manager,請參閱如何在 AWS Secrets Manager 中自動複寫秘密 AWS 區域

如果您使用的是 Aurora Global Database writer 端點,則不需要變更應用程式中的連線設定。確認DNS變更已傳播,而且您可以在新的主要叢集上連接和執行寫入操作。然後,您可以繼續完整操作您的應用程式。

假設您的應用程式連線使用舊主要叢集的叢集端點,而不是全域寫入器端點。在這種情況下,請務必變更您的應用程式連線設定,以使用新主要叢集的叢集端點。如果您在建立 Aurora 全域資料庫時接受提供的名稱,則可透過從應用程式中提升叢集的端點字串移除 -ro 來變更端點。例如,當該叢集提升為主要叢集時,次要叢集的端點 my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com 會變成 my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com

如果您使用 RDS Proxy,請務必將應用程式的寫入操作重新導向至適當的read/write endpoint of the proxy that's associated with the new primary cluster. This proxy endpoint might be the default endpoint or a custom read/write端點。如需詳細資訊,請參閱 RDS Proxy 端點如何使用全域資料庫

您可以使用 AWS Management Console、 AWS CLI或 RDS 執行 Aurora 全域資料庫切換API。

若要在 Aurora 全球資料庫上執行轉換
  1. 登入 AWS Management Console 並在 開啟 Amazon RDS主控台https://console.aws.amazon.com/rds/

  2. 選擇資料庫並尋找您要執行切換的 Aurora 全域資料庫。

  3. 動作功能表選擇轉換或容錯移轉全球資料庫

    開啟動作功能表的資料庫清單,顯示切換或容錯移轉全域資料庫選項。
  4. 選擇轉換

    「轉換或容錯移轉全球資料庫」對話方塊,當中已選取「容錯移轉 (允許資料遺失)」。
  5. 對於新的主要叢集,選擇其中一個次要 AWS 區域 中的使用中叢集,使其成為新的主要叢集。

  6. 選擇確認

轉換完成後,您可以在資料庫清單中看到 Aurora 資料庫叢集及其目前角色,如下圖所示。

顯示已選取全球資料庫的「資料庫」清單。選取的次要叢集現在顯示為具有主要叢集角色,而舊的主要叢集具有次要叢集的角色。

若要在 Aurora 全球資料庫上執行轉換

使用 switchover-global-clusterCLI命令來執行 Aurora Global Database 的切換。使用命令,傳遞下列參數的值。

  • --region – 指定執行 Aurora 全域資料庫 AWS 區域 主要資料庫叢集的 。

  • --global-cluster-identifier – 指定 Aurora 全域資料庫的名稱。

  • --target-db-cluster-identifier – 指定您要提升為 Aurora 全域資料庫主要叢集的 Aurora 資料庫叢集 Amazon Resource Name (ARN)。

用於 Linux, macOS、 或 Unix:

aws rds --region region_of_primary \ switchover-global-cluster --global-cluster-identifier global_database_id \ --target-db-cluster-identifier arn_of_secondary_to_promote

用於 Windows:

aws rds --region region_of_primary ^ switchover-global-cluster --global-cluster-identifier global_database_id ^ --target-db-cluster-identifier arn_of_secondary_to_promote

若要為 Aurora Global Database 執行切換,請執行 SwitchoverGlobalClusterAPI操作。

從計劃外中斷復原 Amazon Aurora 全域資料庫

在極少數情況下,您的 Aurora 全域資料庫可能會在其主要資料庫中發生非預期的中斷 AWS 區域。如果發生此情況,您的主要 Aurora 資料庫叢集及其寫入器節點將無法使用,而主要和次要資料庫叢集之間的複寫也會停止。若要將停機時間 (RTO) 和資料遺失 (RPO) 降至最低,您可以快速執行跨區域容錯移轉。

Aurora Global Database 有兩種容錯移轉方法,可用於災難復原情況:

  • 受管容錯移轉 - 建議使用此方法進行災難復原。使用此方法時,當舊的主要區域再次可用時,Aurora 會自動將它新增回全球資料庫做為次要區域。如此便能維持全域叢集的原始拓撲。若要了解如何使用此方法,請參閱 針對 Aurora 全球資料庫執行受管容錯移轉

  • 手動容錯移轉 - 當無法選擇受管容錯移轉時,可以使用此替代方法,例如,當主要和次要區域執行不相容的引擎版本時。若要了解如何使用此方法,請參閱 針對 Aurora 全球資料庫執行手動容錯移轉

重要

這兩種容錯移轉方法都可能導致未在容錯移轉事件發生之前複寫至所選次要叢集的寫入交易資料遺失。不過,當復原程序將所選次要資料庫叢集上的資料庫執行個體提升為主要主要寫入器資料庫執行個體時,就能保證資料在交易上處於一致狀態。容錯移轉也容易發生大腦分裂問題。

針對 Aurora 全球資料庫執行受管容錯移轉

此方法的目的是在發生實際區域災難或服務完全中斷的情況下,提供業務持續性。

在受管容錯移轉期間,您選擇的次要區域中的次要叢集會成為新的主要叢集。選擇的次要叢集會將其中一個唯讀節點提升為完整寫入器狀態。此步驟可讓叢集擔任主要叢集的角色。當此叢集擔任這個新角色時,您的資料庫在短時間內無法使用。一旦舊的主要區域運作狀態良好且再次可用,Aurora 會自動將其新增回全域叢集做為次要區域。因此,會維護 Aurora 全域資料庫的現有複寫拓撲。

注意

只有在主要和次要資料庫叢集具有相同的主要和次要引擎版本時,才能使用 Aurora Global Database 執行受管跨區域容錯移轉。根據引擎和引擎版本,修補層級可能需要相同,或者修補層級可能不同。如需允許具有不同修補程式層級之主要和次要叢集之間這些操作的引擎和引擎版本清單,請參閱 受管跨區域轉換和容錯移轉的修補程式等級相容性。開始容錯移轉之前,請檢查全域叢集中的引擎版本,以確保它們支援受管跨區域切換,並視需要升級。如果您的引擎版本需要相同的修補程式層級,但正在執行不同的修補程式層級,您可以依照中的步驟手動執行容錯移轉針對 Aurora 全球資料庫執行手動容錯移轉

受管容錯移轉不會等待所選次要區域與目前主要區域之間的資料同步。由於 Aurora Global Database 會以非同步方式複寫資料,因此在提升至接受完整讀取/寫入功能之前,可能並非所有交易都會複寫至所選的次要 AWS 區域。

為了確保資料處於一致狀態,Aurora 會在復原後為舊的主要區域建立新的儲存磁碟區。在區域中建立新的儲存磁碟 AWS 區之前,Aurora 會嘗試在故障時擷取舊儲存磁碟區的快照。如此一來,您就可以還原快照,並從中復原任何遺失的資料。如果此操作成功,Aurora 會將名為 的此快照放在 的快照區段rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp中 AWS Management Console。您也可以使用 describe-db-cluster-snapshots AWS CLI 命令或 DescribeDBClusterSnapshotsAPI操作來查看快照的詳細資訊。

當您啟動受管容錯移轉時,Aurora 也會嘗試透過高可用性 Aurora 儲存層停止寫入流量。我們將此機制稱為「寫入圍欄」。如果程序成功,Aurora 會發出RDS事件,讓您知道寫入已停止。萬一某個區域發生多個 AZ 故障,寫入圍欄程序可能無法及時成功。在這種情況下,Aurora 會發出RDS事件,通知您停止寫入的程序已逾時。如果可以在網路上存取舊的主要叢集,Aurora 會在該處記錄這些事件。如果沒有,Aurora 會在新的主要叢集上記錄事件。若要進一步了解這些事件,請參閱 資料庫叢集事件。由於圍欄寫入是最佳的嘗試,因此在舊的主要區域中可能會暫時接受寫入,從而導致分割大腦問題。

我們建議您先完成下列任務,再使用 Aurora Global Database 執行容錯移轉。這樣做可最大限度地減少分割大腦問題的可能性,或從舊主叢集的快照中復原未複寫的資料。

  • 若要防止寫入傳送至 Aurora Global Database 的主要叢集,請讓應用程式離線。

  • 請確定連線至主要資料庫叢集的任何應用程式都使用全域寫入器端點。即使新的區域因為切換或容錯移轉而成為主要叢集,此端點的值也會保持不變。Aurora 實作額外的保護措施,以將透過全域端點提交的寫入操作遺失資料的可能性降至最低。如需全域寫入器端點的詳細資訊,請參閱連線至 Amazon Aurora Global Database

  • 如果您使用的是全域寫入器端點和應用程式或聯網層快取DNS值,請將 time-to-liveDNS快取的 (TTL) 減少為低值,例如 5 秒。如此一來,您的應用程式就能快速向全域寫入器端點註冊DNS變更。雖然 Aurora 嘗試封鎖舊主要區域中的寫入,但無法保證動作成功。縮短DNS快取持續時間可進一步降低分割大腦問題的可能性。或者,您可以檢查RDS事件,在 Aurora 觀察到全域寫入器端點DNS的變更時通知您。如此一來,您可以在重新啟動應用程式寫入流量之前,驗證您的應用程式是否也已註冊DNS變更。

  • 檢查 Aurora 全域資料庫中所有次要 Aurora 資料庫叢集的延遲時間。選擇複寫延遲最低的次要區域,即可將目前失敗的主要區域的資料遺失降到最低。

    對於所有版本的 Aurora Postgre SQL型全域資料庫,以及從引擎版本 3.04.0 及更高版本或 2.12.0 及更高版本開始的 Aurora My SQL型全域資料庫,請使用 Amazon CloudWatch 檢視所有次要資料庫叢集的AuroraGlobalDBRPOLag指標。如需 Aurora My SQL型全域資料庫的次要版本,請改為檢視 AuroraGlobalDBReplicationLag 指標。這些指標顯示複寫至次要資料庫叢集與複寫至主要資料庫叢集之間的差距 (以毫秒為單位)。

    如需 Aurora CloudWatch 指標的詳細資訊,請參閱Amazon Aurora 的叢集層級指標

在受管容錯移轉期間,選擇的次要資料庫叢集會提升為作為主要資料庫叢集的新角色。但是,它不會繼承主要資料庫叢集的各種組態選項。組態不相符可能會導致效能問題、工作負載不相容,以及其他異常行為。若要避免此類問題,建議您針對下列各項解決 Aurora 全域資料庫叢集之間的差異:

  • 視需要為新的主要伺服器設定 Aurora 資料庫叢集參數群組 – 您可以為 Aurora Global Database 中的每個 Aurora 叢集獨立設定 Aurora 資料庫叢集參數群組。因此,當您提升次要資料庫叢集以接管主要角色時,其參數群組可能會設定與主要資料庫叢集不同的參數群組。如果是這樣,請修改提升的次要資料庫叢集的參數群組,以符合主要叢集的設定。若要瞭解如何操作,請參閱修改 Aurora 全域資料庫的參數

  • 設定監控工具和選項,例如 Amazon CloudWatch Events 和警示 – 視需要為提升的資料庫叢集設定相同的記錄功能、警示等。與參數群組一樣,在容錯移轉程序期間,這些功能的組態不會從主要叢集繼承。有些 CloudWatch 指標,例如複寫延遲,僅適用於次要區域。因此,容錯移轉會改變檢視這些指標並對其設定警示的方式,而且可能需要變更任何預先定義的儀表板。如需監控 Aurora 資料庫叢集的詳細資訊,請參閱 使用 監控 RDS Amazon Aurora 指標 CloudWatch

  • 設定與其他 AWS 服務的整合 – 如果您的 Aurora Global Database 與其他 AWS 服務整合 AWS Secrets Manager AWS Identity and Access Management,例如 Amazon S3 AWS Lambda,而且您需要確保這些服務設定為從任何次要區域存取所需的。如需將 Aurora 全域資料庫與 IAM、Amazon S3 和 Lambda 整合的詳細資訊,請參閱 將 Amazon Aurora 全域資料庫與其他 AWS 服務搭配使用。若要進一步了解 Secrets Manager,請參閱如何在 AWS Secrets Manager 中自動複寫秘密 AWS 區域

通常,選擇的次要叢集會在幾分鐘內擔任主要角色。一旦新的主要區域的寫入器資料庫執行個體可用,您就可以將應用程式連線到該執行個體,並恢復工作負載。Aurora 提升新的主要叢集之後,會自動重建所有其他次要區域叢集。

由於 Aurora 全球資料庫使用非同步複寫,因此每個次要區域的複寫延遲可能有所不同。Aurora 會重建這些次要區域,使其具有與新主要區域叢集完全相同 point-in-time的資料。整個重建工作的期間可能持續幾分鐘到數小時,取決於儲存磁碟區的大小和區域之間的距離。當次要區域叢集從新的主要區域完成重建時,便可供讀取存取使用。

一旦新的主要寫入器進行提升且可用,新的主要區域的叢集就可以處理 Aurora 全球資料庫的讀取和寫入操作。

如果您使用的是 全域端點,則不需要變更應用程式中的連線設定。確認DNS變更已傳播,而且您可以在新的主要叢集上連接和執行寫入操作。然後,您可以繼續完整操作您的應用程式。

如果您未使用全域端點,請務必變更應用程式的端點,以使用新提升的主要資料庫叢集的叢集端點。如果您在建立 Aurora 全域資料庫時接受提供的名稱,則可透過從應用程式中提升叢集的端點字串移除 -ro 來變更端點。

例如,當該叢集提升為主要叢集時,次要叢集的端點 my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com 會變成 my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com

如果您使用的是 RDS Proxy,請務必將應用程式的寫入操作重新導向至適當的read/write endpoint of the proxy that's associated with the new primary cluster. This proxy endpoint might be the default endpoint or a custom read/write端點。如需詳細資訊,請參閱 RDS Proxy 端點如何使用全域資料庫

為了還原全球資料庫叢集的原始拓撲,Aurora 會監控舊主要區域的可用性。一旦該區域正常運作且再次可用,Aurora 就會自動將它新增回全域叢集作為次要區域。在舊的主要區域中建立新的儲存磁碟區之前,Aurora 會嘗試在故障點拍攝舊儲存磁碟區的快照。這樣做是為了讓您用它來復原任何遺失的資料。如果此操作成功,Aurora 會建立名為 的快照rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp。您可以在 的快照區段中找到此快照 AWS Management Console。您也可以在 D Snapshots escribeDBCluster操作傳回的資訊中查看此快照。 API

注意

舊儲存磁碟區的快照是系統快照,會受到舊的主要叢集上設定的備份保留期限的限制。若要在保留期間之外保留此快照,您可以複製該快照並將它儲存為手動快照。若要進一步了解如何複製快照,包括定價在內,請參閱 資料庫叢集快照複製

原始拓撲還原之後,您可以在最適合您的業務和工作負載時執行轉換操作,將全球資料庫容錯回復至原始主要區域。若要啟用,請依照「針對 Amazon Aurora 全球資料庫執行轉換」中的步驟進行。

您可以使用 AWS Management Console、 AWS CLI或 使用 Aurora Global Database RDS 執行容錯移轉API。

若要在 Aurora 全球資料庫上執行受管容錯移轉
  1. 登入 AWS Management Console 並在 開啟 Amazon RDS主控台https://console.aws.amazon.com/rds/

  2. 選擇資料庫並尋找您要執行容錯移轉的 Aurora 全域資料庫。

  3. 動作功能表選擇轉換或容錯移轉全球資料庫

    開啟動作選單的資料庫清單,顯示切換或容錯移轉全域資料庫選項。
  4. 選擇容錯移轉 (允許資料遺失)

    「轉換或容錯移轉全球資料庫」對話方塊,當中已選取「容錯移轉 (允許資料遺失)」。
  5. 對於新的主要叢集,選擇其中一個次要 AWS 區域 中的使用中叢集,使其成為新的主要叢集。

  6. 輸入 confirm,然後選擇確認

當容錯移轉完成時,您可以在資料庫清單中檢視 Aurora 資料庫叢集及其目前狀態,如下圖所示。

顯示已選取全球資料庫的「資料庫」清單。選取的次要叢集現在顯示為具有主要叢集角色,而舊的主要叢集具有次要叢集的角色。

若要在 Aurora 全球資料庫上執行受管容錯移轉

使用 failover-global-clusterCLI命令以使用 Aurora Global Database 執行容錯移轉。使用命令,傳遞下列參數的值。

  • --region – 指定要成為 Aurora 全域資料庫新主要資料庫的次要資料庫叢集正在執行 AWS 區域 的 。

  • --global-cluster-identifier – 指定 Aurora 全域資料庫的名稱。

  • --target-db-cluster-identifier – 指定您要提升為 Aurora 全域資料庫新主要叢集的 Aurora 資料庫叢集 Amazon Resource Name (ARN)。

  • --allow-data-loss - 明確使其成為容錯移轉操作,而不是轉換操作。如果非同步複寫元件尚未完成將所有複寫的資料傳送至次要區域,容錯移轉操作就可能導致部分資料遺失。

用於 Linux, macOS、 或 Unix:

aws rds --region region_of_selected_secondary \ failover-global-cluster --global-cluster-identifier global_database_id \ --target-db-cluster-identifier arn_of_secondary_to_promote \ --allow-data-loss

用於 Windows:

aws rds --region region_of_selected_secondary ^ failover-global-cluster --global-cluster-identifier global_database_id ^ --target-db-cluster-identifier arn_of_secondary_to_promote ^ --allow-data-loss

若要使用 Aurora Global Database 執行容錯移轉,請執行 FailoverGlobalClusterAPI操作。

針對 Aurora 全球資料庫執行手動容錯移轉

在某些情況下,您可能無法使用受管容錯移轉程序。舉例來說,如果您的主要和次要資料庫叢集未執行相容的引擎版本,就是這種情況。在此情況下,您可以遵循此手動程序,執行容錯移轉至目標次要區域。

提示

我們建議您在使用此程序之前先了解該程序。準備計劃,以便在出現第一個全區域問題跡象時快速執行。您可以 CloudWatch 定期使用 Amazon 來追蹤次要叢集的延遲時間,以識別具有最低複寫延遲的次要區域。請務必測試您的計畫,以檢查程序是否完整且準確,以及員工在真正發生容錯移轉之前接受過災難復原容錯移轉的培訓。

在主要區域中意外中斷之後,執行手動容錯移轉至次要叢集
  1. 停止對 中 AWS 區域 主要 Aurora 資料庫叢集發出DML陳述式和其他寫入操作,並中斷。

  2. 從次要 識別 Aurora 資料庫叢集 AWS 區域 ,以用作新的主要資料庫叢集。如果您的 AWS 區域 Aurora 全域資料庫中有兩個或更多次要叢集,請選擇複寫延遲最少的次要叢集。

  3. 從 Aurora 全域資料庫中分離您選擇的次要資料庫叢集。

    若從 Aurora 全域資料庫移除次要資料庫叢集,會立即停止從主要資料庫叢集複寫到該次要資料庫叢集,並將其提升為具有完整讀取/寫入功能的獨立佈建 Aurora 資料庫叢集。與發生中斷區域的主要叢集關聯的任何其他次要 Aurora 資料庫叢集仍然可用,並且可以接受應用程式的呼叫。它們也會取用資源。因您正在重新建立 Aurora 全域資料庫,請先移除其他次要資料庫叢集,再在後續步驟中建立新的 Aurora 全域資料庫。這樣可以避免 Aurora 全域資料庫的資料庫叢集之間出現資料不一致的情況 (稱為核心分裂問題)。

    如需分離的詳細步驟,請參閱從 Amazon Aurora 全域資料庫中移除叢集

  4. 重新設定您的應用程式,以使用其新端點將所有寫入操作傳送至這個目前獨立的 Aurora 資料庫叢集。如果您在建立 Aurora 全域資料庫時接受提供的名稱,則可透過從應用程式中叢集的端點字串移除 -ro 來變更端點。

    例如,當該叢集從 Aurora 全域資料庫分離時,次要叢集的端點 my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com 會變成 my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com

    當您開始在下一個步驟中新增區域時,此 Aurora 資料庫叢集會成為新的 Aurora 全域資料庫的主要叢集。

    如果您使用 RDS Proxy,請務必將應用程式的寫入操作重新導向至適當的read/write endpoint of the proxy that's associated with the new primary cluster. This proxy endpoint might be the default endpoint or a custom read/write端點。如需詳細資訊,請參閱 RDS Proxy 端點如何使用全域資料庫

  5. 將 AWS 區域 新增至資料庫叢集。當您執行這項操作時,從主要到次要的複寫程序即會開始。如需新增區域的詳細步驟,請參閱將 AWS 區域 新增至 Amazon Aurora 全域資料庫

  6. AWS 區域 視需要新增更多 ,以重新建立支援應用程式所需的拓撲。

請確定應用程式寫入會在做出這些變更之前、期間和之後,傳送至正確的 Aurora 資料庫叢集。這樣可以避免 Aurora 全域資料庫的資料庫叢集之間出現資料不一致的情況 (稱為核心分裂問題)。

如果您重新設定 以回應 中的中斷 AWS 區域,您可以在中斷解決後再次讓 AWS 區域 成為主要 。若要這樣做,請將舊的 新增至 AWS 區域 新的全域資料庫,然後使用切換程序來切換其角色。您的 Aurora 全域資料庫必須使用支援切換的 Aurora PostgreSQL 或 Aurora MySQL 版本。如需詳細資訊,請參閱針對 Amazon Aurora 全球資料庫執行轉換

RPOs 管理SQL以 Aurora Postgre 為基礎的全域資料庫

使用以 Aurora Postgre SQL為基礎的全域資料庫,您可以使用 rds.global_db_rpo 參數來管理 Aurora 全域資料庫的復原點目標 (RPO)。 RPO代表發生中斷時可能遺失的資料量上限。

當您RPO為以 Aurora Postgre SQL為基礎的全域資料庫設定 時,Aurora 會監控所有次要叢集的RPO延遲時間,以確保至少一個次要叢集保留在目標RPO視窗中。RPO延遲時間是另一個以時間為基礎的指標。

當您的資料庫在容錯移轉 AWS 區域 後在新的 中恢復操作時,RPO會使用 。Aurora RPO 會評估RPO和延遲在主要 上遞交 (或封鎖) 交易的時間,如下所示:

  • 如果至少一個次要資料庫叢集的RPO延遲時間小於 ,則遞交交易RPO。

  • 如果所有次要資料庫叢集的RPO延遲時間都大於 ,則封鎖交易RPO。它也會將事件記錄到 PostgreSQL 日誌檔案,並發出顯示封鎖工作階段的「等待」事件。

換句話說,如果所有次要叢集都落後於目標 RPO,Aurora 會暫停主要叢集上的交易,直到至少一個次要叢集追上進度為止。一旦至少一個次要資料庫叢集的延遲時間變得小於 ,就會繼續並遞交暫停的交易RPO。結果是,在滿足 RPO 之前,沒有任何交易可以遞交。

rds.global_db_rpo 參數是動態的。如果您決定不要讓所有寫入交易都停止,直到延遲降低到足夠的程度,那麼您可以快速重設它。在這種情況下,Aurora 會在經過短暫延遲後,辨識並實作變更。

重要

在只有兩個 AWS 區域的全域資料庫中,我們建議將rds.global_db_rpo參數的預設值保留在次要區域的參數群組中。否則,由於主要 AWS 區域遺失而執行容錯移轉可能會導致 Aurora 暫停交易。相反地,請等待 Aurora 完成重建舊故障 AWS 區域中的叢集,再變更此參數以強制執行最大 RPO。

如果您依照下列所述設定此參數,您也可以監控其產生的指標。您可以使用 psql或其他工具來查詢 Aurora 全域資料庫的主要資料庫叢集,並取得以 Aurora Postgre SQL為基礎的全域資料庫操作的詳細資訊。若要瞭解如何操作,請參閱監控 Aurora Postgre SQL型全域資料庫

設定復原點目標

rds.global_db_rpo 參數控制 PostgreSQL 資料庫RPO的設定。Aurora Postgre 支援此參數SQL。rds.global_db_rpo 的有效值範圍為 20 秒至 2,147,483,647 秒 (68 年)。選擇符合您的業務需求和應用案例的實際值。例如,您可能希望 最多允許 10 分鐘RPO,在這種情況下,請將 值設定為 600。

您可以使用 AWS Management Console、 AWS CLI或 ,為SQL以 Aurora Postgre RDS 為基礎的全域資料庫設定此值API。

若要設定 RPO
  1. 登入 AWS Management Console 並在 開啟 Amazon RDS主控台https://console.aws.amazon.com/rds/

  2. 選擇 Aurora 全域資料庫的主要叢集,然後開啟 Configuration (組態) 標籤,以尋找其資料庫叢集參數群組。例如,執行 Aurora PostgreSQL 11.7 的主要資料庫叢集的預設參數群組為 。 default.aurora-postgresql11

    無法直接編輯參數群組。而是執行下列動作:

    • 使用適當的預設參數群組作為起點,建立自訂資料庫叢集參數群組。例如,根據 default.aurora-postgresql11 建立自訂資料庫叢集參數群組。

    • 在您的自訂資料庫參數群組上,設定 rds.global_db_rpo 參數的值,以符合您的應用案例。有效值範圍為 20 秒至最大整數值 2,147,483,647 (68 年)。

    • 將修改後的資料庫叢集參數群組套用至您的 Aurora 資料庫叢集。

如需詳細資訊,請參閱在 Amazon Aurora 中修改資料庫叢集參數群組中的參數

若要設定 rds.global_db_rpo 參數,請使用 modify-db-cluster-parameter-group CLI命令。在 命令中,指定主要叢集參數群組的名稱和RPO參數的值。

下列範例會將名為 的主要資料庫叢集參數群組的 RPO設定為 600 秒 (10 分鐘)my_custom_global_parameter_group

用於 Linux, macOS、 或 Unix:

aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name my_custom_global_parameter_group \ --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

用於 Windows:

aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name my_custom_global_parameter_group ^ --parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"

若要修改 rds.global_db_rpo 參數,請使用 Amazon RDS ModifyDBClusterParameterGroup API操作。

檢視復原點目標

全域資料庫的復原點目標 (RPO) 會存放在每個資料庫叢集的 rds.global_db_rpo 參數中。您可以連線至要檢視之次要叢集的端點,並使用 psql 來查詢執行個體的該值。

db-name=>show rds.global_db_rpo;

如果未設定此參數,則查詢會傳回下列項目:

rds.global_db_rpo ------------------- -1 (1 row)

下一個回應來自具有 1 分鐘RPO設定的次要資料庫叢集。

rds.global_db_rpo ------------------- 60 (1 row)

您也可以使用 CLI來取得值,以查明 是否在任何 Aurora 資料庫叢集上rds.global_db_rpo處於作用中狀態,方法是使用 CLI取得叢集所有user參數的值。

用於 Linux, macOS、 或 Unix:

aws rds describe-db-cluster-parameters \ --db-cluster-parameter-group-name lab-test-apg-global \ --source user

用於 Windows:

aws rds describe-db-cluster-parameters ^ --db-cluster-parameter-group-name lab-test-apg-global * --source user

該命令會傳回所有 user 參數類似於下列各項的輸出。這不是 default-enginesystem 資料庫叢集參數。

{ "Parameters": [ { "ParameterName": "rds.global_db_rpo", "ParameterValue": "60", "Description": "(s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated.", "Source": "user", "ApplyType": "dynamic", "DataType": "integer", "AllowedValues": "20-2147483647", "IsModifiable": true, "ApplyMethod": "immediate", "SupportedEngineModes": [ "provisioned" ] } ] }

若要進一步了解如何檢視叢集參數群組的參數,請參閱在 Amazon Aurora 中檢視資料庫叢集參數群組的參數值

停用復原點目標

若要停用 RPO,請重設 rds.global_db_rpo 參數。您可以使用 AWS Management Console、 AWS CLI或 RDS 重設參數API。

停用 RPO
  1. 登入 AWS Management Console ,並在 開啟 Amazon RDS主控台https://console.aws.amazon.com/rds/

  2. 在導覽窗格中,選擇 Parameter groups (參數群組)。

  3. 在清單中,選擇主要資料庫叢集參數群組。

  4. 選擇 Edit parameters (編輯參數)。

  5. 選擇 rds.global_db_rpo 參數旁的方塊。

  6. 選擇 Reset (重設)

  7. 當畫面顯示 Reset parameters in DB parameter group (重設資料庫參數群組中的參數) 時,選擇 Reset parameters (重設參數)

如需如何使用主控台重設參數的詳細資訊,請參閱在 Amazon Aurora 中修改資料庫叢集參數群組中的參數

若要重設 rds.global_db_rpo 參數,請使用 reset-db-cluster-parameter-group 命令。

用於 Linux, macOS、 或 Unix:

aws rds reset-db-cluster-parameter-group \ --db-cluster-parameter-group-name global_db_cluster_parameter_group \ --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

用於 Windows:

aws rds reset-db-cluster-parameter-group ^ --db-cluster-parameter-group-name global_db_cluster_parameter_group ^ --parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"

若要重設 rds.global_db_rpo 參數,請使用 Amazon RDS API ResetDBClusterParameterGroup 操作。