Verwenden von Umstellung oder Failover in einer Amazon Aurora Global Database

Eine globale Aurora-Datenbank bietet mehr Schutz für Geschäftskontinuität und Disaster Recovery (BCDR) als die standardmäßige Hochverfügbarkeit, die ein Aurora-DB-Cluster in einem einzigen bietet AWS-Region. Mithilfe einer globalen Aurora-Datenbank können Sie für echte regionale Katastrophen oder vollständige Service-Level-Ausfälle planen und diese schnell beheben. Die Wiederherstellung nach einem Notfall wird in der Regel von den folgenden beiden Geschäftszielen bestimmt:

Beim Umschalten oder einem Failover einer globalen Aurora-Datenbank muss ein DB-Cluster in einer der sekundären Regionen Ihrer globalen Datenbank zum primären DB-Cluster heraufgestuft werden. Der Begriff „regionaler Ausfall“ wird häufig verwendet, um eine Vielzahl von Ausfallszenarien zu beschreiben. Ein schlimmstmögliches Szenario könnte ein großflächiger Ausfall aufgrund eines katastrophalen Ereignisses sein, das Hunderte von Quadratkilometern betrifft. Die meisten Ausfälle sind jedoch viel stärker lokal begrenzt und betreffen nur einen kleinen Teil der Cloud-Dienste oder Kundensysteme. Berücksichtigen Sie den gesamten Umfang des Ausfalls, um sicherzustellen, dass regionsübergreifendes Failover die richtige Lösung ist, und wählen Sie die für die jeweilige Situation geeignete Failover-Methode aus. Ob Sie den Failover- oder den Umstellungs-Ansatz verwenden sollten, hängt vom jeweiligen Ausfallszenario ab:

Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall

In sehr seltenen Fällen kann es in Ihrer globalen Aurora-Datenbank zu einem unerwarteten Ausfall in der primären AWS-Region kommen. In einem solchen Fall sind der primäre Aurora-DB-Cluster und sein Writer-Knoten nicht verfügbar, und die Replikation zwischen dem primären Cluster und den sekundären Clustern wird angehalten. Um sowohl Ausfallzeiten (RTO) als auch Datenverlust (RPO) zu minimieren, können Sie schnell ein regionsübergreifendes Failover durchführen.

Es gibt zwei Methoden für ein Failover in einer Notfallwiederherstellungssituation:

Ausführen von verwalteten geplanten Failovers für globale Aurora-Datenbanken

Dieser Ansatz dient der Geschäftskontinuität im Falle einer echten regionalen Katastrophe oder eines kompletten Service-Level-Ausfalls.

Während eines verwalteten geplanten Failovers erfolgt ein Failover Ihres primären Clusters auf eine von Ihnen gewählte sekundäre Region, während die vorhandene Replikationstopologie Ihrer globalen Aurora-Datenbank beibehalten wird. Der gewählte sekundäre Cluster stuft einen seiner schreibgeschützten Knoten auf vollen Writer-Status herauf. In diesem Schritt kann der Cluster die Rolle des primären Clusters übernehmen. Ihre Datenbank ist für kurze Zeit nicht verfügbar, während dieser Cluster seine neue Rolle annimmt. Daten, die nicht vom alten primären auf den ausgewählten sekundären Cluster repliziert wurden, fehlen, wenn dieser sekundäre zum neuen primären Cluster wird.

Um Datenverlust zu minimieren, empfehlen wir Ihnen, vor der Verwendung dieser Funktion Folgendes zu tun:

Während eines verwalteten Failovers wird der ausgewählte sekundäre DB-Cluster in seine neue Rolle als primärer Cluster hochgestuft. Er übernimmt jedoch nicht die verschiedenen Konfigurationsoptionen des primären DB-Clusters. Wenn die Konfiguration nicht übereinstimmt, kann dies Leistungsprobleme, Workload-Inkompatibilitäten und anderes anomales Verhalten zur Folge haben. Um solche Probleme zu vermeiden, empfehlen wir Ihnen, die Unterschiede zwischen den Clustern Ihrer globalen Aurora-Datenbank wie folgt aufzulösen:

In der Regel übernimmt der gewählte sekundäre Cluster innerhalb weniger Minuten die primäre Rolle. Sobald der Writer-Knoten der neuen primären Region verfügbar ist, können Sie Ihre Anwendungen mit diesem verbinden und Ihre Workloads fortsetzen. Nachdem Aurora den neuen primären Cluster hochgestuft hat, werden automatisch alle zusätzlichen Cluster der sekundären Region neu erstellt.

