Verwenden von Umstellung oder Failover in einer Amazon Aurora Global Database - Amazon Aurora
Wiederherstellen einer globalen Aurora-Datenbank nach einem ungeplanten AusfallDurchführen von Umstellungen für Amazon Aurora Global DatabasesVerwalten von RPOs für Aurora PostgreSQL–basierte globale Datenbanken

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden von Umstellung oder Failover in einer Amazon Aurora Global Database

Eine globale Aurora-Datenbank bietet mehr Schutz für Business Continuity und Disaster Recovery (BCDR) als die Standard-Hochverfügbarkeit, die von einem Aurora-DB-Cluster in einer einzigen AWS-Region Region bereitgestellt wird. 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:

  • Recovery Time Objective (RTO) – Die Zeit, die ein System benötigt, um nach einem Notfall in einen arbeitsfähigen Zustand zurückzukehren. Mit anderen Worten: RTO misst die Ausfallzeit. Für eine globale Aurora-Datenbank kann sich die RTO in einer Größenordnung von Minuten bewegen.

  • Recovery Point Objective (RPO) – Die Datenmenge, die nach einer Katastrophe oder einem Serviceausfall verloren gehen kann (gemessen in Zeit). Dieser Datenverlust ist in der Regel auf asynchrone Replikationsverzögerungen zurückzuführen. Für eine globale Aurora-Datenbank wird die RPO in der Regel in Sekunden gemessen. Mit einer Aurora PostgreSQL–basierten globalen Datenbank können Sie den Parameter rds.global_db_rpo verwenden, um die RPO-Obergrenze festzulegen und zu überwachen, dies könnte jedoch die Transaktionsverarbeitung auf dem Writer-Knoten des primären Clusters beeinträchtigen. Weitere Informationen finden Sie unter Verwalten von RPOs für Aurora PostgreSQL–basierte globale Datenbanken.

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:

  • Failover – Verwenden Sie diesen Ansatz, um die Daten nach einem ungeplanten Ausfall wiederherzustellen. Damit führen Sie ein regionsübergreifendes Failover auf einen der sekundären DB-Cluster in Ihrer globalen Aurora-Datenbank durch. Das RPO für diesen Ansatz ist in der Regel ein Wert ungleich Null, der in Sekunden gemessen wird. Das Ausmaß des Datenverlusts hängt von der Verzögerung der globalen Aurora-Datenbankreplikation zum AWS-Regionen Zeitpunkt des Ausfalls ab. Weitere Informationen hierzu finden Sie unter Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall.

  • Umstellung – Dieser Vorgang wurde zuvor als „verwaltetes geplantes Failover“ bezeichnet. Dieser Ansatz ist für kontrollierte Umgebungen gedacht, z. B. für betriebliche Wartung und andere geplante Betriebsverfahren. Da diese Funktion die sekundären DB-Cluster mit dem primären synchronisiert, bevor andere Änderungen vorgenommen werden, ist der RPO 0 (kein Datenverlust). Weitere Informationen hierzu finden Sie unter Durchführen von Umstellungen für Amazon Aurora Global Databases.

Anmerkung

Wenn Sie zu einem kopflosen sekundären Aurora-DB-Cluster umstellen oder ein Failover durchführen möchten, müssen Sie diesem zunächst eine DB-Instance hinzufügen. Weitere Informationen zu kopflosen DB-Clustern finden Sie unter Erstellen eines Aurora-Headless-DB-Clusters in einer sekundären Region.

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 Ausfallzeiten (RTO) und 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:

  • Verwaltetes Failover — Diese Methode wird für die Notfallwiederherstellung empfohlen. Wenn Sie diese Methode verwenden, fügt Aurora die alte primäre Region automatisch wieder als sekundäre Region zur globalen Datenbank hinzu, sobald sie wieder verfügbar ist. Somit wird die ursprüngliche Topologie Ihres globalen Clusters beibehalten. Um zu erfahren, wie Sie diese Methode verwenden, vgl. Ausführen von verwalteten geplanten Failovers für globale Aurora-Datenbanken.

  • Manuelles Failover – Diese alternative Methode kann verwendet werden, wenn ein verwaltetes Failover nicht in Frage kommt, z. B. wenn in Ihren primären und sekundären Regionen inkompatible Engine-Versionen ausgeführt werden. Um zu erfahren, wie Sie diese Methode verwenden, vgl. Ausführen von manuellen geplanten Failovers für globale Aurora-Datenbanken.

