Verwenden von Switchover oder Failover in Amazon Aurora Global Database

Die Aurora Global Database-Funktion bietet mehr Schutz vor Geschäftskontinuität und Disaster Recovery (BCDR) als die standardmäßige Hochverfügbarkeit, die ein Aurora-DB-Cluster in einem einzigen AWS-Region bietet. Mithilfe von Aurora Global Database können Sie eine schnellere Wiederherstellung nach seltenen, ungeplanten regionalen Katastrophen planen oder Service-Level-Ausfälle schnell abschließen.

Sie können die folgenden Anleitungen und Verfahren zur Planung, Prüfung und Implementierung Ihrer BCDR-Strategie mithilfe der Aurora Global Database-Funktion nutzen.

Planung für Geschäftskontinuität und Disaster Recovery

Um Ihre Strategie für Geschäftskontinuität und Disaster Recovery zu planen, ist es hilfreich, die folgenden Branchenterminologien zu verstehen und zu verstehen, wie sich diese Begriffe auf die Funktionen der Aurora Global Database beziehen.

Die Wiederherstellung nach einem Notfall wird in der Regel von den folgenden beiden Geschäftszielen bestimmt:

Die Durchführung eines Switchovers oder Failovers mit Aurora Global Database beinhaltet die Heraufstufung eines sekundären DB-Clusters zum primären DB-Cluster. 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:

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 eines Switchovers macht Aurora den Cluster in der von Ihnen ausgewählten sekundären Region zu Ihrem primären Cluster. Der Switchover-Mechanismus behält die bestehende Replikationstopologie Ihrer globalen Datenbank bei: Sie hat immer noch dieselbe Anzahl von Aurora-Clustern in denselben Regionen. Bevor Aurora den Switchover-Prozess startet, wartet es, bis die Cluster der sekundären Zielregion vollständig mit dem Cluster der primären Region synchronisiert sind. Dann wird der DB-Cluster in der primären Region schreibgeschützt. Der gewählte sekundäre Cluster stuft einen seiner schreibgeschützten Knoten in den vollen Writer-Status herauf, sodass dieser sekundäre Cluster die Rolle des primären Clusters übernehmen kann. Da der sekundäre Zielcluster zu Beginn des Prozesses mit dem Primärcluster synchronisiert wurde, setzt der neue Primärcluster den Betrieb für die globale Aurora-Datenbank fort, ohne Daten zu verlieren. 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:

Wenn Sie den Aurora Global Database-Writer-Endpunkt verwenden, müssen Sie die Verbindungseinstellungen in Ihrer Anwendung nicht ändern. Stellen Sie sicher, dass die DNS-Änderungen weitergegeben wurden und dass Sie eine Verbindung herstellen und Schreibvorgänge auf dem neuen primären Cluster ausführen können. Anschließend können Sie den vollen Betrieb Ihrer Anwendung wieder aufnehmen.

Angenommen, Ihre Anwendungsverbindungen verwenden den Cluster-Endpunkt des alten primären Clusters und nicht den globalen Writer-Endpunkt. Stellen Sie in diesem Fall sicher, dass Sie die Verbindungseinstellungen Ihrer Anwendung so ändern, dass sie den Cluster-Endpunkt des neuen primären Clusters 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 den RDS-Proxy verwenden, stellen Sie sicher, dass die Schreibvorgänge Ihrer Anwendung an den entsprechenden 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 Endpunkt umgeleitet werden. Weitere Informationen finden Sie unter So funktionieren RDS-Proxy-Endpunkte mit globalen Datenbanken.

Sie können einen Aurora Global Database-Switchover mithilfe der AWS Management Console AWS CLI, der oder der RDS-API durchführen.

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 Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.

2. Wählen Sie Datenbanken und suchen Sie die globale Aurora-Datenbank, in der Sie den Switchover durchfü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 für Neuer primärer Cluster einen aktiven Cluster in einer Ihrer sekundären AWS-Regionen 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 einen Switchover für Aurora Global Database durchzuführen. 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 als primäres Cluster für die globale Aurora-Datenbank hochstufen 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 einen Switchover für Aurora Global Database durchzuführen, führen Sie den SwitchoverGlobalClusterAPI-Vorgang aus.

Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall

In seltenen Fällen kann es bei Ihrer globalen Aurora-Datenbank zu einem unerwarteten Ausfall der AWS-Region Primärdatenbank 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 Ausfallzeiten (RTO) und Datenverlust (RPO) zu minimieren, können Sie schnell ein regionsübergreifendes Failover durchführen.