Da die globalen Aurora-Datenbanken die asynchrone Replikation verwenden, kann die Replikationsverzögerung in jeder sekundären Region variieren. Aurora baut diese sekundären Regionen neu auf, sodass sie genau dieselben point-in-time Daten wie der neue Cluster der primären Region haben. Die Dauer der vollständigen Neuerstellungsaufgabe kann je nach Größe des Speichervolumens und der Entfernung zwischen den Regionen einige Minuten bis mehrere Stunden dauern. Wenn der Wiederaufbau der Cluster der sekundären Region aus der neuen primären Region abgeschlossen ist, stehen sie für den Lesezugriff zur Verfügung.

Sobald der neue primäre Writer hochgestuft und verfügbar ist, kann der Cluster der neuen primären Region Lese- und Schreibvorgänge für die globale Aurora-Datenbank abwickeln. Stellen Sie sicher, dass Sie den Endpunkt für Ihre Anwendung ändern, um den neuen Endpunkt zu verwenden. Wenn Sie die angegebenen Namen beim Erstellen der globalen Aurora-Datenbank akzeptiert haben, können Sie den Endpunkt ändern, indem Sie -ro aus der Endpunkt-Zeichenfolge des hochgestuften Clusters in Ihrer Anwendung entfernen.

Beispielsweise wird der Endpunkt des sekundären Clusters my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com zu my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com, wenn dieser Cluster zum primären Cluster hochgestuft wird.

Wenn Sie RDS Proxy verwenden, stellen Sie sicher, dass die Schreibvorgänge Ihrer Anwendung an den entsprechenden Lese-/Schreibendpunkt des Proxys umgeleitet werden, der dem neuen primären Cluster zugeordnet ist. Dieser Proxy-Endpunkt kann der Standardendpunkt oder ein benutzerdefinierter Lese-/Schreibendpunkt sein. Weitere Informationen finden Sie unter So funktionieren RDS-Proxy-Endpunkte mit globalen Datenbanken.

Um die ursprüngliche Topologie des globalen Datenbank-Clusters wiederherzustellen, überwacht Aurora die Verfügbarkeit der alten primären Region. Sobald diese Region fehlerfrei und wieder verfügbar ist, fügt Aurora sie automatisch wieder als sekundäre Region zum globalen Cluster hinzu. Bevor das neue Speichervolume in der alten Primärregion erstellt wird, versucht Aurora, zum Zeitpunkt des Fehlers einen Snapshot des alten Speichervolumes zu erstellen. Auf diese Weise können Sie alle fehlenden Daten wiederherstellen. Wenn dieser Vorgang erfolgreich ist, platziert Aurora diesen Snapshot mit dem Namen „rds: unplanned-global-failover -name-of-old-primary-DB-cluster-timestamp"im Snapshot-Abschnitt des AWS Management Console. Sie können diesen Snapshot auch in den Informationen sehen, die vom API Vorgang D escribeDBCluster Snapshots zurückgegeben werden.

Nachdem die ursprüngliche Topologie wiederhergestellt ist, können Sie ein Failback Ihrer globalen Datenbank auf die ursprüngliche primäre Region durchführen, indem Sie eine Umstellung durchführen, wenn dies für Ihr Unternehmen und Ihren Workload am sinnvollsten ist. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter Durchführen von Umstellungen für Amazon Aurora Global Databases.

Sie können ein Failover für Ihre globale Aurora-Datenbank durchführen AWS Management Console, indem Sie die AWS CLI, oder die verwenden RDSAPI.

So starten Sie den verwalteten Failover-Prozess in Ihrer globalen Aurora-Datenbank

1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/.

2. Wählen Sie Datenbanken und suchen Sie die globale Aurora-Datenbank, für die Sie ein Failover ausführen möchten.

3. Wählen Sie im Menü Aktionen die Option Failover für globale Datenbank aus.

   

4. Wählen Sie Failover (Datenverlust zulassen).

   

5. Wählen Sie unter Neuer primärer Cluster einen aktiven Cluster in einem Ihrer sekundären AWS-Regionen Cluster als neuen primären Cluster aus.

6. Geben Sie confirm ein, und wählen Sie dann Bestätigen.

Wenn das Failover abgeschlossen ist, werden die Aurora-DB-Cluster und ihr aktueller Status wie im Folgenden in der Liste Datenbanken dargestellt angezeigt.