Wichtig

Beide Failover-Methoden können zum Verlust von Schreibtransaktionsdaten führen, die vor dem Eintreten des Failover-Ereignisses nicht zur gewählten sekundären Region repliziert wurden. Der Wiederherstellungsprozess, der eine DB-Instance auf dem ausgewählten sekundären DB-Cluster zur primären Writer-DB-Instance hochstuft, garantiert jedoch, dass sich die Daten in einem transaktionskonsistenten Zustand befinden.

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.

Anmerkung

Sie können ein verwaltetes regionsübergreifendes Datenbank-Failover für eine globale Aurora-Datenbank nur durchführen, wenn die primären und sekundären DB-Cluster dieselben Engine-Haupt- und Nebenversionen sowie dasselbe Patch-Level haben. Die Patch-Level können je nach Nebenversion der Engine unterschiedlich sein. Weitere Informationen finden Sie unter Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failovers. Wenn Ihre Engine-Versionen nicht kompatibel sind, können Sie das Failover manuell durchführen, indem Sie die Schritte unter Ausführen von manuellen geplanten Failovers für globale Aurora-Datenbanken ausführen.

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

  • Schalten Sie Anwendungen offline, um zu verhindern, dass Schreibvorgänge an den primären Cluster der globalen Aurora-Datenbank gesendet werden.

  • Überprüfen Sie die Verzögerungszeiten für alle sekundären Aurora-DB-Cluster in der globalen Aurora-Datenbank. Durch die Auswahl der sekundären Region mit der geringsten Replikationsverzögerung kann der Datenverlust in der aktuell ausgefallenen primären Region minimiert werden. Verwenden Sie Amazon CloudWatch für alle Aurora PostgreSQL-basierten globalen Datenbanken und für Aurora MySQL-basierte globale Datenbanken ab Engine-Versionen 3.04.0 und höher oder 2.12.0 und höher, um die Metrik für alle sekundären DB-Cluster anzuzeigen. AuroraGlobalDBRPOLag Zeigen Sie für niedrigere Nebenversionen von Aurora MySQL-basierten globalen Datenbanken stattdessen die AuroraGlobalDBReplicationLag-Metrik an. Diese Metriken geben an, wie weit (in Millisekunden) ein sekundärer Cluster gegenüber dem primären DB-Cluster verzögert ist.

    Weitere Informationen zu CloudWatch Metriken für Aurora finden Sie unterMetriken auf Clusterebene für Amazon Aurora.

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:

  • Konfigurieren Sie die Aurora-DB-Cluster-Parametergruppe für den neuen primären Cluster, falls erforderlich – Sie können Ihre Aurora-DB-Cluster-Parametergruppen für jeden Aurora-Cluster in Ihrer globalen Aurora-Datenbank unabhängig konfigurieren. Wenn Sie also einen sekundären DB-Cluster zur Übernahme der primären Rolle hochstufen, kann die Parametergruppe des sekundären Clusters im Vergleich zum primären Cluster möglicherweise anders konfiguriert sein. Ist dies der Fall, ändern Sie die Parametergruppe des hochgestuften sekundären DB-Clusters so, dass sie den Einstellungen des primären Clusters entspricht. Um zu erfahren wie, siehe Ändern von Parametern für eine Aurora globale Datenbank.

  • Überwachungstools und -optionen wie Amazon CloudWatch Events und Alarme konfigurieren — Konfigurieren Sie den beworbenen DB-Cluster mit den gleichen Protokollierungsfunktionen, Alarmen usw., wie es für die globale Datenbank erforderlich ist. Wie bei Parametergruppen wird die Konfiguration für diese Funktionen während des Failover-Prozesses nicht vom primären Cluster übernommen. Einige CloudWatch Metriken, wie z. B. die Verzögerung bei der Replikation, sind nur für sekundäre Regionen verfügbar. Daher ändert ein Failover die Art und Weise, wie diese Metriken angezeigt und Alarme für sie eingerichtet werden, und es können Änderungen an allen vordefinierten Dashboards erforderlich sein. Weitere Informationen zu Aurora-DB-Clustern und zur Überwachung finden Sie unter Übersicht über die Überwachung von Amazon Aurora.

  • Integrationen mit anderen AWS Diensten konfigurieren — Wenn Ihre globale Aurora-Datenbank in AWS Dienste wie, AWS Secrets Manager AWS Identity and Access Management, Amazon S3 und integriert ist AWS Lambda, müssen Sie sicherstellen, dass diese nach Bedarf konfiguriert sind. Weitere Informationen zur Integration globaler Aurora-Datenbanken in IAM, Amazon S3 und Lambda finden Sie unter Verwenden von globalen Amazon-Aurora-Datenbanken mit anderen AWS-Services. Weitere Informationen zu Secrets Manager finden Sie unter So automatisieren Sie die Replikation von Geheimnissen in AWS Secrets Manager Across AWS-Regionen.

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 Sie die Schreibvorgänge Ihrer Anwendung an den entsprechenden Lese-/Schreibendpunkt 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.

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 von. AWS Management ConsoleSie können diesen Snapshot auch in den Informationen sehen, die von der DescribeDB-API-Operation zurückgegeben werden. ClusterSnapshots