Aurora Global Database verfügt über zwei Failover-Methoden, die Sie in einer Notfallwiederherstellungssituation verwenden können:

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 Failovers wird der sekundäre Cluster in der von Ihnen ausgewählten sekundären Region zum neuen primären Cluster. 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. Sobald diese alte primäre Region fehlerfrei und wieder verfügbar ist, fügt Aurora sie automatisch wieder als sekundäre Region zum globalen Cluster hinzu. Somit wird die bestehende Replikationstopologie Ihrer globalen Aurora-Datenbank beibehalten.

Beim verwalteten Failover wird nicht darauf gewartet, dass Daten zwischen der ausgewählten sekundären Region und der aktuellen primären Region synchronisiert werden. Da Aurora Global Database Daten asynchron repliziert, ist es möglich, dass nicht alle Transaktionen in die gewählte sekundäre AWS Region repliziert wurden, bevor sie auf volle Lese-/Schreibfunktionen heraufgestuft wurde.

Um sicherzustellen, dass sich die Daten in einem konsistenten Zustand befinden, erstellt Aurora nach der Wiederherstellung ein neues Speichervolume für die alte Primärregion. Bevor das neue Speichervolume in der AWS Region erstellt wird, versucht Aurora, zum Zeitpunkt des Fehlers einen Snapshot des alten Speichervolumes zu erstellen. Auf diese Weise können Sie den Snapshot und 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 von AWS Management Console. Sie können auch den describe-db-cluster-snapshots AWS CLI Befehl oder die DescribeDBClusterSnapshots API-Operation verwenden, um Details für den Snapshot anzuzeigen.

Wenn Sie ein verwaltetes Failover initiieren, versucht Aurora auch, den Schreibverkehr über die hochverfügbare Aurora-Speicherschicht zu stoppen. Wir bezeichnen diesen Mechanismus als „Write-Fencing“. Wenn der Vorgang erfolgreich ist, gibt Aurora ein RDS-Ereignis aus, das Sie darüber informiert, dass Schreibvorgänge gestoppt wurden. Im unwahrscheinlichen Fall, dass mehrere AZ-Ausfälle in einer Region auftreten, ist es möglich, dass der Write-Fencing-Prozess nicht rechtzeitig erfolgreich ist. In diesem Fall gibt Aurora ein RDS-Ereignis aus, das Sie darüber informiert, dass das Zeitlimit für den Vorgang zum Stoppen von Schreibvorgängen überschritten wurde. Wenn der alte primäre Cluster im Netzwerk erreichbar ist, zeichnet Aurora diese Ereignisse dort auf. Wenn nicht, zeichnet Aurora die Ereignisse auf dem neuen primären Cluster auf. Weitere Informationen zu diesen Ereignissen finden Sie unterDB-Cluster-Ereignisse. Da das Fencing von Schreibvorgängen ein Versuch nach besten Kräften ist, ist es möglich, dass Schreibvorgänge vorübergehend in der alten primären Region akzeptiert werden, was zu Split-Brain-Problemen führt.

Wir empfehlen, dass Sie die folgenden Aufgaben ausführen, bevor Sie ein Failover mit Aurora Global Database durchführen. Dadurch wird die Möglichkeit von Split-Brain-Problemen oder der Wiederherstellung nicht replizierter Daten aus dem Snapshot des alten primären Clusters minimiert.

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 die Writer-DB-Instance der neuen primären Region verfügbar ist, können Sie Ihre Anwendungen damit verbinden und Ihre Workloads wieder aufnehmen. 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.

Wenn Sie den globalen Endpunkt verwenden, müssen Sie die Verbindungseinstellungen in Ihrer Anwendung nicht ändern. Stellen Sie sicher, dass die DNS-Änderungen übernommen wurden und dass Sie eine Verbindung herstellen und Schreibvorgänge auf dem neuen primären Cluster ausführen können. Anschließend können Sie den vollen Betrieb Ihrer Anwendung wieder aufnehmen.

Wenn Sie den globalen Endpunkt nicht verwenden, stellen Sie sicher, dass Sie den Endpunkt für Ihre Anwendung so ändern, dass er den Cluster-Endpunkt für den neu hochgestuften primären DB-Cluster verwendet. 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 den RDS-Proxy verwenden, stellen Sie sicher, dass die Schreibvorgänge Ihrer Anwendung an den entsprechenden 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 Endpunkt umgeleitet werden. 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, erstellt Aurora einen Snapshot mit dem Namenrds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp. Sie finden diesen Snapshot im Abschnitt Schnappschüsse der AWS Management Console. Sie können diesen Snapshot auch in den Informationen sehen, die vom API-Vorgang Describe DBCluster 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 mit Aurora Global Database mithilfe der AWS Management Console, der oder der AWS CLI RDS-API durchführen.

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 Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.