So führen Sie das verwaltete Failover für eine globale Aurora-Datenbank durch

Verwenden Sie den failover-global-cluster CLI Befehl, um ein Failover für Ihre globale Aurora-Datenbank durchzuführen. Mit dem Befehl können Sie Werte für die folgenden Parameter übertragen.

• --region— Geben Sie an AWS-Region , wo der sekundäre DB-Cluster, den Sie als neuen primären DB-Cluster für die globale Aurora-Datenbank verwenden möchten, ausgeführt wird.

• --global-cluster-identifier – Geben Sie den Namen Ihrer globalen Aurora-Datenbank an.

• --target-db-cluster-identifier— Geben Sie den Amazon-Ressourcennamen (ARN) des Aurora-DB-Clusters an, den Sie zum neuen Primärserver für die globale Aurora-Datenbank heraufstufen möchten.

• --allow-data-loss – Machen Sie dies ausdrücklich zu einer Failover- und nicht zu einer Umstellungs-Operation. Ein Failover-Vorgang kann zu Datenverlusten führen, wenn die asynchronen Replikationskomponenten das Senden aller replizierten Daten an die sekundäre Region nicht abgeschlossen haben.

Für LinuxmacOS, oderUnix:

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

Führen Sie den FailoverGlobalClusterAPIVorgang aus, um ein Failover für eine globale Aurora-Datenbank durchzuführen.

Ausführen von manuellen geplanten Failovers für globale Aurora-Datenbanken

In einigen Szenarien können Sie den verwalteten Failover-Prozess möglicherweise nicht verwenden. Ein Beispiel ist etwa, wenn auf Ihrem primären und sekundären DB-Cluster keine kompatiblen Engine-Versionen ausgeführt werden. In diesem Fall können Sie diesem manuellen Prozess folgen, um ein Failover Ihrer globalen Datenbank in Ihre sekundäre Zielregion durchzuführen.

Stellen Sie sicher, dass Schreibvorgänge der Anwendung vor, während und nach diesen Änderungen an den richtigen Aurora-DB-Cluster gesendet werden. Dadurch werden Dateninkonsistenzen zwischen den DB-Clustern in der globalen Aurora-Datenbank vermieden (split-brain-Probleme).

Wenn Sie als Reaktion auf einen Ausfall in einer neu konfiguriert haben AWS-Region, können Sie diese nach Behebung AWS-Region des Ausfalls wieder zum primären Server machen. Dazu fügen Sie die alte AWS-Region Ihrer neuen globalen Datenbank hinzu und verwenden dann den Umstellungs-Prozess, um die Rolle zu wechseln. Ihre globale Aurora-Datenbank muss eine Version von Aurora Postgre SQL oder Aurora My verwendenSQL, die Switchover unterstützt. Weitere Informationen finden Sie unter Durchführen von Umstellungen für Amazon Aurora Global Databases.

Durchführen von Umstellungen für Amazon Aurora Global Databases

Mithilfe von Switchovers können Sie die Region Ihres primären Clusters routinemäßig ändern. Dieser Ansatz ist für kontrollierte Szenarien gedacht, z. B. für betriebliche Wartung und andere geplante Betriebsverfahren.

Es gibt drei gängige Anwendungsfälle für die Verwendung von Umstellungen.

Während einer Umstellung wechselt Aurora Ihren primären Cluster zu der von Ihnen gewählten sekundären Region, während die vorhandene Replikationstopologie Ihrer Aurora Global Database beibehalten wird. Bevor die Umstellung gestartet wird, wartet Aurora, bis alle Cluster der sekundären Region vollständig mit dem Cluster der primären Region synchronisiert sind. Dann wird der DB-Cluster in der primären Region schreibgeschützt, und der ausgewählte sekundäre Cluster stuft einen seiner schreibgeschützten Knoten auf vollen Writer-Status hoch. Durch die Heraufstufung dieses Knotens zu einem Writer kann dieser sekundäre Cluster die Rolle des primären Clusters übernehmen. Da alle sekundären Cluster zu Beginn des Prozesses mit dem primären Cluster synchronisiert wurden, setzt die neue primäre Version den Betrieb für die globale Aurora-Datenbank fort, ohne dass Daten verloren gehen. Ihre Datenbank ist für kurze Zeit nicht verfügbar, während der primäre und der ausgewählte sekundäre Cluster ihre neuen Rollen übernehmen.

Um die Anwendungsverfügbarkeit zu optimieren, empfehlen wir Ihnen, vor der Verwendung dieser Funktion Folgendes zu tun:

Während einer Umstellung wird der ausgewählte sekundäre DB-Cluster in seine neue Rolle als primärer Cluster hochgestuft. Er übernimmt jedoch nicht die verschiedenen Konfigurationsoptionen des primären DB-Clusters. Wenn die Konfiguration nicht übereinstimmt, kann dies Leistungsprobleme, Workload-Inkompatibilitäten und anderes anomales Verhalten zur Folge haben. Um solche Probleme zu vermeiden, empfehlen wir Ihnen, die Unterschiede zwischen den Clustern Ihrer globalen Aurora-Datenbank wie folgt aufzulösen:

Wenn der Umstellungs-Prozess abgeschlossen ist, kann der hochgestufte Aurora-DB-Cluster Schreibvorgänge für die Aurora Global Database verarbeiten. Stellen Sie sicher, dass Sie den Endpunkt für Ihre Anwendung ändern, um den neuen Endpunkt zu verwenden. Wenn Sie die angegebenen Namen beim Erstellen der globalen Aurora-Datenbank akzeptiert haben, können Sie den Endpunkt ändern, indem Sie -ro aus der Endpunkt-Zeichenfolge des hochgestuften Clusters in Ihrer Anwendung entfernen.

Beispielsweise wird der Endpunkt des sekundären Clusters my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com zu my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com, wenn dieser Cluster zum primären Cluster hochgestuft wird.

Wenn Sie RDS Proxy verwenden, stellen Sie sicher, dass Sie die Schreibvorgänge Ihrer Anwendung an den entsprechenden Lese-/Schreib-Endpunkt des Proxys umleiten, der dem neuen primären Cluster zugeordnet ist. Dieser Proxy-Endpunkt kann der Standardendpunkt oder ein benutzerdefinierter Lese-/Schreibendpunkt sein. Weitere Informationen finden Sie unter So funktionieren RDS-Proxy-Endpunkte mit globalen Datenbanken.

Sie können Ihre globale Aurora-Datenbank mit dem AWS Management Console AWS CLI, dem oder dem umschalten RDSAPI.

So führen Sie eine Umstellung in Ihrer Aurora Global Database durch

1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/.

2. Wählen Sie Datenbanken aus und suchen Sie die Aurora Global Database, für die Sie eine Umstellung ausführen möchten.

3. Wählen Sie im Menü Aktionen die Option Failover für globale Datenbank ausführen aus.

   

4. Wählen Sie Umschaltung.

   

5. Wählen Sie unter Neuer primärer Cluster einen aktiven Cluster in einem Ihrer sekundären AWS-Regionen Cluster als neuen primären Cluster aus.

6. Wählen Sie Bestätigen aus.

Wenn die Umstellung abgeschlossen ist, werden die Aurora-DB-Cluster und ihr aktueller Status wie im Folgenden dargestellt in der Liste Datenbanken angezeigt.

So führen Sie eine Umstellung auf einer Aurora Global Database durch

Verwenden Sie den switchover-global-cluster CLI Befehl, um Ihre globale Aurora-Datenbank umzuschalten. Mit dem Befehl können Sie Werte für die folgenden Parameter übertragen.

• --region— Geben Sie an AWS-Region , wo der primäre DB-Cluster der globalen Aurora-Datenbank läuft.

• --global-cluster-identifier – Geben Sie den Namen Ihrer globalen Aurora-Datenbank an.

• --target-db-cluster-identifier— Geben Sie den Amazon-Ressourcennamen (ARN) des Aurora-DB-Clusters an, den Sie zum primären für die globale Aurora-Datenbank heraufstufen möchten.

Für LinuxmacOS, oderUnix:

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

Um zu einer globalen Aurora-Datenbank zu wechseln, führen Sie den SwitchoverGlobalClusterAPIVorgang aus.

Verwaltung RPOs für globale Datenbanken SQL auf Basis von Aurora Postgre

Mit einer globalen Aurora SQL Postgre-Datenbank können Sie das Recovery Point Objective (RPO) für Ihre globale Aurora-Datenbank mithilfe des rds.global_db_rpo Parameters verwalten. RPOstellt die maximale Datenmenge dar, die bei einem Ausfall verloren gehen kann.

Wenn Sie eine RPO für Ihre Aurora SQL Postgre-basierte globale Datenbank einrichten, überwacht Aurora die RPOVerzögerungszeit aller sekundären Cluster, um sicherzustellen, dass mindestens ein sekundärer Cluster innerhalb des RPO Zielfensters bleibt. RPODie Lagzeit ist eine weitere zeitbasierte Metrik.