Anmerkung

Der Snapshot des alten Speichervolumes ist ein System-Snapshot, der der auf dem alten primären Cluster konfigurierten Aufbewahrungsfrist für Backups unterliegt. Um diesen Snapshot außerhalb des Aufbewahrungszeitraums zu speichern, können Sie ihn kopieren, um ihn als manuellen Snapshot zu speichern. Weitere Informationen zum Kopieren von Snapshots, einschließlich der Preise, finden Sie unter Kopieren eines DB-Cluster-Snapshots.

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 mithilfe der AWS Management Console AWS CLI, der oder der RDS-API durchführen.

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

  1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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.

    Anzeige der Datenbankliste mit der ausgewählten globalen Datenbank und geöffnetem Aktionsmenü mit der Option „Globale Datenbank wechseln“ oder „Failover durchführen“.

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

    Das Dialogfeld „Globale Datenbank wechseln“ oder „Failover“, wobei „Failover (Datenverlust zulassen)“ ausgewählt ist.

  5. Wählen Sie für 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.

Anzeige der Datenbankliste mit der ausgewählten globalen Datenbank. Es wird jetzt angezeigt, dass der ausgewählte sekundäre Cluster die Rolle des primären Clusters hat und der alte primäre Cluster die Rolle eines sekundären Clusters hat.

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 auszufü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 für eine globale Aurora-Datenbank 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 Ihrer globalen Datenbank in Ihre sekundäre Zielregion durchzuführen.

Tipp

Bevor Sie diesen Prozess verwenden, sollten Sie sich damit vertraut machen. Halten Sie einen Plan bereit, um bei den ersten Anzeichen eines regionsweiten Problems schnell handeln zu können. Sie können bereit sein, die sekundäre Region mit der geringsten Replikationsverzögerung zu identifizieren, indem Sie Amazon CloudWatch regelmäßig verwenden, um die Verzögerungszeiten für die sekundären Cluster zu verfolgen. Testen Sie Ihren Plan, um zu überprüfen, ob Ihre Verfahren vollständig und genau sind, und stellen Sie sicher, dass die Mitarbeiter darin geschult sind, ein Failover für die Notfallwiederherstellung durchzuführen, bevor es wirklich erforderlich ist.