2. Wählen Sie Datenbanken und suchen Sie die globale Aurora-Datenbank, in der Sie den Failover durchführen möchten.

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

   

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

   

5. Für Neuer primärer Cluster wählen Sie einen aktiven Cluster in einer Ihrer sekundären AWS-Regionen als neuen primären Cluster aus.

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

Wenn der Failover abgeschlossen ist, können Sie die Aurora-DB-Cluster und ihren aktuellen Status in der Datenbankliste anzeigen, wie in der folgenden Abbildung dargestellt.

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 mit Aurora Global Database 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 als neuen primären Cluster für die globale Aurora-Datenbank hochstufen 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

Um ein Failover mit Aurora Global Database durchzuführen, führen Sie den FailoverGlobalClusterAPI-Vorgang aus.

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 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 einem neu konfiguriert haben AWS-Region, können Sie diesen nach Behebung AWS-Region des Ausfalls wieder zum primären Server machen. Dazu fügen Sie die alte Datenbank AWS-Region zu Ihrer neuen globalen Datenbank hinzu und wechseln dann mithilfe des Switchover-Prozesses ihre Rolle. Ihre Aurora Global Database muss eine Version von Aurora PostgreSQL oder Aurora MySQL verwenden, die Umstellungen unterstützt. Weitere Informationen finden Sie unter Durchführen von Umstellungen für Amazon Aurora Global Databases.

Verwaltung RPOs für globale Aurora-PostgreSQL-Datenbanken

Mit einer Aurora PostgreSQL–basierten globalen Datenbank können Sie den Recovery Point Objective (RPO)-Wert für Ihre globale Aurora-Datenbank mithilfe des Parameters rds.global_db_rpo verwalten. RPO gibt die maximale Datenmenge an, die im Falle eines Ausfalls verloren gehen kann.

Wenn Sie eine RPO für Ihre Aurora PostgreSQL–basierte globale Datenbank festlegen, überwacht Aurora die RPO-Verzögerungszeit aller sekundären Cluster, um sicherzustellen, dass mindestens ein sekundärer Cluster innerhalb des angestrebten RPO-Bereichs liegt. Die RPO-Verzögerungszeit ist eine weitere zeitbasierte Metrik.

Das RPO wird verwendet, wenn Ihre Datenbank nach einem Failover den Betrieb in einem neuen AWS-Region System wieder aufnimmt. Aurora bewertet RPO- und RPO-Verzögerungszeiten, um Transaktionen auf dem primären Netzwerk wie folgt zu übertragen (oder zu blockieren):

Wenn sich also alle sekundären Cluster hinter der Ziel-RPO befinden, pausiert Aurora die Transaktionen im primären Cluster, bis mindestens einer der sekundären Cluster den Rückstand aufholt. Pausierte Transaktionen werden fortgesetzt und übergeben, sobald die Verzögerungszeit mindestens eines sekundären DB-Clusters geringer ist als die RPO. Das Ergebnis ist, dass keine Transaktionen übertragen werden können, bis die RPO 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 im Folgenden beschrieben 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 Aurora PostgreSQL–basierten globalen Datenbank zu erhalten. Um zu erfahren wie, siehe Überwachung globaler Datenbanken SQL auf Basis von Aurora Postgre.

Festlegen des Recovery Point Objective

Der Parameter rds.global_db_rpo steuert die RPO-Einstellung für eine PostgreSQL-Datenbank. Dieser Parameter wird von Aurora PostgreSQL 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. Wenn Sie beispielsweise bis zu 10 Minuten für Ihre RPO festlegen möchten, dann setzen Sie den Wert auf 600.

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

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)

Die 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 einer Minute.

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

Sie können auch die CLI verwenden, um herauszufinden, ob in einem der Aurora-DB-Cluster rds.global_db_rpo aktiviert ist, indem Sie die CLI verwenden, um die Werte aller user-Parameter für den Cluster zu erhalten.

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 den RPO zu deaktivieren, setzen Sie den rds.global_db_rpo-Parameter zurück. Sie können Parameter über die AWS Management Console, die AWS CLI oder die RDS-API zurücksetzen.

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"