Die RPO wird verwendet, wenn Ihre Datenbank AWS-Region nach einem Failover den Betrieb in einem neuen System wieder aufnimmt. Aurora bewertet RPO und RPO verzögert die Zeiten für das Festschreiben (oder Blockieren) von Transaktionen auf der Primärseite wie folgt:

Mit anderen Worten, wenn sich alle sekundären Cluster hinter dem Ziel befindenRPO, pausiert Aurora die Transaktionen auf dem primären Cluster, bis mindestens einer der sekundären Cluster aufholt. Unterbrochene Transaktionen werden wieder aufgenommen und festgeschrieben, sobald die Verzögerungszeit mindestens eines sekundären DB-Clusters unter dem Wert liegt. RPO Das Ergebnis ist, dass keine Transaktionen festgeschrieben werden können, bis der RPO Wert erreicht ist.

Der rds.global_db_rpo-Parameter ist dynamisch. Wenn Sie nicht möchten, dass alle Schreibtransaktionen angehalten werden, bis die Verzögerung ausreichend abnimmt, können Sie ihn schnell zurücksetzen. In diesem Fall erkennt Aurora die Änderung und implementiert sie nach einer kurzen Verzögerung.

Wenn Sie diesen Parameter wie folgt festlegen, können Sie auch die von ihm generierten Metriken überwachen. Sie können dies tun, indem Sie psql oder ein anderes Tool verwenden, um den primären DB-Cluster der globalen Aurora-Datenbank abzufragen und detaillierte Informationen über den Betrieb Ihrer auf Aurora Postgre SQL basierenden globalen Datenbank zu erhalten. Um zu erfahren wie, siehe Überwachung globaler Datenbanken SQL auf Basis von Aurora Postgre.

Festlegen des Recovery Point Objective

Der rds.global_db_rpo Parameter steuert die RPO Einstellung für eine SQL Postgre-Datenbank. Dieser Parameter wird von Aurora Postgre SQL unterstützt. Gültige Werte für rds.global_db_rpo liegen zwischen 20 und 2.147.483.647 Sekunden (68 Jahre). Wählen Sie einen realistischen Wert, der Ihren Geschäftsanforderungen und Ihrem Anwendungsfall entspricht. Möglicherweise möchten Sie für Ihre Zeit bis zu 10 Minuten einplanen. RPO In diesem Fall setzen Sie den Wert auf 600.

Sie können diesen Wert für Ihre globale Aurora SQL Postgre-Datenbank festlegen, indem Sie die AWS Management Console AWS CLI, oder die verwenden. RDS API

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"

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"

Anzeigen des Recovery Point Objective (Zeitraums zwischen zwei Datensicherungen)

Das Recovery Point Objective (RPO) einer globalen Datenbank wird im rds.global_db_rpo Parameter für jeden DB-Cluster gespeichert. Sie können eine Verbindung zum Endpunkt für den sekundären Cluster herstellen, den Sie anzeigen möchten, und mit psql die Instance nach diesem Wert abfragen.

db-name=>show rds.global_db_rpo;

Wenn dieser Parameter nicht festgelegt ist, gibt die Abfrage Folgendes zurück:

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

Diese nächste Antwort stammt von einem sekundären DB-Cluster mit einer RPO Einstellung von 1 Minute.

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

Sie können den auch verwendenCLI, um Werte abzurufen, um herauszufinden, ob er auf einem der Aurora-DB-Cluster aktiv rds.global_db_rpo ist, indem Sie die verwendenCLI, um Werte aller user Parameter für den Cluster abzurufen.

Für LinuxmacOS, oderUnix:

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

Der Befehl gibt für alle user-Parameter, die keine default-engine- oder system-DB-Cluster-Parameter sind, eine Ausgabe zurück, die der folgenden Ausgabe ähnelt.

{
    "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"
            ]
        }
    ]
}

Weitere Informationen zum Anzeigen von Parametern der Clusterparametergruppe finden Sie unter Parameterwerte für eine DB-Cluster-Parametergruppe in Amazon Aurora anzeigen.

Deaktivieren des Recovery Point Objective

Um das zu deaktivierenRPO, setzen Sie den rds.global_db_rpo Parameter zurück. Sie können Parameter mit dem AWS Management Console AWS CLI, dem oder dem zurücksetzen RDSAPI.

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"

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"