Führen Sie nach einem ungeplanten Ausfall in der primären Region ein Failover auf einen sekundären Cluster wie folgt manuell durch:

  1. Beenden Sie die Ausgabe von DML-Anweisungen und anderen Schreibvorgängen an den primären Aurora-DB-Cluster während des AWS-Region Ausfalls.

  2. Identifizieren Sie einen Aurora-DB-Cluster von einem sekundären AWS-Region , der als neuer primärer DB-Cluster verwendet werden soll. Wenn Sie zwei oder mehr sekundäre Cluster AWS-Regionen in Ihrer globalen Aurora-Datenbank haben, wählen Sie den sekundären Cluster mit der geringsten Replikationsverzögerung.

  3. Trennen Sie Ihren ausgewählten sekundären DB-Cluster von der globalen Aurora-Datenbank.

    Das Entfernen eines sekundären DB-Clusters aus einer globalen Aurora-Datenbank stoppt sofort die Replikation vom primären zu diesem sekundären Cluster und stuft ihn als ein eigenständiges bereitgestelltes Aurora-DB-Cluster mit uneingeschränkter Lese-/Schreibfunktion ein. Alle anderen sekundären Aurora-DB-Cluster, die mit dem primären Cluster in der Region mit dem Ausfall verknüpft sind, sind weiterhin verfügbar und können Aufrufe von Ihrer Anwendung annehmen. Sie verbrauchen auch Ressourcen. Da Sie die globale Aurora-Datenbank neu erstellen, entfernen Sie die anderen sekundären DB-Cluster, bevor Sie die neue globale Aurora-Datenbank in den folgenden Schritten erstellen. Dadurch werden Dateninkonsistenzen zwischen den DB-Clustern in der globalen Aurora-Datenbank vermieden (split-brain-Probleme).

    Ausführliche Schritte zum Trennen finden Sie unter Entfernen eines Clusters aus einer Amazon Aurora Global Database.

  4. Konfigurieren Sie Ihre Anwendung neu, um alle Schreibvorgänge mit ihrem neuen Endpunkt an diesen eigenständigen Aurora-DB-Cluster zu senden. 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 Clusters in Ihrer Anwendung entfernen.

    Beispielsweise wird der Endpunkt my-global.cluster-ro-aaaaaabbbbbb.us-west-1.rds.amazonaws.com des sekundären Clusters zu my-global.cluster-aaaaaabbbbbb.us-west-1.rds.amazonaws.com, wenn dieser Cluster von der globalen Aurora-Datenbank getrennt wird.

    Dieser Aurora-DB-Cluster wird zum primären Cluster einer neuen globalen Aurora-Datenbank, wenn Sie im nächsten Schritt beginnen Regionen hinzuzufügen.

    Wenn Sie RDS-Proxy verwenden, stellen Sie sicher, dass Sie die Schreibvorgänge Ihrer Anwendung an den entsprechenden Lese-/Schreibendpunkt 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.

  5. Fügen Sie AWS-Region dem DB-Cluster einen hinzu. Wenn Sie dies tun, beginnt der Replikationsprozess vom primären zum sekundären Cluster. Ausführliche Schritte zum Hinzufügen einer Region finden Sie unter Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank.

  6. Fügen Sie nach AWS-Regionen Bedarf weitere hinzu, um die Topologie wiederherzustellen, die zur Unterstützung Ihrer Anwendung erforderlich ist.

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 AWS-Region Ihrer neuen globalen Datenbank hinzu und verwenden dann den Umstellungs-Prozess, um die Rolle zu wechseln. 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.

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

Anmerkung

Umstellungen wurden früher als „verwaltete geplante Failovers“ bezeichnet.

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.

  • Für Anforderungen an die „regionale Rotation“, die in bestimmten Branchen gelten. Beispielsweise könnten die Vorschriften für Finanzdienstleistungen vorschreiben, dass Tier-0-Systeme für mehrere Monate in eine andere Region wechseln müssen, um sicherzustellen, dass die Notfallwiederherstellungsverfahren regelmäßig geübt werden.

  • Für "follow-the-sun" -Anwendungen mit mehreren Regionen. Beispielsweise möchte ein Unternehmen möglicherweise Schreibvorgänge mit niedrigerer Latenz in verschiedenen Regionen bereitstellen, basierend auf den Geschäftszeiten in verschiedenen Zeitzonen.

  • Als zero-data-loss Methode, um nach einem Failover zur ursprünglichen primären Region zurückzukehren.

Anmerkung

Umstellungen sind so konzipiert, dass sie auf einer funktionierenden Aurora Global Database verwendet werden können. Folgen Sie zur Wiederherstellung nach einem ungeplanten Ausfall dem entsprechenden Verfahren unter Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall.

Um eine Umstellung durchführen zu können, muss Ihr sekundärer DB-Cluster genau dieselbe Engine-Version ausführen, einschließlich des Patch-Levels, je nach Engine-Version. Weitere Informationen finden Sie unter Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failovers. Bevor Sie mit der Umstellung beginnen, überprüfen Sie die Engine-Versionen in Ihrem globalen Cluster, um sicherzustellen, dass diese verwaltete regionsübergreifende Umstellungen unterstützen, und aktualisieren Sie sie bei Bedarf.

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:

  • Führen Sie diesen Vorgang außerhalb der Spitzenzeiten oder zu einem anderen Zeitpunkt durch, wenn die Schreibvorgänge auf den primären DB-Clustern minimal sind.

  • Schalten Sie Anwendungen offline, um zu verhindern, dass Schreibvorgänge an den primären Cluster der globalen Aurora-Datenbank gesendet werden.

  • Überprüfen Sie die Verzögerungszeiten für alle sekundären Aurora-DB-Cluster in der globalen Aurora-Datenbank. Verwenden Sie Amazon CloudWatch für alle Aurora PostgreSQL-basierten globalen Datenbanken und für Aurora MySQL-basierte globale Datenbanken ab Engine-Versionen 3.04.0 und höher oder 2.12.0 und höher, um die Metrik für alle sekundären DB-Cluster anzuzeigen. AuroraGlobalDBRPOLag Zeigen Sie für niedrigere Nebenversionen von Aurora MySQL-basierten globalen Datenbanken stattdessen die AuroraGlobalDBReplicationLag-Metrik an. Diese Metriken geben an, wie weit (in Millisekunden) ein sekundärer Cluster gegenüber dem primären DB-Cluster verzögert ist. Der Wert verhält sich direkt proportional zu der Zeit, die Aurora zum Abschließen der Umstellung benötigt. Je größer der Verzögerungswert, desto länger dauert die Umstellung.

    Weitere Informationen zu CloudWatch Metriken für Aurora finden Sie unterMetriken auf Clusterebene für Amazon Aurora.

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:

  • Konfigurieren Sie die Aurora-DB-Cluster-Parametergruppe für den neuen primären Cluster, falls erforderlich – Sie können Ihre Aurora-DB-Cluster-Parametergruppen für jeden Aurora-Cluster in Ihrer globalen Aurora-Datenbank unabhängig konfigurieren. Wenn Sie also einen sekundären DB-Cluster zur Übernahme der primären Rolle hochstufen, kann die Parametergruppe des sekundären Clusters im Vergleich zum primären Cluster möglicherweise anders konfiguriert werden. Ist dies der Fall, ändern Sie die Parametergruppe des hochgestuften sekundären DB-Clusters so, dass sie den Einstellungen des primären Clusters entspricht. Um zu erfahren wie, siehe Ändern von Parametern für eine Aurora globale Datenbank.

  • Überwachungstools und -optionen wie Amazon CloudWatch Events und Alarme konfigurieren — Konfigurieren Sie den beworbenen DB-Cluster mit den gleichen Protokollierungsfunktionen, Alarmen usw., wie es für die globale Datenbank erforderlich ist. Wie bei Parametergruppen wird die Konfiguration für diese Funktionen während der Umstellung nicht vom primären Cluster übernommen. Einige CloudWatch Metriken, wie z. B. die Verzögerung bei der Replikation, sind nur für sekundäre Regionen verfügbar. Daher ändert sich bei einer Umstellung die Art und Weise, wie diese Metriken angezeigt und Alarme für sie eingerichtet werden, und es können Änderungen an allen vordefinierten Dashboards erforderlich sein. Weitere Informationen zu Aurora-DB-Clustern und zur Überwachung finden Sie unter Übersicht über die Überwachung von Amazon Aurora.

  • Integrationen mit anderen AWS Diensten konfigurieren — Wenn Ihre globale Aurora-Datenbank in AWS Dienste wie Amazon S3 integriert ist AWS Secrets Manager AWS Identity and Access Management, stellen Sie sicher AWS Lambda, dass Sie Ihre Integrationen mit diesen Diensten nach Bedarf konfigurieren. Weitere Informationen zur Integration globaler Aurora-Datenbanken in IAM, Amazon S3 und Lambda finden Sie unter Verwenden von globalen Amazon-Aurora-Datenbanken mit anderen AWS-Services. Weitere Informationen zu Secrets Manager finden Sie unter So automatisieren Sie die Replikation von Geheimnissen in AWS Secrets Manager Across AWS-Regionen.

Anmerkung

In der Regel kann der Rollenwechsel bis zu mehreren Minuten dauern. Das Erstellen zusätzlicher sekundärer Cluster kann jedoch je nach Größe Ihrer Datenbank und der physischen Entfernung zwischen den Regionen einige Minuten bis mehrere Stunden dauern.

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-/Schreibendpunkt 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 mithilfe der AWS Management Console, der oder der AWS CLI RDS-API umschalten.

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

  1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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.

    Anzeige der Datenbankliste mit der ausgewählten globalen Datenbank und geöffnetem Aktionsmenü mit der Option Umschalten oder Failover der globalen Datenbank.

  4. Wählen Sie Umschaltung.

    Das Dialogfeld Umschalten oder Failover der globalen Datenbank, mit aktivierter Option Failover (Datenverlust zulassen).

  5. Wählen Sie für 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.

Anzeige der Datenbankliste mit der ausgewählten globalen Datenbank. Es wird jetzt angezeigt, dass der ausgewählte sekundäre Cluster die Rolle des primären Clusters hat und der alte primäre Cluster die Rolle eines sekundären Clusters hat.

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

Verwenden Sie den switchover-global-cluster-CLI-Befehl, um eine Umstellung für Ihre Aurora Global Database auszufü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 zu einer globalen Aurora-Datenbank zu wechseln, führen Sie den SwitchoverGlobalClusterAPI-Vorgang aus.

Verwalten von RPOs für Aurora PostgreSQL–basierte globale 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 AWS-Region nach einem Failover den Betrieb in einer neuen Datenbank wieder aufnimmt. Aurora bewertet RPO- und RPO-Verzögerungszeiten, um Transaktionen auf dem primären Netzwerk wie folgt zu übertragen (oder zu blockieren):

  • Die Transaktion wird durchgeführt, wenn mindestens ein sekundärer DB-Cluster eine RPO-Verzögerungszeit hat, die kleiner ist als die RPO.

  • Die Transaktion wird blockiert, wenn alle sekundären DB-Cluster RPO-Verzögerungszeiten haben, die größer sind als die RPO. Außerdem wird das Ereignis in der PostgreSQL-Protokolldatei erfasst und es werden Warteereignisse ausgegeben, die die blockierten Sessions anzeigen.

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.

Wichtig

In einer globalen Datenbank mit nur zwei Regionen empfehlen wir, den Standardwert des Parameters rds.global_db_rpo in der Parametergruppe der sekundären Region beizubehalten. Andernfalls könnte ein Failover zu dieser Region aufgrund eines Verlusts der primären Region dazu führen, dass Aurora Transaktionen unterbricht. Warten Sie stattdessen, bis Aurora den Neuaufbau des Clusters in der alten ausgefallenen Region abgeschlossen hat, bevor Sie diesen Parameter ändern, um ein maximales RPO zu erzwingen.

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 Aurora PostgreSQL–basierten globalen Datenbank zu erhalten. Um zu erfahren wie, siehe Überwachen von Aurora-PostgreSQL-basierten globalen Datenbanken.

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.

So legen Sie den RPO fest:

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

  2. Wählen Sie den primären Cluster Ihrer globalen Aurora-Datenbank und öffnen Sie die Registerkarte Konfiguration, um die DB-Cluster-Parametergruppe zu suchen. Die Standardparametergruppe für ein primäres DB-Cluster mit Aurora PostgreSQL 11.7 ist beispielsweise default.aurora-postgresql11.

    Parametergruppen können nicht direkt bearbeitet werden. Stattdessen führen Sie die folgenden Schritte aus:

    • Erstellen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe, wobei Sie die entsprechende Standardparametergruppe als Ausgangspunkt verwenden. So erstellen Sie beispielsweise eine benutzerdefinierte DB-Cluster-Parametergruppe basierend au default.aurora-postgresql11.

    • Legen Sie in Ihrer benutzerdefinierten DB-Parametergruppe den Wert des Parameters rds.global_db_rpo fest, der Ihrem Anwendungsfall entspricht. Gültige Werte liegen zwischen 20 Sekunden und dem maximalen ganzzahligen Wert von 2.147.483.647 (68 Jahre).

    • Wenden Sie die geänderte DB-Cluster-Parametergruppe auf Ihr Aurora-DB-Cluster an.

Weitere Informationen finden Sie unter Ändern von Parametern in einer DB-Cluster-Parametergruppe.

Verwenden Sie den CLI-Befehl modify-db-cluster-parameter-group, um den rds.global_db_rpo Parameter festzulegen. Geben Sie im Befehl den Namen der Parametergruppe Ihres primären Clusters und die Werte für den RPO-Parameter an.

Im folgenden Beispiel wird die RPO für die primäre DB-Cluster-Parametergruppe namens auf 600 Sekunden (10 Minuten) festgeleg my_custom_global_parameter_group.

Für LinuxmacOS, oderUnix:

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"

Verwenden Sie den Amazon RDS ClusterParameterGroupModifyDB-API-Vorgang, um den rds.global_db_rpo Parameter zu ändern.

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ürLinux, odermacOS: 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

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 Anzeigen der Parameterwerte für eine DB-Cluster-Parametergruppe.

Deaktivieren des Recovery Point Objective

Um den RPO zu deaktivieren, setzen Sie den rds.global_db_rpo-Parameter zurück. Sie können Parameter mithilfe der AWS Management Console AWS CLI, der oder der RDS-API zurücksetzen.

So deaktivieren Sie den RPO:

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

  2. Wählen Sie im Navigationsbereich Parameter groups (Parametergruppen) aus.

  3. Wählen Sie in der Liste Ihre primäre DB-Cluster-Parametergruppe aus.

  4. Wählen Sie Parameter bearbeiten aus.

  5. Wählen Sie das Feld neben dem Parameter rds.global_db_rpo aus.

  6. Klicken Sie auf Reset (Zurücksetzen).

  7. Wenn auf dem Bildschirm Reset parameters in DB parameter group (Parameter in DB-Parametergruppe zurücksetzen) angezeigt wird, wählen Sie Reset parameters (Parameter zurücksetzen) aus.

Weitere Informationen zum Zurücksetzen eines Parameters mit der Konsole finden Sie unter Ändern von Parametern in einer DB-Cluster-Parametergruppe.

Verwenden Sie den Befehl reset-db-cluster-parameter-group, um den rds.global_db_rpo Parameter zurückzusetzen.

Für LinuxmacOS, oderUnix:

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"

Verwenden Sie den Amazon RDS-API-Vorgang ResetDB ClusterParameterGroup, um den rds.global_db_rpo Parameter zurückzusetzen.