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 Amazon Aurora Global Database
Mit der Funktion von Amazon Aurora Global Database richten Sie mehrere Aurora-DB-Cluster ein, die sich über mehrere AWS-Regionen erstrecken. Aurora synchronisiert automatisch alle im primären DB-Cluster vorgenommenen Änderungen mit einem oder mehreren sekundären Clustern. Eine globale Aurora-Datenbank hat einen primären DB-Cluster in einer Region und bis zu 10 sekundäre DB-Cluster in verschiedenen Regionen. Diese multiregionale Konfiguration ermöglicht eine schnelle Wiederherstellung nach einem seltenen Ausfall, der sich auf die gesamte AWS-Region auswirken könnte. Eine vollständige Kopie all Ihrer Daten an mehreren geografischen Standorten ermöglicht auch Lesevorgänge mit geringer Latenzzeit für Anwendungen, die von weit voneinander entfernten globalen Standorten aus eine Verbindung herstellen.
**Topics**
+ [Übersicht über Amazon Aurora Global Database](#aurora-global-database-overview)
+ [Vorteile von Amazon Aurora Global Database](#aurora-global-database.advantages)
+ [Verfügbarkeit von Regionen und Versionen](#aurora-global-database.Availability)
+ [Einschränkungen von Amazon Aurora Global Database](#aurora-global-database.limitations)
+ [Erste Schritte mit Amazon Aurora Global Database](aurora-global-database-getting-started.md)
+ [Verwalten einer Amazon Aurora Global Database](aurora-global-database-managing.md)
+ [Verbinden mit Amazon Aurora Global Database](aurora-global-database-connecting.md)
+ [Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank](aurora-global-database-write-forwarding.md)
+ [Verwenden von Umstellung oder Failover in Amazon Aurora Global Database](aurora-global-database-disaster-recovery.md)
+ [Überwachen einer globalen Amazon-Aurora-Datenbank](aurora-global-database-monitoring.md)
+ [Blue/Green Bereitstellungen für Amazon Aurora Global Database verwenden](aurora-global-database-bluegreen.md)
+ [Verwendung der globalen Amazon Aurora Aurora-Datenbanken mit anderen AWS Diensten](aurora-global-database-interop.md)
+ [Aktualisieren einer globalen Datenbank von Amazon Aurora](aurora-global-database-upgrade.md)
## Übersicht über Amazon Aurora Global Database
Durch die Verwendung der Funktion von Amazon Aurora Global Database können Sie Ihre global verteilten Anwendungen mit einer einzigen Aurora-Datenbank ausführen, die sich über mehrere AWS-Regionen erstreckt.
*Eine globale Aurora-Datenbank besteht aus einer *primären* Datenbank, AWS-Region in die Ihre Daten geschrieben werden, und bis zu 10 schreibgeschützten sekundären Datenbanken.* AWS-Regionen Schreibvorgänge erfolgen direkt auf dem primären DB-Cluster in der primären AWS-Region. Am einfachsten ist es, eine Verbindung zum Writer-Endpunkt von Aurora Global Database herzustellen, der immer auf den primären DB-Cluster verweist, auch nach einer Umstellung oder einem Failover zu einer anderen AWS-Region. Nach jedem Schreibvorgang repliziert Aurora Daten AWS-Regionen mithilfe einer dedizierten Infrastruktur auf die Sekundärseite, wobei die Latenz in der Regel unter einer Sekunde liegt.
In der folgenden Abbildung finden Sie ein Beispiel für eine globale Aurora-Datenbank, die sich über zwei AWS-Regionen erstreckt.
![\[Eine globale Aurora-Datenbank hat einen einzelnen primären und mindestens einen sekundären Aurora-DB-Cluster.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-conceptual-illo.png)
Sie können jeden sekundären Cluster separat hochskalieren, indem Sie eine oder mehrere Aurora-Reader-Instances zum Bedienen schreibgeschützter Workloads hinzufügen. Sie können Aurora Serverless v2 für die Reader-Instances verwenden, um noch detaillierter und flexibler Skalieren zu können.
Nur der primäre Cluster führt Schreibvorgänge aus. Clients, die Schreibvorgänge ausführen, stellen eine Verbindung zum Writer-Endpunkt der globalen Aurora-Datenbank her, der immer auf die Writer-DB-Instance des primären Clusters verweist. Wie im Diagramm dargestellt, verwendet Aurora das Cluster-Speicher-Volume und nicht die Datenbank-Engine für die schnelle Replikation mit geringem Overhead. Weitere Informationen hierzu finden Sie unter [Übersicht über Amazon-Aurora-Speicher](Aurora.Overview.StorageReliability.md#Aurora.Overview.Storage).
Aurora Global Database ist für Anwendungen mit weltweiter Präsenz konzipiert. Die mehrfachen schreibgeschützten sekundären DB-Cluster AWS-Regionen helfen dabei, Lesevorgänge in der Nähe der Anwendungsbenutzer zu optimieren. Mit dem Funktion der Schreibweiterleitung können Sie Ihre globale Aurora-Datenbank auch so konfigurieren, dass sekundäre Cluster Daten an primäre Cluster senden. Weitere Informationen finden Sie unter [Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank](aurora-global-database-write-forwarding.md).
Aurora Global Database unterstützt je nach Szenario zwei verschiedene Operationen zum Ändern der Region Ihres primären DB-Clusters: *Umstellung von Aurora Global Database* und *Failover von Aurora Global Database*.
+ Verwenden Sie für geplante operative Verfahren wie die regionale Rotation den Umstellungsmechanismus (früher als „verwaltetes geplantes Failover“ bezeichnet). Mit dieser Funktion können Sie den primären Cluster einer fehlerfreien globalen Aurora-Datenbank ohne Datenverlust in eine der sekundären Regionen verschieben. Weitere Informationen hierzu finden Sie unter [Durchführen von Umstellungen für Amazon Aurora Global Databases](aurora-global-database-disaster-recovery.md#aurora-global-database-disaster-recovery.managed-failover).
+ Um Ihre globale Aurora-Datenbank nach einem Ausfall in der primären Region wiederherzustellen, verwenden Sie den Failover-Mechanismus. Mit dieser Funktion führen Sie ein Failover Ihres primären DB-Clusters zu einer anderen Region durch (regionsübergreifendes Failover). Weitere Informationen hierzu finden Sie unter [Ausführen von verwalteten geplanten Failovers für globale Aurora-Datenbanken](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.managed-unplanned).
## Vorteile von Amazon Aurora Global Database
Durch die Verwendung von Aurora Global Database profitieren Sie von folgenden Vorteilen:
+ **Globale Lesevorgänge mit lokaler Latenz** – Wenn Sie Niederlassungen auf der ganzen Welt haben, können Sie Aurora Global Database nutzen, um die wichtigsten Datenquellen in der primären AWS-Region auf dem neuesten Stand zu halten. Niederlassungen in Ihren anderen Regionen können mit lokaler Latenz auf die Daten in ihrer eigenen Region zugreifen.
+ **Skalierbare sekundäre Aurora-DB-Cluster** – Sie können Ihre sekundären Cluster skalieren, indem Sie einer sekundären AWS-Region weitere schreibgeschützte Instances hinzufügen. Der sekundäre Cluster ist schreibgeschützt und kann daher bis zu 16 schreibgeschützte DB-Instances anstelle des üblichen Limits von 15 für einen einzelnen Aurora-Cluster unterstützen.
+ **Schnelle Replikation von primären zu sekundären Aurora-DB-Clustern** – Die von Aurora Global Database ausgeführte Replikation führt zu geringen Leistungseinbußen auf dem primären DB-Cluster. Die Ressourcen der DB-Instances werden ausschließlich für Lese- und Schreib-Workloads von Anwendungen genutzt.
+ **Wiederherstellung nach regionsweiten Ausfällen** – Die sekundären Cluster ermöglichen Ihnen, eine globale Aurora-Datenbank in einer neuen primären AWS-Region schneller (niedrigere RTO) und mit weniger Datenverlust (niedrigerer RPO) als herkömmliche Replikationslösungen verfügbar zu machen.
## Verfügbarkeit von Regionen und Versionen
Die Verfügbarkeit von Funktionen und der Support variieren zwischen bestimmten Versionen der einzelnen Aurora-Datenbank-Engines und in allen AWS-Regionen. Weitere Informationen zur Verfügbarkeit von Versionen und Regionen im Zusammenhang mit Aurora Global Database finden Sie unter [Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
## Einschränkungen von Amazon Aurora Global Database
Für Aurora Global Database gelten aktuell die folgenden Einschränkungen:
+ Aurora Global Database ist in bestimmten AWS-Regionen und für bestimmte Versionen von Aurora MySQL und Aurora PostgreSQL verfügbar. Weitere Informationen finden Sie unter [Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
+ Aurora Global Database stellt bestimmte Konfigurationsanforderungen an unterstützte DB-Instance-Klassen von Aurora, beispielsweise eine maximale Anzahl von AWS-Regionen. Weitere Informationen finden Sie unter [Anforderungen an die Konfiguration einer globalen Amazon-Aurora-Datenbank](aurora-global-database.configuration.requirements.md).
+ Bei Aurora MySQL mit MySQL-5.7-Kompatibilität sind für Umstellungen von Aurora Global Database die Version 2.09.1 oder höhere Nebenversionen erforderlich.
+ Sie können verwaltete regionsübergreifende Umstellungen oder Failover nur mit Aurora Global Database durchführen, wenn die primären und sekundären DB-Cluster dieselben Engine-Haupt- und Nebenversionen haben. Je nach Engine und Engine-Versionen müssen die Patch-Level möglicherweise identisch sein oder können unterschiedlich sein. Eine Liste der Engines und Engine-Versionen, die diese Operationen zwischen primären und sekundären Clustern mit unterschiedlichen Patch-Leveln unterstützen, finden Sie unter [Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failover](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility). Wenn Ihre Engine-Versionen identische Patch-Level erfordern, können Sie das Failover manuell durchführen, indem Sie die Schritte unter [Ausführen von manuellen geplanten Failovers für globale Aurora-Datenbanken](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.manual-unplanned) ausführen.
+ Aurora Global Database unterstützt derzeit die folgenden Aurora-Funktionen nicht:
+ Aurora Serverless v1
+ Rückverfolgung in Aurora
+ Informationen zu Einschränkungen bei der Verwendung der RDS-Proxy-Funktion mit Aurora Global Database finden Sie unter [Einschränkungen für RDS Proxy mit globalen Datenbanken](rds-proxy-gdb.md#rds-proxy-gdb.limitations).
+ Die automatische Aktualisierung von Nebenversionen gilt nicht für Aurora-MySQL- und Aurora-PostgreSQL-Cluster, die Teil einer globalen Datenbank sind. Beachten Sie, dass Sie diese Einstellung für eine DB-Instance angeben können, die Teil eines globalen Datenbank-Clusters ist, aber die Einstellung hat keine Auswirkungen.
+ Aurora Global Database unterstützt derzeit kein Aurora-Auto-Scaling für sekundäre DB-Cluster.
+ Um Database Activity Streams (DAS) auf einer globalen Aurora-Datenbank zu verwenden, auf der Aurora MySQL 5.7 ausgeführt wird, muss die Engine-Version 2.08 oder höher sein. Weitere Informationen zu DAS finden Sie unter [Überwachung von Amazon Aurora mithilfe von Datenbankaktivitätsstreams](DBActivityStreams.md).
+ Für ein Upgrade von Aurora Global Database gelten aktuell die folgenden Einschränkungen:
+ Sie können keine benutzerdefinierte Parametergruppe auf den globalen Datenbank-Cluster anwenden, während Sie ein Hauptversions-Upgrade dieser globalen Aurora-Datenbank durchführen. Sie erstellen Ihre benutzerdefinierten Parametergruppen in jeder Region des globalen Clusters und wenden sie nach dem Upgrade manuell auf die regionalen Cluster an.
+ Mit einer globalen Aurora-Datenbank, die auf Aurora MySQL basiert, können Sie kein direktes Upgrade von Aurora MySQL Version 2 auf Version 3 durchführen, wenn der `lower_case_table_names`-Parameter aktiviert ist. Weitere Informationen zu den möglichen Verfahren finden Sie unter [Hauptversions-Upgrades](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
+ Mit Aurora Global Database können Sie kein Upgrade der Hauptversion der DB-Engine von Aurora PostgreSQL durchführen, wenn die Recovery Point Objective (RPO)-Funktion aktiviert ist. Weitere Informationen über die RPO-Funktion finden Sie unter [Verwalten von RPOs für Aurora PostgreSQL–basierte globale Datenbanken](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery).
+ Bei einer globalen Aurora-Datenbank können Sie kein Nebenversions-Upgrade von Aurora-MySQL-Version 3.01 oder 3.02 auf 3.03 oder höher durchführen, indem Sie den Standardprozess verwenden. Weitere Informationen zu dem zu verwendenden Prozess finden Sie unter [Upgrade von Aurora MySQL durch Ändern der Engine-Version](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md).
Informationen zum Upgrade von Aurora Global Database finden Sie unter [Aktualisieren einer globalen Datenbank von Amazon Aurora](aurora-global-database-upgrade.md).
+ Sie können die Aurora-DB-Cluster in Ihrer globalen Datenbank nicht einzeln anhalten oder starten. Weitere Informationen hierzu finden Sie unter [Stoppen und Starten eines Amazon Aurora-DB-Clusters](aurora-cluster-stop-start.md).
+ Reader-DB-Instances von Aurora, die mit dem sekundären Aurora-DB-Cluster verbunden sind, können unter bestimmten Umständen neu gestartet werden. Wenn die AWS-Region Writer-DB-Instance der primären Instanz neu gestartet oder ausgefallen wird, werden auch die Leser-DB-Instances in den sekundären Regionen neu gestartet. Der sekundäre Cluster ist erst dann wieder verfügbar, wenn alle Reader-DB-Instances wieder mit der Writer-Instance des primären DB-Clusters synchronisiert sind. Das Verhalten des primären Clusters beim Neustart oder beim Failover ist dasselbe wie bei einem einzelnen, nicht globalen DB-Cluster. Weitere Informationen finden Sie unter [Replikation mit Amazon Aurora](Aurora.Replication.md).
Stellen Sie sicher, dass Sie die Auswirkungen auf Ihre globale Datenbank verstehen, bevor Sie Änderungen an Ihrem primären DB-Cluster vornehmen. Weitere Informationen hierzu finden Sie unter [Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall](aurora-global-database-disaster-recovery.md#aurora-global-database-failover).
+ Aurora Global Database unterstützt derzeit nicht den `inaccessible-encryption-credentials-recoverable` Status, wenn Amazon Aurora den Zugriff auf den AWS KMS Schlüssel für den DB-Cluster verliert. In diesen Fällen wechselt der verschlüsselte DB-Cluster direkt in den Beendigungszustand `inaccessible-encryption-credentials`. Weitere Informationen zu diesen Zuständen finden Sie unter [Anzeigen des DB-Clusterstatus](accessing-monitoring.md#Aurora.Status).
+ Secrets Manager unterstützt Aurora Global Database nicht. Wenn Sie einer globalen Datenbank eine Region hinzufügen, müssen Sie zuerst die Secrets-Manager-Integration für die DB-Instance deaktivieren.
+ Für Aurora-PostgreSQL-basierte DB-Cluster, die Aurora Global Database verwenden, gelten folgende Einschränkungen:
+ Die Verwaltung des Cluster-Cache wird für sekundäre DB-Cluster von Aurora PostgreSQL, die Teil der globalen Aurora-Datenbanken sind, nicht unterstützt.
+ Wenn der primäre DB-Cluster Ihrer globalen Datenbank auf dem Replikat einer PostgreSQL-Instance von Amazon RDS basiert, können Sie keinen sekundären Cluster erstellen. Versuchen Sie nicht, mithilfe der API-Operation, der oder der AWS-Managementkonsole`CreateDBCluster` API-Operation eine sekundäre AWS CLI Komponente aus diesem Cluster zu erstellen. Solche Versuche werden unterbrochen und der sekundäre Cluster wird nicht erstellt.
Wir empfehlen, dass Sie sekundäre DB-Cluster für Ihre globalen Datenbanken erstellen, indem Sie die Version der Aurora-DB-Engine verwenden, die auch für den primären Cluster verwendet wird. Weitere Informationen finden Sie unter [Erstellen einer globalen Datenbank von Amazon Aurora](aurora-global-database-creating.md).
# Erste Schritte mit Amazon Aurora Global Database
Um mit Aurora Global Database zu beginnen, müssen Sie zunächst entscheiden, welche Aurora-DB-Engine Sie verwenden möchten und in welchen AWS-Regionen. Nur bestimmte Versionen der Datenbank-Engines von Aurora MySQL und Aurora PostgreSQL in bestimmten AWS-Regionen unterstützen Aurora Global Database. Die vollständige Liste finden Sie unter [Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
Sie können eine globale Aurora-Datenbank auf eine der folgenden Arten erstellen:
+ **Erstellen einer neuen globalen Aurora-Datenbank mit neuen Aurora-DB-Clustern und Aurora-DB-Instances** – Sie können dies tun, indem Sie die unter [Erstellen einer globalen Datenbank von Amazon Aurora](aurora-global-database-creating.md) beschriebenen Schritte ausführen. Nachdem Sie den primären Aurora-DB-Cluster erstellt haben, fügen Sie die sekundäre AWS-Region hinzu, indem Sie die unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md) beschriebenen Schritte ausführen.
+ **Verwenden eines vorhandenen Aurora-DB-Clusters, der die Funktion von Aurora Global Database unterstützt und diesem eine AWS-Region hinzufügen** – Dies können Sie nur tun, wenn Ihr vorhandener Aurora-DB-Cluster eine DB-Engine-Version verwendet, die global kompatibel ist.
Überprüfen Sie, ob Sie in **Region hinzufügen** als **Aktion** auf AWS-Managementkonsole auswählen können, wenn Ihr Aurora-DB-Cluster ausgewählt ist. Wenn das möglich ist, können Sie diesen Aurora-DB-Cluster als globalen Aurora-Cluster verwenden. Weitere Informationen finden Sie unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
Bevor Sie eine globale Aurora-Datenbank erstellen, sollten Sie sich mit allen Konfigurationsanforderungen vertraut machen.
**Topics**
+ [Anforderungen an die Konfiguration einer globalen Amazon-Aurora-Datenbank](aurora-global-database.configuration.requirements.md)
+ [Erstellen einer globalen Datenbank von Amazon Aurora](aurora-global-database-creating.md)
+ [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md)
+ [Erstellen eines Aurora-Headless-DB-Clusters in einer sekundären Region](aurora-global-database-attach.console.headless.md)
+ [Erstellen einer globalen Amazon-Aurora-Datenbank aus einem Aurora- oder Amazon-RDS-Snapshot](aurora-global-database.use-snapshot.md)
# Anforderungen an die Konfiguration einer globalen Amazon-Aurora-Datenbank
Bevor Sie anfangen, mit Ihrer globalen Datenbank zu arbeiten, sollten Sie die Cluster- und Instance-Namen, AWS-Regionen sowie die Anzahl der Instances und Instance-Klassen planen, die Sie verwenden möchten. Stellen Sie sicher, dass Ihre Auswahl den folgenden Konfigurationsanforderungen entspricht:
Eine globale Aurora-Datenbank umfasst mindestens zwei AWS-Regionen. Die primäre AWS-Region unterstützt einen Aurora-DB-Cluster mit einer Writer-Aurora-DB-Instance. Eine sekundäre AWS-Region führt einen schreibgeschützten Aurora-DB-Cluster aus, der vollständig aus Aurora-Replikaten besteht. Es ist mindestens eine sekundäre AWS-Region erforderlich, wobei eine globale Aurora-Datenbank bis zu 10 sekundäre AWS-Regionen haben kann. In der Tabelle sind die maximal zulässigen Aurora-DB-Cluster, Aurora-DB-Instances und Aurora-Replicas aufgeführt, die in einer globalen Aurora-Datenbank zulässig sind.
| Beschreibung | Primär AWS-Region | Sekundär AWS-Regionen |
| --- | --- | --- |
| Aurora-DB-Cluster | 1 | 10 (maximal) |
| Writer-Inst | 1 | 0 |
| Schreibgeschützte Instances (Aurora-Replicas) pro Aurora-DB-Cluster | 15 (Max.) | 16 (Total) |
| Schreibgeschützte Instances (maximal zulässig, bei tatsächlicher Anzahl von sekundären Regionen) | 15 - *s* | *s* = Gesamtzahl der sekundären AWS-Regionen |
Die Aurora-DB-Cluster, aus denen eine globale Aurora-Datenbank besteht, haben die folgenden spezifischen Anforderungen:
+ **DB-Instance-Klassenanforderungen** – Eine globale Aurora-Datenbank erfordert DB-Instance-Klassen, die für speicherintensive Anwendungen optimiert sind. Weitere Informationen zu den arbeitsspeicheroptimierten DB-Instance-Klassen finden Sie unter [DB-Instance-Klassenarten](Concepts.DBInstanceClass.Types.md). Wir empfehlen, db.r5 oder eine höhere Instance-Klasse zu nutzen.
+ **AWS-Region-Anforderungen** – Eine globale Aurora-Datenbank benötigt einen primären Aurora-DB-Cluster in einer AWS-Region und mindestens einen sekundären Aurora-DB-Cluster in einer anderen Region. Sie können bis zu 10 sekundäre (schreibgeschützte) Aurora-DB-Cluster erstellen und jeder muss sich in einer anderen Region befinden. Mit anderen Worten, es können sich keine zwei Aurora-DB-Cluster in einer globalen Aurora-Datenbank in derselben AWS-Region befinden.
Informationen darüber, welche Kombinationen aus Aurora-DB-Engine, Engine-Version und AWS-Region Sie bei Aurora Global Database verwenden können, finden Sie unter [Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
+ **Benennungsanforderungen** – Die Namen, die Sie für jeden Ihrer Aurora-DB-Cluster auswählen, müssen in allen AWS-Regionen eindeutig sein. Sie können nicht denselben Namen für verschiedene Aurora-DB-Cluster verwenden, obwohl sie sich in verschiedenen Regionen befinden.
+ **Kapazitätsanforderungen für Aurora Serverless v2** – Für eine globale Datenbank mit Aurora Serverless v2 beträgt die [erforderliche Mindestkapazität](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.min_capacity_considerations) für den DB-Cluster in der primären AWS-Region 8 ACUs.
Bevor Sie die in diesem Abschnitt beschriebenen Verfahren befolgen können, benötigen Sie ein AWS-Konto. Schließen Sie die Einrichtungsaufgaben für die Arbeit mit Amazon Aurora ab. Weitere Informationen finden Sie unter [Einrichten Ihrer Umgebung für Amazon Aurora](CHAP_SettingUp_Aurora.md). Sie müssen auch andere vorab erforderliche Schritte zum Erstellen eines Aurora-DB-Clusters ausführen. Weitere Informationen hierzu finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md).
Wenn Sie bereit sind, Ihre globale Datenbank einzurichten, finden Sie unter [Erstellen einer globalen Datenbank von Amazon Aurora](aurora-global-database-creating.md) Informationen über das Verfahren zum Erstellen aller erforderlichen Ressourcen. Sie können auch das Verfahren unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md) befolgen, um eine globale Datenbank mit einem vorhandenen Aurora-Cluster als primärem Cluster zu erstellen.
# Erstellen einer globalen Datenbank von Amazon Aurora
Gehen Sie wie folgt vor, um eine globale Aurora-Datenbank und die AWS-Managementkonsole zugehörigen Ressourcen mithilfe der AWS CLI, der oder der RDS-API zu erstellen.
**Anmerkung**
Wenn Sie über einen vorhandenen Aurora-DB-Cluster verfügen, auf dem eine global kompatible Aurora-Datenbank-Engine ausgeführt wird, können Sie das Verfahren abkürzen. In diesem Fall können Sie dem vorhandenen DB-Cluster einen weiteren AWS-Region hinzufügen, um Ihre globale Aurora-Datenbank zu erstellen. Lesen Sie dazu den Abschnitt [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
## Konsole
Die Schritte zum Erstellen einer globalen Aurora-Datenbank beginnen mit der Anmeldung bei einer AWS-Region , die die globale Aurora-Datenbankfunktion unterstützt. Eine vollständige Liste finden Sie hier: [Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md).
Einer der folgenden Schritte ist die Auswahl einer Virtual Private Cloud (VPC), die auf Amazon VPC für Ihren Aurora-DB-Cluster basiert. Um Ihre eigene VPC zu verwenden, empfehlen wir Ihnen, diese im Voraus zu erstellen, damit sie von Ihnen ausgewählt werden kann. Erstellen Sie gleichzeitig alle zugehörigen Subnetze und nach Bedarf eine Subnetz- und Sicherheitsgruppe. Um zu erfahren wie dies geht, vgl. [Tutorial: Eine VPC zur Verwendung mit einem erstellen (IPv4 nur)](CHAP_Tutorials.WebServerDB.CreateVPC.md).
Allgemeine Informationen zum Erstellen eines Aurora-DB-Clusters finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md).
**So erstellen Sie eine globale Aurora-Datenbank**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie **Datenbank erstellen** aus. Gehen Sie auf der Seite **Datenbank erstellen** wie folgt vor:
+ Wählen Sie als Datenbankerstellungsmethode **Standarderstellung** aus. Wählen Sie nicht Einfache Erstellung.
+ Wählen Sie für `Engine type` im Abschnitt **Engine-Optionen** den entsprechenden Engine-Typ, **Aurora (MySQL-kompatibel)** oder **Aurora (PostgreSQL-kompatibel)**.
1. Fahren Sie fort mit dem Erstellen der globalen Datenbank, indem Sie den Schritten aus den folgenden Verfahren folgen:
### Erstellen einer globalen Datenbank mit Aurora MySQL
Die folgenden Schritte gelten für alle Versionen von Aurora MySQL.
**So erstellen Sie eine globale Aurora-Datenbank mit Aurora MySQL:**
Füllen Sie die Seite **Datenbank erstellen** aus.
1. Wählen Sie unter **Engine-Optionen** Folgendes aus:
1. Wählen Sie für **Engine-Version** die Version von Aurora MySQL, die Sie für Ihre globale Aurora-Datenbank verwenden möchten.
1. Wählen Sie für **Vorlagen****Produktion**. Oder Sie können wählen, Dev/Test ob es für Ihren Anwendungsfall geeignet ist. Nicht Dev/Test in Produktionsumgebungen verwenden.
1. Für **Settings (Einstellungen)** nehmen Sie folgendes vor:
1. Geben Sie einen aussagekräftigen Namen für die DB-Cluster-ID ein. Wenn Sie mit dem Erstellen der Aurora globalen Datenbank fertig sind, identifiziert dieser Name den primären DB-Cluster.
1. Geben Sie Ihr eigenes Passwort für das `admin`-Benutzerkonto für die DB-Instance ein oder lassen Sie Aurora eines für Sie erstellen. Wenn Sie ein Passwort automatisch generieren, erhalten Sie die Option zum Kopieren des Passworts.
![\[Screenshot der Optionen für die Einstellungen beim Erstellen einer globalen Datenbank.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-ams-3.png)
1. Wählen Sie für **DB instance class (DB-Instance-Klasse)** `db.r5.large` oder eine andere arbeitsspeicheroptimierte DB-Instance-Klasse aus. Wir empfehlen, db.r5 oder eine höhere Instance-Klasse zu nutzen.
1. Für **Verfügbarkeit und Haltbarkeit** empfehlen wir Ihnen, Aurora für die Erstellung einer Aurora-Replica in einer anderen Availability Zone (AZ) zu wählen. Wenn Sie jetzt keine Aurora-Replica erstellen, müssen Sie dies später tun.
![\[Screenshot von Verfügbarkeit und Haltbarkeit.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-ams-4b.png)
1. Wählen Sie bei **Anbindung** die auf Amazon VPC basierende Virtual Private Cloud (VPC) aus, die die virtuelle Netzwerkumgebung für diese DB-Instance definiert. Sie können die Standardwerte auswählen, um diese Aufgabe zu vereinfachen.
1. Schließen Sie die Einstellungen für die **Datenbankauthentifizierung** ab. Um den Prozess zu vereinfachen, können Sie jetzt **Passwort-Authentifizierung** wählen und AWS Identity and Access Management (IAM) später einrichten.
1. Für **Zusätzliche Konfiguration** führen Sie die folgenden Schritte aus:
1. Geben Sie einen Namen für **Anfänglicher Datenbankname** ein, um die primäre Aurora-DB-Instance für diesen Cluster zu erstellen. Dies ist der Writer-Knoten für den Aurora primären DB-Cluster.
Belassen Sie die für die DB-Clusterparametergruppe und die DB-Parametergruppe ausgewählten Standardwerte, es sei denn, Sie haben Ihre eigenen benutzerdefinierten Parametergruppen, die Sie verwenden möchten.
1. Deaktivieren Sie das Kontrollkästchen **Rückverfolgung aktivieren**, wenn es aktiviert ist. Globale Datenbanken von Aurora unterstützen keine Rückverfolgung. Sie können andernfalls die anderen Standardeinstellungen für die **Zusätzliche Konfiguration** akzeptieren.
1. Wählen Sie **Create database (Datenbank erstellen)** aus.
Es kann einige Minuten dauern, bis Aurora den Prozess zum Erstellen der Aurora-DB-Instance, ihrer Aurora Replica und des Aurora-DB-Clusters abgeschlossen hat. Sie können anhand des Status feststellen, wann der Aurora-DB-Cluster als primärer DB-Cluster in einer globalen Aurora-Datenbank verwendet werden kann. Wenn dies der Fall ist, lautet der Status und der des Writer- und Replikat-Knotens **Verfügbar**, wie nachstehend gezeigt.
![\[Screenshot von Datenbanken mit einem Aurora-DB-Cluster, der für globale Aurora-Datenbanken verwendet werden kann.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-ams-5.png)
Wenn Ihr primärer DB-Cluster verfügbar ist, erstellen Sie die globale Aurora-Datenbank, indem Sie einen sekundären Cluster hinzufügen. Befolgen Sie dafür die unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md) beschriebenen Schritte.
### Erstellen einer globalen Datenbank mit Aurora PostgreSQL
**So erstellen Sie eine globale Aurora-Datenbank mit Aurora PostgreSQL**
Füllen Sie die Seite **Datenbank erstellen** aus.
1. Wählen Sie unter **Engine-Optionen** Folgendes aus:
1. Wählen Sie für **Engine-Version** die Version von Aurora PostgreSQL, die Sie für Ihre Aurora globale Datenbank verwenden möchten.
1. Wählen Sie für **Vorlagen****Produktion**. Oder Sie können wählen, Dev/Test ob es angemessen ist. Nicht Dev/Test in Produktionsumgebungen verwenden.
1. Für **Settings (Einstellungen)** nehmen Sie folgendes vor:
1. Geben Sie einen aussagekräftigen Namen für die DB-Cluster-ID ein. Wenn Sie mit dem Erstellen der Aurora globalen Datenbank fertig sind, identifiziert dieser Name den primären DB-Cluster.
1. Geben Sie Ihr eigenes Passwort für das Standard-Admin-Konto für den DB-Cluster ein, oder lassen Sie es Aurora für Sie generieren. Wenn Sie „Passwort automatisch generieren“ wählen, erhalten Sie die Option zum Kopieren des Passworts.
![\[Screenshot der Optionen für die Einstellungen beim Erstellen einer globalen Datenbank.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-2.png)
1. Wählen Sie für **DB instance class (DB-Instance-Klasse)** `db.r5.large` oder eine andere arbeitsspeicheroptimierte DB-Instance-Klasse aus. Wir empfehlen, db.r5 oder eine höhere Instance-Klasse zu nutzen.
1. Für **Verfügbarkeit und Haltbarkeit** empfehlen wir Ihnen, Aurora für die Erstellung einer Aurora-Replica in einer anderen AZ für Sie zu wählen. Wenn Sie jetzt keine Aurora-Replica erstellen, müssen Sie dies später tun.
1. Wählen Sie bei **Anbindung** die auf Amazon VPC basierende Virtual Private Cloud (VPC) aus, die die virtuelle Netzwerkumgebung für diese DB-Instance definiert. Sie können die Standardwerte auswählen, um diese Aufgabe zu vereinfachen.
1. (Optional) Schließen Sie die Einstellungen für die **Datenbankauthentifizierung** ab. Die Passwortauthentifizierung ist immer aktiviert. Um den Prozess zu vereinfachen, können Sie diesen Abschnitt überspringen und später die IAM- oder Passwort- und Kerberos-Authentifizierung einrichten.
1. Für **Zusätzliche Konfigurationen** führen Sie die folgenden Schritte aus:
1. Geben Sie einen Namen für **Anfänglicher Datenbankname** ein, um die primäre Aurora-DB-Instance für diesen Cluster zu erstellen. Dies ist der Writer-Knoten für den Aurora primären DB-Cluster.
Belassen Sie die für die DB-Clusterparametergruppe und die DB-Parametergruppe ausgewählten Standardwerte, es sei denn, Sie haben Ihre eigenen benutzerdefinierten Parametergruppen, die Sie verwenden möchten.
1. Akzeptieren Sie alle anderen Standardeinstellungen für **zusätzliche Konfigurationen** wie Verschlüsselung, Protokollexporte usw.
1. Wählen Sie **Datenbank erstellen** aus.
Es kann einige Minuten dauern, bis Aurora den Prozess zum Erstellen der Aurora-DB-Instance, ihrer Aurora Replica und des Aurora-DB-Clusters abgeschlossen hat. Wenn der Cluster einsatzbereit ist, zeigen der Aurora-DB-Cluster und seine Writer- und Replica-Nodes den Status **Verfügbar** an. Dies wird der primäre DB-Cluster Ihrer Aurora globalen Datenbank, nachdem Sie einen sekundären Cluster hinzugefügt haben.
![\[Screenshot von Datenbanken mit einem Aurora-DB-Cluster, der für globale Aurora-Datenbanken verwendet werden kann.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-5-add-region.png)
Wenn Ihr primäre DB-Cluster verfügbar ist, erstellen Sie einen oder mehrere sekundäre Cluster, indem Sie die Schritte [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
## AWS CLI
Die AWS CLI Befehle in den folgenden Verfahren erfüllen die folgenden Aufgaben:
1. Erstellen einer globalen Aurora-Datenbank, Eingabe eines Namens und Spezifizierung des Typs der Aurora-Datenbank-Engine, den Sie verwenden möchten.
1. Erstellen Sie einen Aurora-DB-Cluster für die Aurora globale Datenbank.
1. Erstellen Sie eine Aurora-DB-Instance für den Cluster. Dies ist der primäre Aurora-DB-Cluster der globalen Datenbank.
1. Erstellen Sie eine zweite DB-Instance für den Aurora-DB-Cluster. Dies ist ein Reader zur Vervollständigung des Aurora-DB-Clusters.
1. Erstellen Sie einen zweiten Aurora-DB-Cluster in einer anderen Region und fügen Sie ihn dann Ihrer Aurora globalen Datenbank hinzu, indem Sie die unter beschriebenen Schritte ausführe [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
Folgen Sie der Vorgehensweise für Ihre Aurora-Datenbank-Engine.
### Erstellen einer globalen Datenbank mit Aurora MySQL
**So erstellen Sie eine globale Aurora-Datenbank mit Aurora MySQL:**
1. Verwenden Sie den `[create-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-global-cluster.html)` CLI-Befehl und übergeben Sie den Namen der AWS-Region Aurora-Datenbank-Engine und die Version.
Für Linux, macOS oder Unix:
```
aws rds create-global-cluster --region primary_region \
--global-cluster-identifier global_database_id \
--engine aurora-mysql \
--engine-version version # optional
```
Für Windows:
```
aws rds create-global-cluster ^
--global-cluster-identifier global_database_id ^
--engine aurora-mysql ^
--engine-version version # optional
```
Dadurch wird eine „leere“ Aurora globale Datenbank mit nur einem Namen (Identifier) und einer Aurora-Datenbank-Engine erstellt. Es kann einige Minuten dauern, bis die Aurora globale Datenbank verfügbar ist. Bevor Sie mit dem nächsten Schritt fortfahren, prüfen Sie mit dem `[describe-global-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-global-clusters.html)`-CLI-Befehl, ob sie verfügbar ist.
```
aws rds describe-global-clusters --region primary_region --global-cluster-identifier global_database_id
```
Wenn die Aurora globale Datenbank verfügbar ist, können Sie ihren primären Aurora-DB-Cluster erstellen.
1. Um einen primären Aurora-DB-Cluster zu erstellen, verwenden Sie den `[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)`-CLI-Befehl. Fügen Sie den Namen Ihrer Aurora globalen Datenbank mit dem Parameter `--global-cluster-identifier` ein.
Für Linux, macOS oder Unix:
```
aws rds create-db-cluster \
--region primary_region \
--db-cluster-identifier primary_db_cluster_id \
--master-username userid \
--master-user-password password \
--engine aurora-mysql \
--engine-version version \
--global-cluster-identifier global_database_id
```
Für Windows:
```
aws rds create-db-cluster ^
--region primary_region ^
--db-cluster-identifier primary_db_cluster_id ^
--master-username userid ^
--master-user-password password ^
--engine aurora-mysql ^
--engine-version version ^
--global-cluster-identifier global_database_id
```
Verwenden Sie den `[describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)` AWS CLI Befehl, um zu bestätigen, dass der Aurora-DB-Cluster bereit ist. Um einen bestimmten Aurora-DB-Cluster herauszugreifen, verwenden Sie den Parameter `--db-cluster-identifier`. Oder Sie können den Aurora-DB-Cluster-Namen im Befehl weg lassen, um Details zu all Ihren Aurora-DB-Clustern in der angegebenen Region zu erhalten.
```
aws rds describe-db-clusters --region primary_region --db-cluster-identifier primary_db_cluster_id
```
Wenn die Antwort `"Status": "available"` für den Cluster anzeigt, ist er einsatzbereit.
1. Erstellen Sie die DB-Instance für Ihren primären Aurora-DB-Cluster. Verwenden Sie dazu den `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`-CLI-Befehl. Geben Sie den Namen Ihres Aurora-DB-Clusters an und geben Sie die Konfigurationsdetails für die Instance an. Sie müssen die Parameter `--master-username` und `--master-user-password` im Befehl nicht übergeben, da diese vom Aurora-DB-Cluster abgerufen werden.
Für `--db-instance-class` können Sie nur arbeitsspeicheroptimierte Klassen verwenden, z. B. `db.r5.large`. Wir empfehlen, db.r5 oder eine höhere Instance-Klasse zu nutzen. Informationen zu diesen Klassen finden Sie unter [DB-Instance-Klassenarten](Concepts.DBInstanceClass.Types.md).
Für Linux, macOS oder Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier db_instance_id \
--engine aurora-mysql \
--engine-version version \
--region primary_region
```
Für Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier db_instance_id ^
--engine aurora-mysql ^
--engine-version version ^
--region primary_region
```
Die Operation `create-db-instance` kann einige Zeit in Anspruch nehmen. Überprüfen Sie den Status, um festzustellen, ob die Aurora-DB-Instance verfügbar ist, bevor Sie fortfahren.
```
aws rds describe-db-clusters --db-cluster-identifier primary_db_cluster_id
```
Wenn der Befehl den Status `available` zurückgibt, können Sie eine weitere Aurora-DB-Instance für Ihren primären DB-Cluster erstellen. Dies ist die Reader-Instance (Aurora-Replica) für den Aurora-DB-Cluster.
1. Um eine weitere Aurora-DB-Instance für den Cluster zu erstellen, verwenden Sie den `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`-CLI-Befehl.
Für Linux, macOS oder Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier replica_db_instance_id \
--engine aurora-mysql
```
Für Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier replica_db_instance_id ^
--engine aurora-mysql
```
Wenn die DB-Instance verfügbar ist, beginnt die Replikation vom Writer-Knoten zum Replica. Bevor Sie fortfahren, überprüfen Sie, ob die DB-Instance mit dem `[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)`-CLI-Befehl verfügbar ist.
Zu diesem Zeitpunkt verfügen Sie über eine Aurora globale Datenbank mit ihrem primären Aurora-DB-Cluster, der eine Writer-DB-Instance und eine Aurora-Replica enthält. Sie können jetzt einen schreibgeschützten Aurora-DB-Cluster in einer anderen Region hinzufügen, um Ihre Aurora globale Datenbank zu vervollständigen. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
### Erstellen einer globalen Datenbank mit Aurora PostgreSQL
Wenn Sie mithilfe der folgenden Befehle Aurora-Objekte für eine globale Aurora-Datenbank erstellen, kann es einige Minuten dauern, bis jedes verfügbar ist. Wir empfehlen, dass Sie nach Abschluss eines bestimmten Befehls den Status des jeweiligen Aurora-Objekts überprüfen, um sicherzustellen, dass der Status „Verfügbar“ lautet.
Verwenden Sie dazu den `[describe-global-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-global-clusters.html)`-CLI-Befehl.
```
aws rds describe-global-clusters --region primary_region
--global-cluster-identifier global_database_id
```
**So erstellen Sie eine globale Aurora-Datenbank mit Aurora PostgreSQL**
1. Verwenden Sie den `[create-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-global-cluster.html)`-CLI-Befehl.
Für Linux, macOS oder Unix:
```
aws rds create-global-cluster --region primary_region \
--global-cluster-identifier global_database_id \
--engine aurora-postgresql \
--engine-version version # optional
```
Für Windows:
```
aws rds create-global-cluster ^
--global-cluster-identifier global_database_id ^
--engine aurora-postgresql ^
--engine-version version # optional
```
Wenn die Aurora globale Datenbank verfügbar ist, können Sie ihren primären Aurora-DB-Cluster erstellen.
1. Um einen primären Aurora-DB-Cluster zu erstellen, verwenden Sie den `[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)`-CLI-Befehl. Fügen Sie den Namen Ihrer Aurora globalen Datenbank mit dem Parameter `--global-cluster-identifier` ein.
Für Linux, macOS oder Unix:
```
aws rds create-db-cluster \
--region primary_region \
--db-cluster-identifier primary_db_cluster_id \
--master-username userid \
--master-user-password password \
--engine aurora-postgresql \
--engine-version version \
--global-cluster-identifier global_database_id
```
Für Windows:
```
aws rds create-db-cluster ^
--region primary_region ^
--db-cluster-identifier primary_db_cluster_id ^
--master-username userid ^
--master-user-password password ^
--engine aurora-postgresql ^
--engine-version version ^
--global-cluster-identifier global_database_id
```
Prüfen Sie, ob der Aurora-DB-Cluster bereit ist. Wenn die Antwort des folgenden Befehls `"Status": "available"` für den Aurora-DB-Cluster angezeigt wird, können Sie fortfahren.
```
aws rds describe-db-clusters --region primary_region --db-cluster-identifier primary_db_cluster_id
```
1. Erstellen Sie die DB-Instance für Ihren primären Aurora-DB-Cluster. Verwenden Sie dazu den `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`-CLI-Befehl.
Übergeben Sie den Namen Ihres Aurora-DB-Clusters mit dem Parameter `--db-cluster-identifier`.
Sie müssen die Parameter `--master-username` und `--master-user-password` im Befehl nicht übergeben, da diese vom Aurora-DB-Cluster abgerufen werden.
Für `--db-instance-class` können Sie nur arbeitsspeicheroptimierte Klassen verwenden, z. B. `db.r5.large`. Wir empfehlen, db.r5 oder eine höhere Instance-Klasse zu nutzen. Informationen zu diesen Klassen finden Sie unter [DB-Instance-Klassenarten](Concepts.DBInstanceClass.Types.md).
Für Linux, macOS oder Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier db_instance_id \
--engine aurora-postgresql \
--engine-version version \
--region primary_region
```
Für Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier db_instance_id ^
--engine aurora-postgresql ^
--engine-version version ^
--region primary_region
```
1. Prüfen Sie den Status der Aurora-DB-Instance, bevor Sie fortfahren.
```
aws rds describe-db-clusters --db-cluster-identifier primary_db_cluster_id
```
Wenn die Antwort zeigt, dass der Status der Aurora-DB-Instance `available` lautet, können Sie eine weitere Aurora-DB-Instance für Ihren primären DB-Cluster erstellen.
1. Um eine Aurora-Replica für Aurora-DB-Cluster zu erstellen, verwenden Sie den `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)`CLI-Befehl.
Für Linux, macOS oder Unix:
```
aws rds create-db-instance \
--db-cluster-identifier primary_db_cluster_id \
--db-instance-class instance_class \
--db-instance-identifier replica_db_instance_id \
--engine aurora-postgresql
```
Für Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier primary_db_cluster_id ^
--db-instance-class instance_class ^
--db-instance-identifier replica_db_instance_id ^
--engine aurora-postgresql
```
Wenn die DB-Instance verfügbar ist, beginnt die Replikation vom Writer-Knoten zum Replica. Bevor Sie fortfahren, überprüfen Sie, ob die DB-Instance mit dem `[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)`-CLI-Befehl verfügbar ist.
Ihre Aurora globale Datenbank existiert nun, verfügt aber nur in ihrer primären Region einen Aurora-DB-Cluster, der aus einer Writer-DB-Instance und einer Aurora-Replica besteht. Sie können jetzt einen schreibgeschützten Aurora-DB-Cluster in einer anderen Region hinzufügen, um Ihre Aurora globale Datenbank zu vervollständigen. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
## RDS-API
Führen Sie den [CreateGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateGlobalCluster.html)Vorgang aus, um eine globale Aurora-Datenbank mit der RDS-API zu erstellen.
# Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank
Sie können das folgende Verfahren verwenden, um einer vorhandenen globalen Datenbank einen zusätzlichen sekundären Cluster hinzuzufügen. Sie können auch eine globale Datenbank aus einem eigenständigen Aurora-DB-Cluster erstellen, indem Sie mit diesem Verfahren die erste sekundäre AWS-Region hinzuzufügen.
Eine globale Aurora-Datenbank benötigt mindestens einen sekundären Aurora-DB-Cluster in einer anderen AWS-Region als der primäre Aurora-DB-Cluster. Sie können bis zu 10 sekundäre DB-Cluster an Ihre globale Aurora-Datenbank anhängen. Wiederholen Sie das folgende Verfahren für jeden neuen sekundären DB-Cluster. Reduzieren Sie für jeden sekundären DB-Cluster, den Sie Ihrer globalen Aurora-Datenbank hinzufügen, die Anzahl der Aurora-Replicas, die für den primären DB-Cluster zulässig sind, um eins.
Wenn Ihre globale Aurora-Datenbank beispielsweise 10 sekundäre Regionen hat, kann Ihr primärer DB-Cluster nur 5 (statt 15) Aurora-Replikate haben. Weitere Informationen finden Sie unter [Anforderungen an die Konfiguration einer globalen Amazon-Aurora-Datenbank](aurora-global-database.configuration.requirements.md).
Die Anzahl der Aurora-Replikate (Reader-Instances) im primären DB-Cluster bestimmt die Anzahl der sekundären DB-Cluster, die Sie hinzufügen können. Die Gesamtzahl der Reader-Instances im primären DB-Cluster plus die Anzahl der sekundären Cluster darf nicht mehr als 15 betragen. Wenn Sie zum Beispiel 14 Reader-Instances im primären DB-Cluster und einen sekundären Cluster haben, können Sie der globalen Datenbank keinen weiteren sekundären Cluster hinzufügen.
**Anmerkung**
Wenn Sie für Aurora MySQL Version 3 einen sekundären Cluster erstellen, stellen Sie sicher, dass der Wert von `lower_case_table_names` mit dem Wert im primären Cluster übereinstimmt. Diese Einstellung ist ein Datenbankparameter, der beeinflusst, wie der Server die Groß- und Kleinschreibung von Bezeichnern behandelt. Weitere Informationen zu Datenbankparametern finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md).
Es wird empfohlen, beim Erstellen eines sekundären Clusters dieselbe DB-Engine-Version für den primären und den sekundären Cluster zu verwenden. Aktualisieren Sie bei Bedarf den primären Cluster auf die Version des sekundären Clusters. Weitere Informationen finden Sie unter [Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failover](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility).
## Konsole
**Um ein AWS-Region zu einer globalen Aurora-Datenbank hinzuzufügen**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich der AWS-Managementkonsole die Option **Datenbanken** aus.
1. Wählen Sie die Aurora globale Datenbank aus, die einen sekundären Aurora-DB-Cluster benötigt. Stellen Sie sicher, dass der primäre Aurora-DB-Cluster is `Available`.
1. Wählen Sie für **Aktionen** die Option **AWS-Region hinzufügen** aus.
![\[Der Screenshot zeigt den bereitgestellten DB-Cluster mit im Aktionsmenü ausgewählter Option „AWS-Region hinzufügen“.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-5-add-region.png)
1. Wählen Sie auf der Seite **Eine Region hinzufügen** die sekundäre AWS-Region aus.
Sie können keine AWS-Region auswählen, die bereits über einen sekundären Aurora-DB-Cluster für dieselbe globale Aurora-Datenbank verfügt. Außerdem kann dies nicht dieselbe Region sein wie die des primären Aurora-DB-Clusters.
**Anmerkung**
Die globalen Datenbanken von Babelfish für Aurora PostgreSQL funktionieren nur in sekundären Regionen, wenn die Parameter, die die Babelfish-Einstellungen steuern, in diesen Regionen aktiviert sind. Weitere Informationen finden Sie unter [Einstellungen der DB-Cluster-Parametergruppe für Babelfish](babelfish-configuration.md)
![\[Die „Region hinzufügen“-Seite für eine globale Aurora-Datenbank\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-create-apg-6-add-region.png)
1. Füllen Sie die restlichen Felder für den sekundären Aurora-Cluster in der neuen AWS-Region aus. Dies sind die gleichen Konfigurationsoptionen wie für jede Aurora-DB-Cluster-Instance, mit Ausnahme der folgenden Option nur für Aurora MySQL–basierte globale Aurora-Datenbanken:
+ Read Replica-Schreibweiterleitung aktivieren – Mit dieser optionalen Einstellung leiten die sekundären DB-Cluster Ihrer globalen Aurora-Datenbank Schreibvorgänge an den primären Cluster weiter. Weitere Informationen finden Sie unter [Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank](aurora-global-database-write-forwarding.md).
![\[Screenshot mit Anzeige des sekundären Clusters, jetzt Teil der globalen Aurora-Datenbank.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-database-enable-write-forwarding.png)
1. Wählen Sie **AWS-Region hinzufügen** aus.
Nachdem Sie die Region zu Ihrer globalen Aurora-Datenbank hinzugefügt haben, können Sie sie in der Liste der **Datenbanken** in AWS-Managementkonsole sehen, wie im Screenshot gezeigt.
![\[Screenshot mit Anzeige des sekundären Clusters, jetzt Teil der globalen Aurora-Datenbank.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-apg-complete.png)
## AWS CLI
**Fügen Sie eine sekundäre AWS-Region zu einer globalen Aurora-Datenbank wie folgt hinzu:**
Um Ihrer globalen Datenbank mithilfe der CLI einen sekundären Cluster hinzuzufügen, müssen Sie bereits über das globale Cluster-Container-Objekt verfügen. Wenn Sie den `create-global-cluster`-Befehl noch nicht ausgeführt haben, finden Sie weitere Informationen zum CLI-Verfahren unter [Erstellen einer globalen Datenbank von Amazon Aurora](aurora-global-database-creating.md).
1. Verwenden Sie den `[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)`-CLI-Befehl mit dem Namen (`--global-cluster-identifier`) Ihrer globalen Aurora-Datenbank. Für andere Parameter, führen Sie die folgenden Schritte aus:
1. Wählen Sie für `--region` eine andere AWS-Region als die Ihrer primären Aurora-Region aus.
1. Wählen Sie bestimmte Werte für die Parameter `--engine-version` und `--engine` aus. Diese Werte entsprechen denen des primären Aurora-DB-Clusters in Ihrer globalen Aurora-Datenbank.
1. Geben Sie für einen verschlüsselten Cluster Ihre primäre AWS-Region als `--source-region` für die Verschlüsselung an.
Im folgenden Beispiel wird ein neuer Aurora-DB-Cluster erstellt und als schreibgeschützter sekundärer Aurora-DB-Cluster an eine globale Aurora-Datenbank angehängt. Im letzten Schritt wird dem neuen Aurora-DB-Cluster eine Aurora-DB-Instance hinzugefügt.
Für Linux, macOS oder Unix:
```
aws rds --region secondary_region \
create-db-cluster \
--db-cluster-identifier secondary_cluster_id \
--global-cluster-identifier global_database_id \
--engine aurora-mysql | aurora-postgresql \
--engine-version version
aws rds --region secondary_region \
create-db-instance \
--db-instance-class instance_class \
--db-cluster-identifier secondary_cluster_id \
--db-instance-identifier db_instance_id \
--engine aurora-mysql | aurora-postgresql
```
Für Windows:
```
aws rds --region secondary_region ^
create-db-cluster ^
--db-cluster-identifier secondary_cluster_id ^
--global-cluster-identifier global_database_id_id ^
--engine aurora-mysql | aurora-postgresql ^
--engine-version version
aws rds --region secondary_region ^
create-db-instance ^
--db-instance-class instance_class ^
--db-cluster-identifier secondary_cluster_id ^
--db-instance-identifier db_instance_id ^
--engine aurora-mysql | aurora-postgresql
```
## RDS-API
Um einer globalen Aurora-Datenbank mit der RDS-API eine neue AWS-Region hinzuzufügen, führen Sie die Operation [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) aus. Geben Sie die Kennung der vorhandenen globalen Datenbank mithilfe des Parameters `GlobalClusterIdentifier` an.
# Erstellen eines Aurora-Headless-DB-Clusters in einer sekundären Region
Obwohl eine globale Aurora-Datenbank mindestens einen sekundären Aurora-DB-Cluster in einer AWS-Region außerhalb der primären Region benötigt, können Sie eine *Headless*-Konfiguration für den sekundären Cluster verwenden. Ein sekundärer Aurora-Headless-DB-Cluster hat keine DB-Instance. Diese Art der Konfiguration kann die Ausgaben für eine globale Aurora-Datenbank senken. In einem Aurora-DB-Cluster werden die Rechen- und Speicherressourcen entkoppelt. Ohne die DB-Instance wird Ihnen die Rechenleistung nicht in Rechnung gestellt, sondern nur der Speicherplatz. Richtig eingerichtet, wird das sekundäre Headless-Speichervolume mit dem primären Aurora-DB-Cluster synchonisiert.
Sie fügen den sekundären Cluster wie gewohnt beim Erstellen einer globalen Aurora-Datenbank hinzu. Wenn Sie alle Cluster in der globalen Datenbank erstellen, gehen Sie wie unter [Erstellen einer globalen Datenbank von Amazon Aurora](aurora-global-database-creating.md) beschrieben vor. Wenn Sie bereits über einen DB-Cluster verfügen, den Sie als primären Cluster verwenden können, gehen Sie wie unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md) beschrieben vor.
Nachdem der primäre Aurora-DB-Cluster mit der Replikation zum sekundären Cluster begonnen hat, löschen Sie die schreibgeschützte Aurora-DB-Instance aus dem sekundären Aurora-DB-Cluster. Dieser sekundäre Cluster gilt jetzt als „Headless“, da er keine DB-Instance mehr hat. Selbst ohne DB-Instance im sekundären Aurora-DB-Cluster synchronisiert Aurora das Speicher-Volume mit dem primären Aurora-DB-Cluster.
**Warnung**
Um mit Aurora PostgreSQL einen Headless-Cluster in einer sekundären AWS-Region zu erstellen, verwenden Sie die AWS CLI- oder RDS-API, um die sekundäre AWS-Region hinzuzufügen. Überspringen Sie den Schritt, um die Reader-DB-Instance für den sekundären Cluster zu erstellen. Derzeit wird das Erstellen eines Headless-Clusters in der RDS-Konsole nicht unterstützt. Informationen zur Verwendung der CLI- und API-Prozeduren finden Sie unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md).
Wenn Ihre globale Datenbank eine niedrigere Engine-Version als 13.4, 12.8 oder 11.13 verwendet, kann das Erstellen einer Reader-DB-Instance in einer sekundären Region und das anschließende Löschen dieser Instance zu einem Aurora-PostgreSQL-Bereinigungsproblem auf der Writer-DB-Instance der primären Region führen. Wenn dieses Problem auftritt, starten Sie die Writer-DB-Instance der primären Region neu, nachdem Sie die Reader-DB-Instance der sekundären Region gelöscht haben.
**So fügen Sie Ihrer globalen Aurora-Datenbank einen sekundären Aurora-Headless-DB-Cluster hinzu**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich der AWS-Managementkonsole die Option **Datenbanken** aus.
1. Wählen Sie die Aurora globale Datenbank aus, die einen sekundären Aurora-DB-Cluster benötigt. Stellen Sie sicher, dass der primäre Aurora-DB-Cluster is `Available`.
1. Wählen Sie für **Aktionen** die Option **AWS-Region hinzufügen** aus.
1. Wählen Sie auf der Seite **Eine Region hinzufügen** die sekundäre AWS-Region aus.
Sie können keine AWS-Region auswählen, die bereits über einen sekundären Aurora-DB-Cluster für dieselbe globale Aurora-Datenbank verfügt. Außerdem kann dies nicht dieselbe Region sein wie die des primären Aurora-DB-Clusters.
1. Füllen Sie die restlichen Felder für den sekundären Aurora-Cluster in der neuen AWS-Region aus. Dies sind die gleichen Konfigurationsoptionen wie bei jeder Aurora-DB-Cluster-Instance.
Bei einer Aurora MySQL–basierten globalen Aurora-Datenbank ignorieren Sie die Option **Read Replica-Schreibweiterleitung aktivieren**. Diese Option hat keine Funktion, nachdem Sie die Reader-Instance gelöscht haben.
1. Wählen Sie **AWS-Region hinzufügen** aus. Nachdem Sie die Region zu Ihrer globalen Aurora-Datenbank hinzugefügt haben, können Sie sie in der Liste der **Datenbanken** in AWS-Managementkonsole sehen, wie im Screenshot gezeigt.
![\[Screenshot, der zeigt, dass der sekundäre Cluster mit seiner Reader-Instance jetzt Teil der globalen Aurora-Datenbank ist.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-headless-stage-1.png)
1. Überprüfen Sie den Status des sekundären Aurora-DB-Clusters und seiner Reader-Instance, bevor Sie fortfahren, indem Sie die AWS-Managementkonsole oder AWS CLI verwenden. Zum Beispiel:
```
$ aws rds describe-db-clusters --db-cluster-identifier secondary-cluster-id --query '*[].[Status]' --output text
```
Es kann mehrere Minuten dauern, bis der Status eines neu hinzugefügten sekundären Aurora-DB-Clusters von `creating` auf `available` wechselt. Wenn der Aurora-DB-Cluster verfügbar ist, können Sie die Reader-Instance löschen.
1. Wählen Sie die Reader-Instance im sekundären Aurora-DB-Cluster aus und klicken Sie dann auf **Löschen**.
![\[Der Screenshot zeigt die ausgewählte und zum Löschen bereitstehende Reader-Instance.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-headless-stage-2.png)
Nach dem Löschen der Reader-Instance bleibt der sekundäre Cluster Teil der globalen Aurora-Datenbank. Ihm ist keine Instance zugeordnet, wie im Folgenden gezeigt.
![\[Screenshot mit dem sekundären Headless-DB-Cluster.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-headless-secondary.png)
Sie können diesen sekundären Aurora-Headless-DB-Cluster verwenden, um Ihre [globale Amazon-Aurora-Datenbank nach einem ungeplanten Ausfall der primären AWS-Region manuell wiederherzustellen](aurora-global-database-disaster-recovery.md#aurora-global-database-failover), wenn ein solcher Ausfall auftritt.
# Erstellen einer globalen Amazon-Aurora-Datenbank aus einem Aurora- oder Amazon-RDS-Snapshot
Sie können einen Snapshot eines Aurora-DB-Clusters oder von einer Amazon-RDS-DB-Instance wiederherstellen, um ihn als Ausgangspunkt für Ihre globale Aurora-Datenbank zu verwenden. Sie stellen den Snapshot wieder her und erstellen gleichzeitig einen neuen von Aurora bereitgestellten DB-Cluster. Sie fügen dann dem wiederhergestellten DB-Cluster eine weitere AWS-Region hinzu und verwandeln sie so in eine globale Aurora-Datenbank. Jeder Aurora-DB-Cluster, den Sie auf diese Weise mit einem Snapshot erstellen, wird zum primären Cluster Ihrer globalen Aurora-Datenbank.
Der Snapshot, den Sie verwenden, kann von einem `provisioned`- oder einem `serverless` Aurora-DB-Cluster stammen.
Wählen Sie während des Wiederherstellungsvorgangs den gleichen DB-Engine-Typ wie den des Snapshots aus. Angenommen, Sie möchten einen Snapshot wiederherstellen, der aus einem Aurora Serverless-DB-Cluster mit Aurora PostgreSQL erstellt wurde. In diesem Fall erstellen Sie einen Aurora PostgreSQL-DB-Cluster mit derselben Aurora-DB-Engine und derselben Version.
Der wiederhergestellte DB-Cluster übernimmt die Rolle des primären Clusters für die globale Aurora-Datenbank, wenn Sie ihm eine AWS-Region hinzufügen. Alle in diesem primären Cluster enthaltenen Daten werden auf alle sekundären Cluster repliziert, die Sie Ihrer globalen Aurora-Datenbank hinzufügen.
![\[Screenshot mit der Seite zur Wiederherstellung eines Snapshots für eine globale Aurora-Datenbank\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-restore-snapshot-01.png)
# Verwalten einer Amazon Aurora Global Database
Die meisten Verwaltungsvorgänge werden auf den einzelnen Clustern ausgeführt, aus denen eine globale Aurora-Datenbank besteht. Wenn Sie **Group related resources (Gruppenbezogene Ressourcen)** auf der Seite **Databases (Datenbanken)** in der Konsole auswählen, werden der primäre Cluster und der sekundäre Cluster unter der zugehörigen globalen Datenbank gruppiert. Um die AWS-Regionen zu finden, in denen die DB-Cluster einer globalen Datenbank ausgeführt werden sowie die zugehörige Aurora-DB-Engine, -Version und ihre Kennung, verwenden Sie die Registerkarte **Konfiguration**.
Die regionsübergreifenden Datenbank-Failover-Prozesse stehen nur globalen Aurora-Datenbankobjekten zur Verfügung, nicht einem einzelnen Aurora-DB-Cluster. Weitere Informationen hierzu finden Sie unter [Verwenden von Umstellung oder Failover in Amazon Aurora Global Database](aurora-global-database-disaster-recovery.md).
Informationen zum Wiederherstellen einer globalen Aurora-Datenbank nach einem ungeplanten Ausfall in ihrer primären Region finden Sie unter [Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall](aurora-global-database-disaster-recovery.md#aurora-global-database-failover).
**Topics**
+ [Verändern einer Amazon Aurora Global Database](aurora-global-database-modifying.md)
+ [Ändern von Parametern für eine Aurora globale Datenbank](aurora-global-database-modifying.parameters.md)
+ [Entfernen eines Clusters aus einer Amazon Aurora Global Database](aurora-global-database-detaching.md)
+ [Löschen einer Amazon Aurora Global Database](aurora-global-database-deleting.md)
+ [Taggen von Ressourcen von Amazon Aurora Global Database](aurora-global-database-tagging.md)
# Verändern einer Amazon Aurora Global Database
Auf der **Datenbankseite** AWS-Managementkonsole werden alle Ihre globalen Aurora-Datenbanken aufgeführt, wobei der primäre Cluster und die sekundären Cluster für jede einzelne angezeigt werden. Die globale Aurora-Datenbank hat ihre eigenen Konfigurationseinstellungen. Insbesondere wurde es mit seinen primären und sekundären Clustern AWS-Regionen verknüpft, wie im folgenden Screenshot gezeigt.
![\[Screenshot mit einer ausgewählten globalen Aurora-Datenbank und ihrer Konfigurationseinstellungen in der AWS-Managementkonsole.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-global-database-configuration.png)
Wenn Sie Änderungen an der Aurora globalen Datenbank vornehmen, haben Sie die Möglichkeit, Änderungen abzubrechen, wie im folgenden Screenshot gezeigt.
![\[Screenshot mit der Seite zum Ändern der Einstellungen einer globalen Aurora-Datenbank\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-modify-global-01.png)
Wenn Sie **Weiter** wählen, bestätigen Sie die Änderungen.
# Ändern von Parametern für eine Aurora globale Datenbank
Sie können die Parametergruppen jedes Aurora-DB-Cluster für jeden Aurora-Cluster in der globalen Aurora-Datenbank einzeln konfigurieren. Die meisten Parameter funktionieren wie bei anderen Aurora-Clusterarten. Wir empfehlen, dass Sie die Einstellungen zwischen allen Clustern in einer globalen Datenbank konsistent halten. Dies hilft, unerwartete Verhaltensänderungen zu vermeiden, wenn Sie einen sekundären Cluster zum primären Cluster hochstufen.
Sie sollten z. B. die gleichen Einstellungen für Zeitzonen und Zeichensätze verwenden, um inkonsistentes Verhalten zu vermeiden, wenn ein anderer Cluster die Rolle des primären Clusters übernimmt.
Die Konfigurationseinstellungen `aurora_enable_repl_bin_log_filtering` und `aurora_enable_replica_log_compression` haben keine Auswirkungen.
# Entfernen eines Clusters aus einer Amazon Aurora Global Database
Sie können Aurora-DB-Cluster aus verschiedenen Gründen aus Ihrer Aurora globalen Datenbank entfernen. Beispielsweise möchten Sie möglicherweise einen Aurora-DB-Cluster aus einer Aurora globalen Datenbank entfernen, wenn der primäre Cluster herabgesetzt oder isoliert wird. Er wird dann zu einem eigenständigen bereitgestellten Aurora-DB-Cluster, der zum Erstellen einer neuen globalen Aurora-Datenbank verwendet werden könnte. Weitere Informationen hierzu finden Sie unter [Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall](aurora-global-database-disaster-recovery.md#aurora-global-database-failover).
Sie können bei Bedarf auch Aurora-DB-Cluster entfernen, wenn Sie eine globale Aurora-Datenbank löschen möchten, die Sie nicht mehr benötigen. Sie können die globale Aurora-Datenbank erst löschen, nachdem Sie alle zugehörigen Aurora-DB-Cluster entfernt haben, wobei der primäre Cluster zuletzt entfernt wird. Weitere Informationen finden Sie unter [Löschen einer Amazon Aurora Global Database](aurora-global-database-deleting.md).
Wenn ein Aurora-DB-Cluster von der globalen Aurora-Datenbank getrennt wird, wird er nicht mehr mit dem primären Cluster synchronisiert. Er wird zu einem eigenständigen bereitgestellten Aurora-DB-Cluster mit vollen Lese-/Schreibfähigkeiten.
Sie können Aurora-DB-Cluster aus Ihrer globalen Aurora-Datenbank mithilfe von AWS-Managementkonsole, AWS CLI oder der RDS-API entfernen.
## Konsole
**So entfernen Sie einen Aurora-Cluster aus einer globalen Aurora-Datenbank:**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie den Cluster auf der Seite **Databases (Datenbanken)** aus.
1. Wählen Sie unter **Actions (Aktionen)** die Option **Remove from Global (Aus 'Global' entfernen)** aus.
![\[Screenshot mit ausgewähltem Aurora-DB-Cluster (sekundär) und der Aktion „Entfernen aus global“.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-detach-secondary-01.png)
Sie sehen eine Aufforderung, um zu bestätigen, dass Sie den sekundären Cluster von der Aurora globalen Datenbank trennen möchten.
![\[Screenshot mit einer Bestätigungsaufforderung zum Entfernen eines sekundären Clusters aus einer globalen Aurora-Datenbank\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-detach-secondary-02.png)
1. Wählen Sie **Entfernen und hochstufen** , um den Cluster aus der globalen Datenbank zu entfernen.
Der Aurora-DB-Cluster dient nicht mehr als sekundärer Cluster in der Aurora globalen Datenbank und ist nicht mehr mit dem primären DB-Cluster synchronisiert. Er ist ein eigenständiger Aurora-DB-Cluster mit voller Lese-/Schreibfähigkeit.
![\[Screenshot mit einer Bestätigungsaufforderung zum Entfernen eines sekundären Clusters aus einer globalen Aurora-Datenbank\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-detach-secondary-03.png)
Nachdem Sie alle sekundären Cluster entfernt oder gelöscht haben, können Sie den primären Cluster auf die gleiche Weise entfernen. Sie können den primären Aurora-DB-Cluster erst von einer Aurora globalen Datenbank trennen (entfernen), nachdem Sie alle sekundären Cluster entfernt haben.
Die globale Aurora-Datenbank kann in der **Datenbankliste** mit null Regionen und AZs verbleiben. Sie können sie löschen, wenn Sie diese Aurora globale Datenbank nicht mehr verwenden möchten. Weitere Informationen finden Sie unter [Löschen einer Amazon Aurora Global Database](aurora-global-database-deleting.md).
## AWS CLI
Führen Sie den CLI-Befehl [remove-from-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/remove-from-global-cluster.html) mit den Parametern im Folgenden aus, um einen Aurora-Cluster von einer globalen Aurora-Datenbank zu entfernen:
+ `--global-cluster-identifier` – Der Name (identifier) Ihrer Aurora globalen Datenbank.
+ `--db-cluster-identifier` – Der Name jedes Aurora-DB-Clusters, der aus der Aurora globalen Datenbank entfernt werden soll. Entfernen Sie alle sekundären Aurora-DB-Cluster, bevor Sie den primären Cluster entfernen.
Bei den folgenden Beispielen wird zuerst ein sekundärer Cluster und dann der primäre Cluster aus einer globalen Aurora-Datenbank entfernt.
Für Linux, macOS oder Unix:
```
aws rds --region secondary_region \
remove-from-global-cluster \
--db-cluster-identifier secondary_cluster_ARN \
--global-cluster-identifier global_database_id
aws rds --region primary_region \
remove-from-global-cluster \
--db-cluster-identifier primary_cluster_ARN \
--global-cluster-identifier global_database_id
```
Wiederholen Sie den `remove-from-global-cluster --db-cluster-identifier secondary_cluster_ARN `-Befehl für jede sekundäre AWS-Region in Ihrer globalen Aurora-Datenbank.
Für Windows:
```
aws rds --region secondary_region ^
remove-from-global-cluster ^
--db-cluster-identifier secondary_cluster_ARN ^
--global-cluster-identifier global_database_id
aws rds --region primary_region ^
remove-from-global-cluster ^
--db-cluster-identifier primary_cluster_ARN ^
--global-cluster-identifier global_database_id
```
Wiederholen Sie den `remove-from-global-cluster --db-cluster-identifier secondary_cluster_ARN`-Befehl für jede sekundäre AWS-Region in Ihrer globalen Aurora-Datenbank.
## RDS-API
Führen Sie die Aktion [RemoveFromGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RemoveFromGlobalCluster.html) aus, um einen Aurora-Cluster mit der RDS-API aus einer globalen Aurora-Datenbank zu entfernen.
# Löschen einer Amazon Aurora Global Database
Da eine Aurora globale Datenbank üblicherweise geschäftskritische Daten enthält, ist es nicht möglich, die globale Datenbank und ihre zugeordneten Cluster in einem einzigen Schritt zu löschen. Um eine globale Aurora-Datenbank zu löschen, führen Sie die folgenden Schritte aus:
+ Entfernen Sie alle sekundären DB-Cluster aus der Aurora globalen Datenbank. Jeder Cluster wird zu einem eigenständigen Aurora-DB-Cluster. Um zu erfahren wie, siehe [Entfernen eines Clusters aus einer Amazon Aurora Global Database](aurora-global-database-detaching.md).
+ Löschen Sie von jedem eigenständigen Aurora-DB-Cluster alle Aurora-Replicas.
+ Entfernen Sie den primären DB-Cluster aus der globalen Aurora-Datenbank. Dieser Cluster wird zu einem eigenständigen Aurora-DB-Cluster.
+ Löschen Sie vom primären Aurora-DB-Cluster zuerst alle Aurora-Replicas und löschen Sie dann die Writer-DB-Instance.
Durch das Löschen der Writer-Instance aus dem neu eigenständigen Aurora-DB-Cluster werden normalerweise auch der Aurora-DB-Cluster und die Aurora globale Datenbank entfernt.
Weitere allgemeine Informationen finden Sie unter [Löschen einer DB-Instance aus einem Aurora-DB-Cluster](USER_DeleteCluster.md#USER_DeleteInstance).
Um eine globale Aurora-Datenbank zu löschen, können Sie AWS-Managementkonsole, AWS CLI oder die RDS-API verwenden.
## Konsole
**So löschen Sie eine globale Aurora-Datenbank**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie **Datenbanken** und suchen Sie die Aurora globale Datenbank, die Sie löschen möchten, in der Liste.
1. Bestätigen Sie, dass alle Cluster aus der globalen Aurora-Datenbank entfernt sind. Die globale Aurora-Datenbank sollte 0 Regionen und AZs sowie eine Größe von 0 Clustern enthalten.
Wenn die Aurora globale Datenbank Aurora-DB-Cluster enthält, können Sie sie nicht löschen. Trennen Sie bei Bedarf die primären und sekundären Aurora-DB-Cluster von der Aurora globalen Datenbank. Weitere Informationen finden Sie unter [Entfernen eines Clusters aus einer Amazon Aurora Global Database](aurora-global-database-detaching.md).
1. Wählen Sie Ihre globale Aurora-Datenbank in der Liste aus, und wählen Sie dann **Löschen** im Menü **Aktionen** aus.
![\[Eine globale Aurora-Datenbank, die auf Aurora MySQL 5.6.10a basiert, verbleibt in AWS-Managementkonsole bis Sie sie löschen, auch wenn sie keine zugehörigen Aurora-DB-Cluster enthält.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-ams5610a-delete-empty-cluster.png)
## AWS CLI
Um eine globale Aurora-Datenbank zu löschen, führen Sie den CLI-Befehl [delete-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-global-cluster.html) mit dem Namen der AWS-Region und der globalen Aurora-Datenbank-ID aus, wie im folgenden Beispiel gezeigt.
Für Linux, macOS oder Unix:
```
aws rds --region primary_region delete-global-cluster \
--global-cluster-identifier global_database_id
```
Für Windows:
```
aws rds --region primary_region delete-global-cluster ^
--global-cluster-identifier global_database_id
```
## RDS-API
Führen Sie die API-Operation [DeleteGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html) aus, um einen Cluster, der Teil einer globalen Aurora-Datenbank ist, zu löschen.
# Taggen von Ressourcen von Amazon Aurora Global Database
Mit der Funktion von Aurora Global Database können Sie RDS-Tags auf Ressourcen auf verschiedenen Ebenen innerhalb einer globalen Datenbank anwenden. Wenn Sie nicht wissen, wie Tags bei AWS- oder Aurora-Ressourcen verwendet werden, informieren Sie sich entsprechend unter [Taggen von Amazon Aurora- und Amazon RDS-Ressourcen](USER_Tagging.md), ehe Sie Tags innerhalb Ihrer globalen Datenbank anwenden.
**Anmerkung**
Da AWS Tag-Daten im Rahmen des Mechanismus der Kostenberichterstattung verarbeitet, sollten Sie keine sensiblen Daten oder persönlich identifizierbare Informationen (PII) in die Tag-Namen oder -Werte aufnehmen.
Sie können Tags auf die folgenden Ressourcenarten innerhalb einer globalen Datenbank anwenden:
+ Das Container-Objekt für Ihre gesamte globale Datenbank. Diese Ressource gilt als globaler Cluster.
Nachdem Sie den globalen Cluster erstellt haben, indem Sie in der Konsole den Vorgang **AWS-Region hinzufügen** ausgeführt haben, können Sie mithilfe der Detailseite für den globalen Cluster Tags hinzufügen. Auf der Registerkarte **Tags** der Detailseite für den globalen Cluster können Sie Tags und ihre zugehörigen Werte hinzufügen, entfernen oder ändern, indem Sie **Tags verwalten** auswählen.
Mit der AWS CLI und der RDS-API können Sie dem globalen Cluster gleichzeitig mit dessen Erstellung Tags hinzufügen. Sie können auch Tags für einen vorhandenen globalen Cluster hinzufügen, entfernen oder ändern.
+ Den primären Cluster. Sie verwenden hier dieselben Verfahren für die Arbeit mit Tags wie für eigenständige Aurora-Cluster. Sie können die Tags einrichten, bevor Sie den ursprünglichen Aurora-Cluster in eine globale Datenbank umwandeln. Sie können auch Tags und die zugehörigen Werte hinzufügen, entfernen oder ändern, indem Sie auf der Detailseite des DB-Clusters die Option **Tags verwalten** auf der Registerkarte **Tags** auswählen.
+ Alle sekundären Cluster. Sie verwenden hier dieselben Verfahren für die Arbeit mit Tags wie für eigenständige Aurora-Cluster. Sie können die Tags gleichzeitig mit der Erstellung eines sekundären Aurora-Clusters einrichten, indem Sie die Aktion **AWS-Region hinzufügen** in der Konsole verwenden. Sie können auch Tags und die zugehörigen Werte hinzufügen, entfernen oder ändern, indem Sie auf der Detailseite des DB-Clusters die Option **Tags verwalten** auf der Registerkarte **Tags** auswählen.
+ Einzelne DB-Instances innerhalb des primären oder sekundären Clusters. Sie verwenden hier dieselben Verfahren für die Arbeit mit Tags wie für Aurora- oder RDS-DB-Instances. Sie können die Tags gleichzeitig mit dem Hinzufügen einer neuen DB-Instance zum Aurora-Cluster einrichten, indem Sie die Aktion **Reader hinzufügen** in der Konsole verwenden. Sie können auch Tags und die zugehörigen Werte hinzufügen, entfernen oder ändern, indem Sie auf der Detailseite der DB-Instance die Option **Tags verwalten** auf der Registerkarte **Tags** auswählen.
Nachfolgend einige Beispiele für die Arten von Tags, die Sie innerhalb einer globalen Datenbank zuweisen können:
+ Sie können dem globalen Cluster Tags hinzufügen, um allgemeine Informationen über Ihre Anwendung zu erfassen, z. B. anonymisierte Kennungen, die Eigentümer und Kontakte innerhalb Ihrer Organisation repräsentieren. Sie können Tags verwenden, um Eigenschaften der Anwendung zu kennzeichnen, die die globale Datenbank verwendet.
+ Sie können dem primären Cluster und den sekundären Clustern Tags hinzufügen, um die Kosten für Ihre Anwendung auf AWS-Regionsebene nachzuverfolgen. Einzelheiten zu diesem Verfahren finden Sie unter [So funktioniert die AWS Abrechnung mit Tags in Amazon RDS](USER_Tagging.md#Tagging.Billing).
+ Sie können bestimmten DB-Instances mit den Aurora-Clustern Tags hinzufügen, um deren speziellen Zweck anzugeben. Sie könnten zum Beispiel innerhalb des primären Clusters eine Reader-Instance mit einer niedrigen Failover-Priorität haben, die ausschließlich für die Berichtsgenerierung verwendet wird. Durch ein Tag hebt sich diese spezielle DB-Instance von anderen Instances ab, die für eine hohe Verfügbarkeit innerhalb des primären Clusters vorgesehen sind.
+ Sie können Tags auf allen Ebenen Ihrer globalen Datenbankressourcen verwenden, um den Zugriff über IAM-Richtlinien zu steuern. Weitere Informationen finden Sie unter [Steuern des Zugriffs auf AWS-Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html#access_tags_control-resources) im *AWS-Identity-and-Access-Management-Benutzerhandbuch*.
**Tipp**
In der AWS-Managementkonsole fügen Sie Tags zum globalen Cluster-Container in einem separaten Schritt hinzu, nachdem Sie ihn erstellt haben. Wenn Sie Zeitintervalle vermeiden möchten, in denen der globale Cluster ohne Tags für die Zugriffskontrolle existiert, können Sie die Tags während der `CreateGlobalCluster`-Operation anwenden, indem Sie die Ressource mit der AWS CLI, der RDS-API oder einer CloudFormation-Vorlage erstellen.
+ Sie können Tags auf Cluster-Ebene oder für den globalen Cluster verwenden, um Informationen zur Qualitätssicherung und zum Testen Ihrer Anwendung zu erfassen. Sie können beispielsweise ein Tag auf einem DB-Cluster angeben, um zu erfassen, wann Sie das letzte Mal eine Umstellung zu diesem Cluster durchgeführt haben. Sie können ein Tag für den globalen Cluster angeben, um den Zeitpunkt der letzten Notfallwiederherstellungsübung für die gesamte Anwendung zu erfassen.
## AWS CLI-Beispiele für das Taggen globaler Datenbanken
Die folgenden AWS CLI-Beispiele zeigen, wie Sie Tags für alle Arten von Aurora-Ressourcen in Ihrer globalen Datenbank angeben und untersuchen können.
Sie können Tags für den globalen Cluster-Container mit dem `create-global-cluster`-Befehl angeben. Der folgende Befehl erstellt einen globalen Cluster und weist diesem 2 Tags zu. Die Tags haben die Schlüssel `tag1` und `tag2`.
```
$ aws rds create-global-cluster --global-cluster-identifier my_global_cluster_id \
--engine aurora-mysql --tags Key=tag1,Value=val1 Key=tag2,Value=val2
```
Sie können die Tags im globalen Cluster-Container mit dem `describe-global-clusters`-Befehl auflisten. Wenn Sie mit Tags arbeiten, führen Sie diesen Befehl normalerweise zuerst aus, um den Amazon-Ressourcennamen (ARN) des globalen Clusters abzurufen. Sie verwenden den ARN als Parameter in nachfolgenden Befehlen für die Arbeit mit Tags. Mit dem folgenden Befehl werden die Tag-Informationen im `TagList`-Attribut angezeigt. Er zeigt auch den ARN, der in den späteren Beispielen als Parameter verwendet wird.
```
$ aws rds describe-global-clusters --global-cluster-identifier my_global_cluster_id
{
"GlobalClusters": [
{
"Status": "available",
"Engine": "aurora-mysql",
"GlobalClusterArn": "my_global_cluster_arn",
...
"TagList": [
{
"Value": "val1",
"Key": "tag1"
},
{
"Value": "val2",
"Key": "tag2"
}
]
}
]
}
```
Sie können mit dem `add-tags-to-resource`-Befehl neue Tags hinzufügen. Mit diesem Befehl geben Sie anstelle der ID den Amazon-Ressourcennamen (ARN) des globalen Clusters an. Wenn Sie ein neues Tag hinzufügen, dessen Name mit dem eines vorhandenen Tags identisch ist, wird der vorherige Tag-Wert überschrieben. Wenn Sie Leerzeichen oder Sonderzeichen in die Tag-Werte aufnehmen, setzen Sie die Werte entsprechend Ihrem Betriebssystem oder Ihrer Befehls-Shell in Anführungszeichen. Im folgenden Beispiel werden die Tags des globalen Clusters aus dem vorherigen Beispiel geändert. Ursprünglich hatte der Cluster Tags mit den Schlüsseln `tag1` und `tag2`. Nach Ausführung des Befehls hat der globale Cluster ein neues Tag mit dem Schlüssel `tag3` und das Tag mit dem Schlüssel `tag1` hat einen anderen Wert.
```
$ aws rds add-tags-to-resource --resource-name my_global_cluster_arn \
--tags Key=tag1,Value="new value for tag1" Key=tag3,Value="entirely new tag"
$ aws rds describe-global-clusters --global-cluster-identifier my_global_cluster_id
{
"GlobalClusters": [
{
"Status": "available",
"Engine": "aurora-mysql",
...
"TagList": [
{
"Value": "new value for tag1",
"Key": "tag1"
},
{
"Value": "val2",
"Key": "tag2"
},
{
"Value": "entirely new tag",
"Key": "tag3"
}
]
}
]
}
```
Mit dem `remove-tags-from-resource`-Befehl können Sie ein Tag aus dem globalen Cluster löschen. Mit diesem Befehl geben Sie nur einen Satz von Tag-Schlüsseln ohne Tag-Werte an. Im folgenden Beispiel werden die Tags des globalen Clusters aus dem vorherigen Beispiel geändert. Ursprünglich hatte der Cluster Tags mit den Schlüsseln `tag1`, `tag2` und `tag3`. Nach Ausführung des Befehls bleibt nur das Tag mit dem Schlüssel `tag1` übrig.
```
$ aws rds remove-tags-from-resource --resource-name my_global_cluster_arn --tag-keys tag2 tag3
$ aws rds describe-global-clusters --global-cluster-identifier my_global_cluster_id
{
"GlobalClusters": [
{
"Status": "available",
"Engine": "aurora-mysql",
...
"TagList": [
{
"Value": "new value for tag1",
"Key": "tag1"
}
]
}
]
}
```
# Verbinden mit Amazon Aurora Global Database
Jede globale Aurora-Datenbank verfügt über einen Writer-Endpunkt, der automatisch von Aurora aktualisiert wird, um Anfragen an die aktuelle Writer-Instance des primären DB-Clusters weiterzuleiten. Mit dem Writer-Endpunkt müssen Sie Ihre Verbindungszeichenfolge nicht ändern, nachdem Sie den Standort der primären Region mithilfe der verwalteten Umstellungs- und Failover-Funktionen von Aurora Global Database geändert haben. Weitere Informationen zur Verwendung des Writer-Endpunkts zusammen mit den Umstellungs- und Failover-Funktionen von Aurora Global Database finden Sie unter [Verwenden von Umstellung oder Failover in Amazon Aurora Global Database](aurora-global-database-disaster-recovery.md). Informationen zum Verbinden mit einer globalen Aurora-Datenbank über RDS-Proxy finden Sie unter [Verwenden von RDS-Proxy mit globalen Aurora-Datenbanken](https://docs.aws.amazon.com/AuroraUserGuide/rds-proxy-gdb.html).
**Topics**
+ [Auswählen des Endpunkts, der Ihren Anwendungsanforderungen entspricht](#gdb-endpoint-choosing)
+ [Anzeigen der Endpunkte einer globalen Amazon-Aurora-Datenbank](#viewing-endpoints)
+ [Überlegungen zur Verwendung globaler Writer-Endpunkte](#global-writer-endpoint-considerations)
## Auswählen des Endpunkts, der Ihren Anwendungsanforderungen entspricht
Die Verbindung zu einer globalen Aurora-Datenbank hängt davon ab, ob Sie aus der Datenbank lesen oder in diese schreiben müssen sowie von der AWS-Region, an die Sie Ihre Anfragen weiterleiten möchten. Nachfolgend ein paar typische Anwendungsfälle:
+ **Weiterleiten von Anfragen an die Writer-Instance**: Stellen Sie eine Verbindung zum Writer-Endpunkt von Aurora Global Database her, wenn Sie Data Manipulation Language (DML)- und Data Definition Language (DDL)-Anweisungen ausführen müssen oder wenn Sie eine hohe Konsistenz zwischen Lese- und Schreibvorgängen benötigen. Dieser Endpunkt leitet Anfragen an die Writer-Instance im primären Cluster Ihrer globalen Datenbank weiter. Dieser Endpunkt wird automatisch aktualisiert, um Anfragen an die Writer-Instance weiterzuleiten, sodass Sie Ihre Anwendung nicht jedes Mal aktualisieren müssen, wenn Sie den Writer-Standort in Ihrem globalen Cluster ändern. Sie können den globalen Endpunkt auch verwenden, um regionsübergreifende Lese-/Schreibanfragen an Ihren Writer zu senden.
**Anmerkung**
Wenn Sie Ihre globale Datenbank eingerichtet haben, bevor der Writer-Endpunkt von Aurora Global Database verfügbar war, stellt Ihre Anwendung möglicherweise eine Verbindung zum Cluster-Endpunkt des primären Clusters her. In diesem Fall empfehlen wir, Ihre Verbindungseinstellungen so zu ändern, dass stattdessen der globale Writer-Endpunkt verwendet wird. Dadurch müssen Sie Ihre Verbindungseinstellungen nicht nach jeder Umstellung oder jedem Failover von Aurora Global Database ändern.
Der erste Teil des Namens des Writer-Endpunkts ist der Name Ihrer globalen Aurora-Datenbank. Wenn Sie also Ihre globale Aurora-Datenbank umbenennen, ändert sich der Name des Writer-Endpunkts, und jeder Code, der ihn verwendet, muss mit dem neuen Namen aktualisiert werden.
+ **Skalieren von Lesevorgängen näher an der Region Ihrer Anwendung**: Um schreibgeschützte Anfragen in derselben AWS-Region wie Ihre Anwendung oder in einer nahegelegenen zu skalieren, stellen Sie eine Verbindung zum Reader-Endpunkt des primären oder sekundären Aurora-Clusters her.
+ **Skalieren von Lesevorgängen mit gelegentlichen regionsübergreifenden Schreibvorgängen**: Stellen Sie für gelegentliche DML-Anweisungen, z. B. zur Wartung und Datenbereinigung, eine Verbindung zum Reader-Endpunkt eines sekundären Clusters her, für den die Schreibweiterleitung aktiviert ist. Mit der Schreibweiterleitung leitet Aurora die Schreibanweisungen automatisch an den Writer in der primären Region Ihrer globalen Aurora-Datenbank weiter. Die Schreibweiterleitung bietet die folgenden Vorteile:
+ Sie müssen sich nicht die Mühe machen, eine Konnektivität zwischen dem sekundären und dem primären Cluster herzustellen, um regionsübergreifende Schreibvorgänge zu senden.
+ Sie müssen Lese- und Schreibanforderungen in der Anwendung nicht aufteilen.
+ Sie müssen keine komplexe Logik entwickeln, um die Konsistenz von Read-After-Write-Anfragen zu gewährleisten.
Bei der Schreibweiterleitung müssen Sie jedoch Ihren Anwendungscode oder Ihre Konfiguration aktualisieren, um nach einem regionsübergreifenden Failover oder einer solchen Umstellung eine Verbindung zum Reader-Endpunkt der neu hochgestuften primären Region herzustellen. Es wird empfohlen, die Latenz von Vorgängen, die über die Schreibweiterleitung ausgeführt werden, zu überwachen, um den Overhead bei der Verarbeitung der Schreibanforderungen zu überprüfen. Schließlich unterstützt die Schreibweiterleitung bestimmte MySQL- oder PostgreSQL-Operationen nicht, wie beispielsweise DDL-Änderungen oder `SELECT FOR UPDATE`-Anweisungen.
Weitere Informationen zur Verwendung der Schreibweiterleitung innerhalb von AWS-Regionen finden Sie unter [Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank](aurora-global-database-write-forwarding.md).
Einzelheiten zu den verschiedenen Arten von Aurora-Endpunkten finden Sie unter [Herstellen einer Verbindung mit einem Amazon Aurora-DB-Cluster](Aurora.Connecting.md).
## Anzeigen der Endpunkte einer globalen Amazon-Aurora-Datenbank
Wenn Sie eine globale Aurora-Datenbank in der Konsole anzeigen, können Sie alle Endpunkte sehen, die mit allen ihren Clustern verknüpft sind. Die folgende Abbildung zeigt ein Beispiel für die Arten von Endpunkten, die Sie sehen, wenn Sie sich die Details für Ihren primären DB-Cluster ansehen:
+ Globaler Writer – Dies ist der einzelne Lese-/Schreibendpunkt, der immer auf die aktuelle Writer-DB-Instance für den globalen Datenbank-Cluster verweist.
+ Writer – Dies ist der Verbindungsendpunkt für Lese-/Schreibanforderungen an den primären DB-Cluster im globalen Datenbankcluster.
+ Reader – Dies ist der Verbindungsendpunkt für schreibgeschützte Anfragen an einen primären oder sekundären DB-Cluster im globalen Datenbank-Cluster. Zum Minimieren der Latenzzeit wählen Sie denjenigen Reader-Endpunkt aus, der sich in Ihrer AWS-Region oder der Ihnen am nächsten gelegenen AWS-Region befindet.
![\[In der RDS-Konsole zeigt die Registerkarte „Konnektivität und Sicherheit“ für eine globale Aurora-Datenbank den globalen Writer-Endpunkt an.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-primary-cluster-connectivity-2.png)
### Konsole
**So zeigen Sie die Endpunkte einer globalen Datenbank an**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie in der Liste die globale Datenbank oder den primären oder sekundären DB-Cluster aus, dessen Endpunkte Sie anzeigen möchten.
1. Wählen Sie die Registerkarte **Konnektivität und Sicherheit** aus, um die Endpunktdetails zu sehen. Die angezeigten Endpunkte hängen vom Typ des Clusters ab, den Sie ausgewählt haben:
+ Globale Datenbank – der globale Writer-Endpunkt
+ Primärer DB-Cluster – der globale Writer-Endpunkt sowie der Cluster-Endpunkt und der Reader-Endpunkt für den primären Cluster
+ Sekundärer DB-Cluster – der Cluster-Endpunkt und der Reader-Endpunkt für den sekundären Cluster Auf einem sekundären Cluster zeigt der Cluster-Endpunkt den Status **inaktiv** an, da er keine Schreibanforderungen bearbeitet. Sie können weiterhin eine Verbindung zum Cluster-Endpunkt herstellen, jedoch nur für Leseabfragen.
### AWS CLI
Um den Writer-Endpunkt des globalen Clusters anzuzeigen, verwenden Sie den AWS CLI-Befehl [describe-global-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-global-clusters.html) wie im folgenden Beispiel gezeigt.
```
aws rds describe-global-clusters --region aws_region
{
"GlobalClusters": [
{
"GlobalClusterIdentifier": "global_cluster_id",
"GlobalClusterResourceId": "cluster-unique_string",
"GlobalClusterArn": "arn:aws:rds::123456789012:global-cluster:global_cluster_id",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2",
"GlobalClusterMembers": [
...
],
"Endpoint": "global_cluster_id.global-unique_string.global.rds.amazonaws.com"
}
]
}
```
Um die Cluster- und Reader-Endpunkte für Mitglieds-DB-Cluster des globalen Clusters anzuzeigen, verwenden Sie den AWS CLI-Befehl [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) wie im folgenden Beispiel gezeigt. Bei den für `Endpoint` und `ReaderEndpoint` zurückgegebenen Werten handelt es sich um die Endpunkte für den Cluster bzw. Reader.
```
aws rds describe-db-clusters --region primary_region --db-cluster-identifier db_cluster_id
{
"DBClusters": [
{
"AllocatedStorage": 1,
"AvailabilityZones": [
"az_1",
"az_2",
"az_3"
],
"BackupRetentionPeriod": 1,
"DBClusterIdentifier": "db_cluster_id",
"DBClusterParameterGroup": "default.aurora-mysql5.7",
"DBSubnetGroup": "default",
"Status": "available",
"EarliestRestorableTime": "2023-08-01T18:21:11.301Z",
"Endpoint": "db_cluster_id.cluster-unique_string.primary_region.rds.amazonaws.com",
"ReaderEndpoint": "db_cluster_id.cluster-ro-unique_string.primary_region.rds.amazonaws.com",
"MultiAZ": false,
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2",
"ReadReplicaIdentifiers": [
"arn:aws:rds:secondary_region:123456789012:cluster:db_cluster_id"
],
"DBClusterMembers": [
{
"DBInstanceIdentifier": "db_instance_id",
"IsClusterWriter": true,
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1
}
],
...
"TagList": [],
"GlobalWriteForwardingRequested": false
}
]
}
```
### RDS-API
Verwenden Sie die RDS-API-Operation [DescribeGlobalClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeGlobalClusters.html), um den Writer-Endpunkt des globalen Clusters anzuzeigen. Verwenden Sie die RDS-API-Operation [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html), um die Cluster- und Reader-Endpunkte für Mitglieds-DB-Cluster des globalen Clusters anzuzeigen.
## Überlegungen zur Verwendung globaler Writer-Endpunkte
Sie können Writer-Endpunkte von Aurora Global Database effektiv nutzen, indem Sie sich an die folgenden Richtlinien und bewährten Methoden halten:
+ Um Unterbrechungen nach einem regionsübergreifenden Failover oder einer solchen Umstellung zu minimieren, können Sie eine VPC-Konnektivität zwischen Ihrer Anwendungsdatenverarbeitung und Ihren primären und sekundären AWS-Regionen einrichten. Angenommen, Sie haben Anwendungen oder Clientsysteme, die in derselben VPC wie der primäre Cluster ausgeführt werden. Wenn der sekundäre Cluster hochgestuft wird, ändert sich der globale Writer-Endpunkt automatisch so, dass er auf diesen Cluster verweist. Mit dem globalen Writer-Endpunkt können Sie zwar vermeiden, dass Sie die Verbindungseinstellungen für Ihre Anwendung ändern müssen, Ihre Anwendungen können aber erst dann auf die IP-Adressen in der VPC der neu hochgestuften, primären AWS-Region zugreifen, wenn Sie ein Netzwerk zwischen den beiden VPCs eingerichtet haben. Unter [Amazon VPC-to-Amazon VPC connectivity options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html) finden Sie Informationen zur Bewertung verschiedener Optionen für die Einrichtung dieser Konnektivität.
+ Die Aktualisierung des globalen Writer-Endpunkts nach einem globalen Datenbank-Failover oder einer solchen Umstellung kann je nach Dauer der Zwischenspeicherung Ihres Domain Name Service (DNS) lange dauern. Weitere Informationen finden Sie im [Administratorhandbuch zu Amazon Aurora-MySQL-Datenbanken](https://docs.aws.amazon.com/pdfs/whitepapers/latest/amazon-aurora-mysql-db-admin-handbook/amazon-aurora-mysql-db-admin-handbook.pdf). Aurora Global Database gibt ein RDS-Ereignis aus, wenn es eine DNS-Änderung auf dem globalen Writer-Endpunkt feststellt. Sie können das Ereignis verwenden, um Strategien zu entwickeln, die dafür sorgen, dass die Dauer der DNS-Zwischenspeicherung nicht über die Zeit nach der Generierung des Ereignisses hinausgeht. Weitere Informationen finden Sie unter [DB-Cluster-Ereignisse](USER_Events.Messages.md#USER_Events.Messages.cluster).
+ Aurora Global Database repliziert Daten asynchron. Die regionsübergreifenden Failover-Methoden können dazu führen, dass einige Schreibtransaktionsdaten vor dem Eintreten des Failovers nicht zur gewählten sekundären Region repliziert wurden. Obwohl Aurora nach besten Kräften versucht, Schreibvorgänge in der ursprünglichen primären AWS-Region zu blockieren, kann ein Failover Split-Brain-Probleme nach sich ziehen. Die Überlegungen zur Minimierung von Datenverlusten und Split-Brain-Risiken gelten auch für Writer-Endpunkte von Aurora Global Database. Weitere Informationen finden Sie unter [Ausführen von verwalteten geplanten Failovers für globale Aurora-Datenbanken](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.managed-unplanned).
# Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank
Sie können die Anzahl der Endpunkte reduzieren, die Sie für Anwendungen verwalten müssen, die in Ihrer Aurora globalen Datenbank ausgeführt werden, indem Sie *Schreibweiterleitung* verwenden. Wenn die Schreibweiterleitung aktiviert ist, leiten sekundäre Cluster in einer Aurora Global Database SQL-Anweisungen, die Schreibvorgänge ausführen, an den primären Cluster weiter. Der primäre Cluster aktualisiert die Quelle und überträgt dann die resultierenden Änderungen an alle sekundären AWS-Regionen zurück.
Die Konfiguration der Schreibweiterleitung erspart Ihnen die Implementierung Ihres eigenen Mechanismus zum Senden von Schreibvorgängen von einer sekundären AWS-Region an die primäre Region. Aurora übernimmt die regionsübergreifende Netzwerk-Einrichtung. Aurora überträgt auch den gesamten erforderlichen Sitzungs- und Transaktionskontext für jede Anweisung. Die Daten werden stets zuerst im primären Cluster geändert und anschließend zu den sekundären Clustern in der Aurora globalen Datenbank repliziert. Daher ist der primäre Cluster die autoritative Quelle und enthält stets die jeweils aktuellen Versionen all Ihrer Daten.
**Topics**
+ [Verwenden der Schreibweiterleitung in einer globalen Aurora-MySQL-Datenbank](aurora-global-database-write-forwarding-ams.md)
+ [Verwenden der Schreibweiterleitung in einer globalen Aurora-PostgreSQL-Datenbank](aurora-global-database-write-forwarding-apg.md)
# Verwenden der Schreibweiterleitung in einer globalen Aurora-MySQL-Datenbank
**Topics**
+ [Verfügbarkeit von Regionen und Versionen der Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-regions-versions-ams)
+ [Aktivieren der Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-enabling-ams)
+ [Überprüfen, ob die Schreibweiterleitung für einen sekundären Cluster in Aurora MySQL aktiviert ist](#aurora-global-database-write-forwarding-describing-ams)
+ [Anwendungs- und SQL-Kompatibilität mit Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-compatibility-ams)
+ [Isolation und Konsistenz für die Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-isolation-ams)
+ [Ausführen von Multipart-Anweisungen mit Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-multipart-ams)
+ [Transaktionen mit Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-txns-ams)
+ [Konfigurationsparameter für die Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-params-ams)
+ [Amazon-CloudWatch-Metriken für die Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-cloudwatch-ams)
+ [Aurora-MySQL-Statusvariablen für die Schreibweiterleitung](#aurora-global-database-write-forwarding-status-ams)
## Verfügbarkeit von Regionen und Versionen der Schreibweiterleitung in Aurora MySQL
Die Schreibweiterleitung wird für Aurora MySQL 2.08.1 und höhere Versionen in jeder Region unterstützt, in der Aurora-MySQL-basierte globale Datenbanken verfügbar sind.
Informationen zur Verfügbarkeit von Versionen und Regionen von globalen Aurora-MySQL-Datenbanken finden Sie unter [Globale Aurora-Datenbanken mit Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.amy).
## Aktivieren der Schreibweiterleitung in Aurora MySQL
Standardmäßig ist die Schreibweiterleitung nicht aktiviert, wenn Sie einen sekundären Cluster zu einer Aurora Global Database hinzufügen.
Um die Schreibweiterleitung über die AWS-Managementkonsole zu aktivieren, wählen Sie das Kontrollkästchen **Globale Schreibweiterleitung aktivieren** unter **Read-Replica-Schreibweiterleitung** aus, wenn Sie eine Region für eine globale Datenbank hinzufügen. Ändern Sie den Cluster für einen vorhandenen sekundären Cluster in **Globale Schreibweiterleitung aktivieren**. Wenn Sie die Schreibweiterleitung ausschalten möchten, deaktivieren Sie beim Hinzufügen der Region oder beim Ändern des sekundären Clusters das Kontrollkästchen **Read-Replica-Schreibweiterleitung aktivieren**.
Um die Schreibweiterleitung über die AWS CLI zu aktivieren, verwenden Sie die Option `--enable-global-write-forwarding`. Diese Option funktioniert, wenn Sie über den Befehl `create-db-cluster` einen neuen sekundären Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster über den Befehl `modify-db-cluster` ändern. Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie die Option `--no-enable-global-write-forwarding` mit denselben CLI-Befehlen verwenden.
Um die Schreibweiterleitung über die Amazon-RDS-API zu aktivieren, legen Sie den Parameter `EnableGlobalWriteForwarding` auf `true` fest. Dieser Parameter funktioniert, wenn Sie über die Operation `CreateDBCluster` einen neuen sekundären Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster über die Operation `ModifyDBCluster` ändern. Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie den Parameter `EnableGlobalWriteForwarding` auf `false` festlegen.
**Anmerkung**
Damit eine Datenbanksitzung die Schreibweiterleitung verwenden kann, geben Sie eine Einstellung für den Konfigurationsparameter `aurora_replica_read_consistency` an. Sie führen dies in jeder Sitzung aus, in der die Schreibweiterleitungsfunktion verwendet wird. Informationen zu diesem Parameter finden Sie unter [Isolation und Konsistenz für die Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-isolation-ams).
Die RDS-Proxy-Funktion unterstützt den `SESSION`-Wert für die Variable `aurora_replica_read_consistency` nicht. Durch das Festlegen dieses Werts kann unerwartetes Verhalten auftreten.
Die folgenden CLI-Beispiele zeigen, wie Sie eine Aurora Global Database mit aktivierter oder deaktivierter Schreibweiterleitung einrichten. Die markierten Elemente stellen die Befehle und Optionen dar, die bei der Einrichtung der Infrastruktur für eine Aurora Global Database Datenbank angegeben werden müssen und konsistent sein müssen.
Im folgenden Beispiel werden eine Aurora Global Database, ein primärer Cluster und ein sekundärer Cluster mit aktivierter Schreibweiterleitung erstellt. Geben Sie Ihre eigenen Daten für Benutzername, Passwort und primäre und sekundäre AWS-Regionen ein.
```
# Create overall global database.
aws rds create-global-cluster --global-cluster-identifier write-forwarding-test \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-1
# Create primary cluster, in the same AWS Region as the global database.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
--db-cluster-identifier write-forwarding-test-cluster-1 \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--master-username user_name --master-user-password password \
--region us-east-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
--db-instance-identifier write-forwarding-test-cluster-1-instance-1 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
--db-instance-identifier write-forwarding-test-cluster-1-instance-2 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-1
# Create secondary cluster, in a different AWS Region than the global database,
# with write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
--db-cluster-identifier write-forwarding-test-cluster-2 \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-2 \
--enable-global-write-forwarding
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-2
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-east-2
```
Das folgende Beispiel setzt das vorherige Beispiel fort. In ihm werden ein sekundärer Cluster ohne aktivierte Schreibweiterleitung erstellt und anschließend die Schreibweiterleitung aktiviert. Nach Abschluss dieses Beispiels ist die Schreibweiterleitung für alle sekundären Cluster in der globalen Datenbank aktiviert.
```
# Create secondary cluster, in a different AWS Region than the global database,
# without write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
--db-cluster-identifier write-forwarding-test-cluster-2 \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-west-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-west-1
aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
--db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
--db-instance-class db.r5.large \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
--region us-west-1
aws rds modify-db-cluster --db-cluster-identifier write-forwarding-test-cluster-2 \
--region us-east-2 \
--enable-global-write-forwarding
```
## Überprüfen, ob die Schreibweiterleitung für einen sekundären Cluster in Aurora MySQL aktiviert ist
Um festzustellen, ob Sie die Schreibweiterleitung aus einem sekundären Cluster verwenden können, können Sie prüfen, ob der Cluster das Attribut besitz `"GlobalWriteForwardingStatus": "enabled"`.
In der AWS-Managementkonsole sehen Sie auf der Registerkarte **Konfiguration** der Detailseite des Clusters den Status**Aktiviert** für **Globale Lesereplikat-Schreibweiterleitung**.
Um den Status der globalen Einstellung für die Schreibweiterleitung für alle Cluster anzuzeigen, führen Sie den folgenden AWS CLI-Befehl aus.
Ein sekundärer Cluster zeigt die Werte `"enabled"` oder `"disabled"` an, um anzugeben, ob die Schreibweiterleitung aktiviert oder deaktiviert ist. Der Wert `null` gibt an, dass die Schreibweiterleitung für diesen Cluster nicht verfügbar ist. Entweder ist der Cluster nicht Teil einer globalen Datenbank oder ist der primäre Cluster und nicht kein sekundärer Cluster. Der Wert kann auch `"enabling"` oder `"disabling"` sein, wenn die Schreibweiterleitung gerade aktiviert oder deaktiviert wird.
**Example**
```
aws rds describe-db-clusters \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'
[
{
"GlobalWriteForwardingStatus": "enabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
},
{
"GlobalWriteForwardingStatus": "disabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
},
{
"GlobalWriteForwardingStatus": null,
"DBClusterIdentifier": "non-global-cluster"
}
]
```
Führen Sie den folgenden Befehl aus, um alle sekundären Cluster zu suchen, für die eine globale Schreibweiterleitung aktiviert ist. Dieser Befehl gibt auch den Reader-Endpunkt des Clusters aus. Sie verwenden den Reader-Endpunkt des sekundären Clusters, wenn Sie die Schreibweiterleitung vom sekundären zum primären Cluster in Ihrer globalen Aurora-Datenbank verwenden.
**Example**
```
aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
{
"GlobalWriteForwardingStatus": "enabled",
"ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
}
]
```
## Anwendungs- und SQL-Kompatibilität mit Schreibweiterleitung in Aurora MySQL
Sie können die folgenden Arten von SQL-Anweisungen mit Schreibweiterleitung verwenden:
+ Data Manipulation Language (DM)-Anweisungen wie `INSERT`, wie`DELETE` und `UPDATE`. Es gibt einige Einschränkungen für die Eigenschaften dieser Anweisungen, die Sie bei der Schreibweiterleitung verwenden können, wie im Folgenden beschrieben.
+ `SELECT ... LOCK IN SHARE MODE`- und `SELECT FOR UPDATE`-Anweisungen.
+ `PREPARE`- und `EXECUTE`-Anweisungen.
Bestimmte Anweisungen sind nicht zulässig oder können veraltete Ergebnisse erzeugen, wenn Sie sie in einer globalen Datenbank mit Schreibweiterleitung verwenden. Daher ist die Einstellung `EnableGlobalWriteForwarding` für sekundäre Cluster standardmäßig deaktiviert. Stellen Sie vor einer Aktivierung sicher, dass der Anwendungscode von keiner dieser Einschränkungen betroffen ist.
Die folgenden Einschränkungen gelten für die SQL-Anweisungen, die Sie für die Schreibweiterleitung verwenden. In einigen Fällen können Sie die Anweisungen auf sekundären Clustern verwenden, bei denen eine Schreibweiterleitung auf Cluster-Ebene aktiviert ist. Dieser Ansatz funktioniert, wenn die Schreibweiterleitung nicht innerhalb der Sitzung durch den Konfigurationsparameter `aurora_replica_read_consistency` aktiviert wird. Der Versuch, eine Anweisung zu verwenden, wenn sie aufgrund der Schreibweiterleitung nicht zulässig ist, verursacht eine Fehlermeldung im folgendem Format.
```
ERROR 1235 (42000): This version of MySQL doesn't yet support 'operation with write forwarding'.
```
**Data Definition Language (DDL)**
Stellen Sie eine Verbindung zum primären Cluster her, um DDL-Anweisungen auszuführen. Sie können sie nicht von Reader-DB-Instances aus ausführen.
**Aktualisieren einer permanenten Tabelle mit Daten aus einer temporären Tabelle**
Sie können in sekundären Clustern mit aktivierter Schreibweiterleitung temporäre Tabellen verwenden. Sie können jedoch keine DML-Anweisung verwenden, um eine permanente Tabelle zu ändern, wenn sich die Anweisung auf eine temporäre Tabelle bezieht. Beispielsweise können Sie keine `INSERT ... SELECT`-Anweisung verwenden, die die Daten aus einer temporären Tabelle übernimmt. Die temporäre Tabelle ist auf dem sekundären Cluster vorhanden und nicht verfügbar, wenn die Anweisung auf dem primären Cluster ausgeführt wird.
**XA-Transaktionen**
Sie können die folgenden Anweisungen nicht in einem sekundären Cluster verwenden, wenn die Schreibweiterleitung innerhalb der Sitzung aktiviert wird. Sie können diese Anweisungen in sekundären Clustern verwenden, bei denen die Schreibweiterleitung nicht aktiviert ist, oder innerhalb von Sitzungen mit leerer Einstellung `aurora_replica_read_consistency`. Bevor Sie die Schreibweiterleitung innerhalb einer Sitzung aktivieren, müssen Sie überprüfen, ob Ihr Code diese Anweisungen verwendet.
```
XA {START|BEGIN} xid [JOIN|RESUME]
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA RECOVER [CONVERT XID]
```
**LOAD-Anweisungen für permanente Tabellen**
Sie können die folgenden Anweisungen nicht in einem sekundären Cluster mit aktivierter Schreibweiterleitung verwenden.
```
LOAD DATA INFILE 'data.txt' INTO TABLE t1;
LOAD XML LOCAL INFILE 'test.xml' INTO TABLE t1;
```
Sie können in einem sekundären Cluster Daten in eine temporäre Tabelle laden. Sie dürfen jedoch alle `LOAD`-Anweisungen, die sich auf permanente Tabellen beziehen, nur im primären Cluster ausführen.
**Plugin-Anweisungen**
Sie können die folgenden Anweisungen nicht in einem sekundären Cluster mit aktivierter Schreibweiterleitung verwenden.
```
INSTALL PLUGIN example SONAME 'ha_example.so';
UNINSTALL PLUGIN example;
```
**SAVEPOINT-Anweisungen**
Sie können die folgenden Anweisungen nicht in einem sekundären Cluster verwenden, wenn die Schreibweiterleitung innerhalb der Sitzung aktiviert wird. Sie können diese Anweisungen in sekundären Clustern ohne aktivierte Schreibweiterleitung oder in Sitzungen mit leerer Einstellung `aurora_replica_read_consistency` verwenden. Sie müssen überprüfen, ob Ihr Code diese Anweisungen verwendet, bevor Sie die Schreibweiterleitung innerhalb einer Sitzung aktivieren.
```
SAVEPOINT t1_save;
ROLLBACK TO SAVEPOINT t1_save;
RELEASE SAVEPOINT t1_save;
```
## Isolation und Konsistenz für die Schreibweiterleitung in Aurora MySQL
In Sitzungen, die Schreibweiterleitung verwenden, können Sie nur die Isolationsstufe `REPEATABLE READ` verwenden. Obwohl Sie die Isolationsstufe `READ COMMITTED` auch mit schreibgeschützten Clustern in sekundären AWS-Regionen verwenden können, funktioniert diese Isolationsstufe nicht mit Schreibweiterleitung. Weitere Informationen zu den Isolationsstufen `REPEATABLE READ` und `READ COMMITTED` finden Sie unter [Aurora MySQL-Isolierungsstufen](AuroraMySQL.Reference.IsolationLevels.md).
Sie können den Grad der Lesekonsistenz in einem sekundären Cluster steuern. Die Lesekonsistenzstufe legt fest, wie viel Wartezeit der sekundäre Cluster vor jeder Leseoperation ausführt, um sicherzustellen, dass einige oder alle Änderungen aus dem primären Cluster repliziert werden. Sie können die Lesekonsistenzstufe anpassen, um sicherzustellen, dass alle aus Ihrer Sitzung weitergeleiteten Schreiboperationen im sekundären Cluster vor nachfolgenden Abfragen angezeigt werden. Sie können diese Einstellung auch verwenden, um sicherzustellen, dass Abfragen auf dem sekundären Cluster stets die aktuellsten Updates des primären Clusters angezeigt werden. Dies gilt auch für diejenigen, die von anderen Sitzungen oder anderen Clustern übermittelt wurden. Um diese Art von Verhalten für Ihre Anwendung anzugeben, wählen Sie einen Wert für den Sitzungsebenen-Parameter au `aurora_replica_read_consistency`.
**Wichtig**
Legen Sie immer den Parameter `aurora_replica_read_consistency` für jede Sitzung fest, für die Sie Schreibvorgänge weiterleiten möchten. Andernfalls aktiviert Aurora die Schreibweiterleitung für diese Sitzung nicht. Dieser Parameter hat standardmäßig einen leeren Wert, wählen Sie daher einen bestimmten Wert, wenn Sie diesen Parameter verwenden. Der Parameter `aurora_replica_read_consistency` wirkt sich nur auf sekundäre Cluster aus, in denen die Schreibweiterleitung aktiviert ist.
Verwenden Sie für Aurora-MySQL-Version 2 und Version 3 unter 3.04 `aurora_replica_read_consistency` als Sitzungsvariable. Für Aurora-MySQL-Version 3.04 und höher können Sie `aurora_replica_read_consistency` entweder als Sitzungsvariable oder als DB-Cluster-Parameter verwenden.
Für den Parameter `aurora_replica_read_consistency` können Sie die Werte `EVENTUAL`, `SESSION` und `GLOBAL` angeben.
Wenn Sie das Konsistenzniveau erhöhen, verbringt Ihre Anwendung mehr Zeit mit dem Warten auf die Propagierung von Änderungen zwischen AWS-Regionen. Sie können das Verhältnis zwischen schneller Reaktionszeit und der Gewährleistung festlegen, dass vor der Ausführung Ihrer Abfragen Änderungen an anderen Speicherorten vollständig verfügbar sind.
Wenn die Lesekonsistenz auf `EVENTUAL` festgelegt wird, werden Abfragen in einer sekundären AWS-Region, die Schreibweiterleitung verwendet, möglicherweise Daten angezeigt, die aufgrund von Replikationsverzögerungen leicht veraltet sind. Ergebnisse von Schreiboperationen in derselben Sitzung werden erst angezeigt, wenn die Schreiboperation in der primären Region ausgeführt und zur aktuellen Region repliziert wird. Die Abfrage wartet nicht, bis die aktualisierten Ergebnisse verfügbar sind. Daher könnte sie die älteren Daten oder die aktualisierten Daten abrufen, abhängig vom Zeitpunkt der Anweisungen und der Größe der Replikationsverzögerung.
Wenn die Lesekonsistenz auf `SESSION` festgelegt ist, werden allen Abfragen in einer sekundären AWS-Region, die Schreibweiterleitung verwendet, die Ergebnisse aller in dieser Sitzung ausgeführten Änderungen angezeigt. Die Änderungen werden unabhängig davon angezeigt, ob die Transaktion übergeben wurde. Wenn notwendig, wartet die Abfrage auf die Replikation der Ergebnisse weitergeleiteter Schreiboperationen zur aktuellen Region. Sie wartet nicht auf aktualisierte Ergebnisse aus Schreiboperationen, die in anderen Regionen oder in anderen Sitzungen innerhalb der aktuellen Region ausgeführt werden.
Wenn die Lesekonsistenz auf `GLOBAL` festgelegt ist, werden einer Sitzung in einer sekundären AWS-Region Änderungen angezeigt, die von dieser Sitzung ausgeführt wurden. Außerdem werden ihr alle übergebenen Änderungen sowohl aus der primären AWS-Region als auch aus anderen sekundären AWS-Regionen angezeigt. Jede Abfrage kann für einen bestimmten Zeitraum warten, abhängig von der Sitzungsverzögerung. Die Abfrage wird fortgesetzt, wenn der sekundäre Cluster mit allen übergebenen Daten aus dem primären Cluster mit Stand zu dem Zeitpunkt, an dem die Abfrage gestartet wurde, aktualisiert ist.
Weitere Informationen zu allen mit der Schreibweiterleitung verbundenen Parametern finden Sie unter [Konfigurationsparameter für die Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-params-ams).
### Beispiele für die Verwendung der Schreibweiterleitung
In diesen Beispielen wird `aurora_replica_read_consistency` als Sitzungsvariable verwendet. Für Aurora-MySQL-Version 3.04 und höher können Sie `aurora_replica_read_consistency` entweder als Sitzungsvariable oder als DB-Cluster-Parameter verwenden.
Im folgenden Beispiel befindet sich der primäre Cluster in der Region US East (N. Virginia). Der sekundäre Cluster befindet sich in der Region USA Ost (Ohio). Das Beispiel zeigt die Auswirkungen ausgeführter `INSERT`-Anweisungen, gefolgt von `SELECT`-Anweisungen. Abhängig vom Wert der Einstellung `aurora_replica_read_consistency` können sich die Ergebnisse abhängig vom Zeitpunkt der Anweisungen unterscheiden. Um eine höhere Konsistenz zu erreichen, können Sie kurz warten, bevor Sie die Anweisung `SELECT` ausführen. Oder Aurora kann automatisch warten, bis die Ergebnisse fertig repliziert sind, bevor mit fortgefahren wir `SELECT`.
In diesem Beispiel gibt es eine Lesekonsistenzeinstellung von `eventual`. Das Ausführen der Anweisung `INSERT` unmittelbar gefolgt von der Anweisung `SELECT` gibt immer noch den Wert von `COUNT(*)` zurück. Dieser Wert gibt die Anzahl der Zeilen an, bevor die neue Zeile eingefügt wird. Wenn Sie kurze Zeit später `SELECT` erneut ausführen, wird die aktualisierte Zeilenzahl zurückgegeben. Die `SELECT`-Anweisungen haben keine Wartezeit.
```
mysql> set aurora_replica_read_consistency = 'eventual';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 5 |
+----------+
1 row in set (0.00 sec)
mysql> insert into t1 values (6); select count(*) from t1;
+----------+
| count(*) |
+----------+
| 5 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 6 |
+----------+
1 row in set (0.00 sec)
```
Bei Festlegung der Lesekonsistenzeinstellung auf `session` wartet eine `SELECT`-Anweisung, die unmittelbar nach einer `INSERT`-Anweisung ausgeführt wird, bis die Änderungen aus der `INSERT`-Anweisung angezeigt werden. Nachfolgende `SELECT`-Anweisungen haben keine Wartezeit.
```
mysql> set aurora_replica_read_consistency = 'session';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 6 |
+----------+
1 row in set (0.01 sec)
mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1;
Query OK, 1 row affected (0.08 sec)
+----------+
| count(*) |
+----------+
| 7 |
+----------+
1 row in set (0.37 sec)
+----------+
| count(*) |
+----------+
| 7 |
+----------+
1 row in set (0.00 sec)
```
Wenn die Lesekonsistenzeinstellung weiter auf `session` festgelegt ist, wird durch die Einführung einer kurzen Wartezeit nach der Ausführung einer `INSERT`-Anweisung die aktualisierte Zeilenzahl zum Zeitpunkt der nächsten Ausführung der `SELECT`-Anweisung verfügbar.
```
mysql> insert into t1 values (6); select sleep(2); select count(*) from t1;
Query OK, 1 row affected (0.07 sec)
+----------+
| sleep(2) |
+----------+
| 0 |
+----------+
1 row in set (2.01 sec)
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.00 sec)
```
Wenn die Leseksistenzeinstellung auf `global` festgelegt ist, wartet jede `SELECT`-Anweisung, um sicherzustellen, dass alle Datenänderungen mit Stand zur Startzeit der Anweisung angezeigt werden, bevor die Abfrage ausgeführt wird. Die Wartezeit für die einzelnen `SELECT`-Anweisungen ist von der Replikationsverzögerung zwischen dem primären und den sekundären Clustern abhängig.
```
mysql> set aurora_replica_read_consistency = 'global';
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.75 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.37 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 8 |
+----------+
1 row in set (0.66 sec)
```
## Ausführen von Multipart-Anweisungen mit Schreibweiterleitung in Aurora MySQL
Eine DML-Anweisung kann aus mehreren Teilen bestehen, z. B. einer `INSERT ... SELECT`-Anweisung oder einer `DELETE ... WHERE`-Anweisung. In diesem Fall wird die gesamte Anweisung an den primären Cluster weitergeleitet und dort ausgeführt.
## Transaktionen mit Schreibweiterleitung in Aurora MySQL
Ob die Transaktion an den primären Cluster weitergeleitet wird, ist vom Zugriffsmodus der Transaktion abhängig. Sie können den Zugriffsmodus für die Transaktion durch Verwendung der Anweisungen `SET TRANSACTION` oder `START TRANSACTION` angeben. Sie können den Transaktionszugriffsmodus auch angeben, indem Sie den Wert der Sitzungsvariablen [transaction\$1read\$1only](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_transaction_read_only) ändern. Sie können diesen Sitzungswert nur ändern, wenn Sie mit einem DB-Cluster verbunden sind, für den die Schreibweiterleitung aktiviert ist.
Wenn eine Transaktion mit langer Laufzeit für einen beträchtlichen Zeitraum keine Anweisung ausgibt, kann sie Leerlaufzeitüberschreitung überschreiten. Dieser Zeitraum hat einen Standardwert von einer Minute. Sie können den Wert auf bis zu einem Tag erhöhen. Eine Transaktion, die die Leerlaufzeitüberschreitung überschreitet, wird vom primären Cluster abgebrochen. Die nächste nachfolgende Anweisung, die Sie übermitteln, empfängt einen Zeitüberschreitungsfehler. In diesem Fall rollt Aurora die Transaktion zurück.
Diese Art von Fehler kann in anderen Fällen auftreten, wenn die Schreibweiterleitung nicht mehr verfügbar ist. Beispielsweise bricht Aurora alle Transaktionen ab, die Schreibweiterleitung verwenden, wenn Sie den primären Cluster neu starten oder die Konfigurationseinstellung für die Schreibweiterleitung deaktivieren.
## Konfigurationsparameter für die Schreibweiterleitung in Aurora MySQL
Die Aurora-Cluster-Parametergruppen enthalten Einstellungen für die Schreibweiterleitung. Da es sich um Cluster-Parameter handelt, haben alle DB-Instances in allen Clustern die gleichen Werte für diese Variablen. Details zu diesen Parametern sind in der folgenden Tabelle zusammengefasst, mit Nutzungshinweisen unterhalb der Tabelle.
| Name | Scope | Typ | Standardwert | Zulässige Werte |
| --- | --- | --- | --- | --- |
| aurora\$1fwd\$1master\$1idle\$1timeout (Aurora-MySQL-Version 2) | Global | Ganzzahl ohne Vorzeichen | 60 | 1 – 86.400 |
| aurora\$1fwd\$1master\$1max\$1connections\$1pct (Aurora-MySQL-Version 2) | Global | Lange Ganzzahl ohne Vorzeichen | 10 | 0 – 90 |
| aurora\$1fwd\$1writer\$1idle\$1timeout (Aurora-MySQL-Version 3) | Global | Ganzzahl ohne Vorzeichen | 60 | 1 – 86.400 |
| aurora\$1fwd\$1writer\$1max\$1connections\$1pct (Aurora-MySQL-Version 3) | Global | Lange Ganzzahl ohne Vorzeichen | 10 | 0 – 90 |
| aurora\$1replica\$1read\$1consistency | Sitzung für Version 2 und Version 3 niedriger als 3.04, global für Version 3.04 und höher | Enum | '' (null) | EVENTUAL, SESSION, GLOBAL |
Um eingehende Schreibanforderungen aus sekundären Clustern zu steuern, verwenden Sie die folgenden Einstellungen auf dem primären Cluster:
+ `aurora_fwd_master_idle_timeout`, `aurora_fwd_writer_idle_timeout`: Die Anzahl der Sekunden, die der primäre Cluster auf Aktivität für eine Verbindung wartet, die aus einem sekundären Cluster weitergeleitet wird, bevor er sie schließt. Wenn die Sitzung über diesen Zeitraum hinaus im Leerlauf ist, bricht Aurora die Sitzung ab.
+ `aurora_fwd_master_max_connections_pct`, `aurora_fwd_writer_max_connections_pct`: Die obere Grenze für Datenbankverbindungen, die in einer Writer-DB-Instance für die Verarbeitung von Abfragen verwendet werden können, die von Lesern weitergeleitet werden. Sie wird als Prozentsatz der Einstellung `max_connections` für die Writer-DB-Instance im primären Cluster ausgedrückt. Wenn beispielsweise `max_connections` 800 ist und `aurora_fwd_master_max_connections_pct` oder `aurora_fwd_writer_max_connections_pct` 10 ist, lässt der Writer maximal 80 weitergeleitete Sitzungen gleichzeitig zu. Diese Verbindungen stammen aus demselben, von der Einstellung `max_connections` verwalteten Verbindungspool.
Diese Einstellung gilt nur für den primären Cluster, wenn für mindestens einen sekundären Cluster die Schreibweiterleitung aktiviert ist. Wenn Sie den Wert verringern, sind vorhandene Verbindungen nicht betroffen. Aurora berücksichtigt den neuen Wert der Einstellung, wenn versucht wird, eine neue Verbindung aus einem sekundären Cluster zu erstellen. Der Standardwert ist 10, was 10 % des Werts für `max_connections` entspricht. Wenn Sie die Abfrageweiterleitung für einen der sekundären Cluster aktivieren, muss diese Einstellung einen Wert ungleich Null haben, damit Schreiboperationen aus sekundären Clustern erfolgreich ausgeführt werden können. Wenn der Wert null ist, empfangen die Schreiboperationen den Fehlercode `ER_CON_COUNT_ERROR` mit der Meldung `Not enough connections on writer to handle your request`.
Der `aurora_replica_read_consistency`-Parameter aktiviert die Schreibweiterleitung. Sie benutzen ihn in jeder Sitzung. Sie können `EVENTUAL`, `SESSION` oder `GLOBAL` als Lesekonsistenzstufe angeben. Weitere Informationen über Konsistenzebenen finden Sie unter [Isolation und Konsistenz für die Schreibweiterleitung in Aurora MySQL](#aurora-global-database-write-forwarding-isolation-ams). Für diesen Parameter gelten die folgenden Regeln:
+ Der Standardwert ist '' (leer).
+ Die Schreibweiterleitung ist in einer Sitzung nur verfügbar, wenn `aurora_replica_read_consistency` auf `EVENTUAL`, `SESSION` oder `GLOBAL` festgelegt ist. Dieser Parameter ist nur in Reader-Instances sekundärer Cluster relevant, für die Schreibweiterleitung aktiviert ist und die sich in einer Aurora Global Database befinden.
+ Sie können diese Variable (wenn leer) oder nicht eingestellt (wenn sie bereits festgelegt ist) nicht innerhalb einer Multistatement-Transaktion setzen. Sie können sie jedoch während einer solchen Transaktion von einem gültigen Wert (`EVENTUAL`, `SESSION` oder `GLOBAL`) in einen anderen gültigen Wert (`EVENTUAL`, `SESSION` oder `GLOBAL`) ändern.
+ Die Variable darf nicht `SET` sein, wenn die Schreibweiterleitung auf dem sekundären Cluster nicht aktiviert ist.
## Amazon-CloudWatch-Metriken für die Schreibweiterleitung in Aurora MySQL
Die folgenden Amazon CloudWatch-Metriken gelten für den primären Cluster, wenn Sie die Schreibweiterleitung auf einem oder mehreren sekundären Clustern verwenden. Diese Metriken werden alle auf der Writer-DB-Instance im primären Cluster gemessen.
| CloudWatch-Metrik | Einheit | Beschreibung |
| --- | --- | --- |
| `AuroraDMLRejectedMasterFull` | Anzahl | Die Anzahl der weitergeleiteten Abfragen, die abgelehnt wurden, weil die Sitzung auf der Writer-DB-Instance ausgelastet ist Für Aurora-MySQL-Version 2. |
| `AuroraDMLRejectedWriterFull` | Anzahl | Die Anzahl der weitergeleiteten Abfragen, die abgelehnt wurden, weil die Sitzung auf der Writer-DB-Instance ausgelastet ist Für Aurora-MySQL-Version 3. |
| `ForwardingMasterDMLLatency` | Millisekunden | Durchschnittliche Zeit für die Verarbeitung jeder weitergeleiteten DML-Anweisung auf der Writer-DB-Instance. Nicht enthalten ist die Zeit, die der sekundäre Cluster benötigt, um die Schreibanforderung weiterzuleiten, oder die Zeit, um Änderungen zurück an den sekundären Cluster zu replizieren. Für Aurora-MySQL-Version 2. |
| `ForwardingMasterDMLThroughput` | Anzahl pro Sekunde | Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde von dieser Writer-DB-Instance verarbeitet werden. Für Aurora-MySQL-Version 2. |
| `ForwardingMasterOpenSessions` | Anzahl | Anzahl der weitergeleiteten Sitzungen auf der Writer-DB-Instance. Für Aurora-MySQL-Version 2. |
| `ForwardingWriterDMLLatency` | Millisekunden | Durchschnittliche Zeit für die Verarbeitung jeder weitergeleiteten DML-Anweisung auf der Writer-DB-Instance. Nicht enthalten ist die Zeit, die der sekundäre Cluster benötigt, um die Schreibanforderung weiterzuleiten, oder die Zeit, um Änderungen zurück an den sekundären Cluster zu replizieren. Für Aurora-MySQL-Version 3. |
| `ForwardingWriterDMLThroughput` | Anzahl pro Sekunde | Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde von dieser Writer-DB-Instance verarbeitet werden.Für Aurora-MySQL-Version 3. |
| `ForwardingWriterOpenSessions` | Anzahl | Anzahl der weitergeleiteten Sitzungen auf der Writer-DB-Instance.Für Aurora-MySQL-Version 3. |
Die folgenden CloudWatch-Metriken gelten für jeden sekundären Cluster. Diese Metriken werden auf jeder Reader-DB-Instance in einem sekundären Cluster mit aktivierter Schreibweiterleitung gemessen.
| CloudWatch-Metrik | Einheit | Beschreibung |
| --- | --- | --- |
| `ForwardingReplicaDMLLatency` | Millisekunden | Durchschnittliche Reaktionszeit weitergeleiteter DML-Anweisungen auf Replikaten. |
| `ForwardingReplicaDMLThroughput` | Anzahl pro Sekunde | Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde verarbeitet werden. |
| `ForwardingReplicaOpenSessions` | Anzahl | Die Anzahl der Sitzungen, die die Schreibweiterleitung für eine Reader-DB-Instance verwenden. |
| `ForwardingReplicaReadWaitLatency` | Millisekunden | Durchschnittliche Wartezeit, die eine `SELECT`-Anweisung in einer Reader-DB-Instance darauf wartet, zum primären Cluster aufzuholen. Der Grad, in dem die Reader-DB-Instance vor der Verarbeitung einer Abfrage wartet, ist von der Einstellung `aurora_replica_read_consistency` abhängig. |
| `ForwardingReplicaReadWaitThroughput` | Anzahl pro Sekunde | Gesamtzahl der pro Sekunde in allen Sitzungen verarbeiteten SELECT-Anweisungen, die Schreibvorgänge weiterleiten. |
| `ForwardingReplicaSelectLatency` | Millisekunden | Weitergeleitete SELECT-Latenz, Durchschnitt über alle weitergeleiteten SELECT-Anweisungen innerhalb des Überwachungszeitraums. |
| `ForwardingReplicaSelectThroughput` | Anzahl pro Sekunde | Weitergeleiteter SELECT-Durchsatz, pro Sekunde, als Durchschnitt innerhalb des Überwachungszeitraums. |
## Aurora-MySQL-Statusvariablen für die Schreibweiterleitung
Die folgenden Aurora-MySQL-Statusvariablen gelten für den primären Cluster, wenn Sie die Schreibweiterleitung auf einem oder mehreren sekundären Clustern verwenden. Diese Metriken werden alle auf der Writer-DB-Instance im primären Cluster gemessen.
| Aurora-MySQL-Statusvariable | Einheit | Beschreibung |
| --- | --- | --- |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Anzahl | Gesamtzahl der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden.Für Aurora-MySQL-Version 2. |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Mikrosekunden | Gesamtdauer der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Für Aurora-MySQL-Version 2. |
| Aurora\$1fwd\$1master\$1open\$1sessions | Anzahl | Anzahl der weitergeleiteten Sitzungen auf der Writer-DB-Instance. Für Aurora-MySQL-Version 2. |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Anzahl | Gesamtzahl der `SELECT`-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Für Aurora-MySQL-Version 2. |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Mikrosekunden | Gesamtdauer der `SELECT`-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Für Aurora-MySQL-Version 2. |
| Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count | Anzahl | Gesamtzahl der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden.Für Aurora-MySQL-Version 3. |
| Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration | Mikrosekunden | Gesamtdauer der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. |
| Aurora\$1fwd\$1writer\$1open\$1sessions | Anzahl | Anzahl der weitergeleiteten Sitzungen auf der Writer-DB-Instance.Für Aurora-MySQL-Version 3. |
| Aurora\$1fwd\$1writer\$1select\$1stmt\$1count | Anzahl | Gesamtzahl der `SELECT`-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden.Für Aurora-MySQL-Version 3. |
| Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration | Mikrosekunden | Gesamtdauer der `SELECT`-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Für Aurora-MySQL-Version 3. |
Die folgenden Aurora-MySQL-Statusvariablen gelten für jeden sekundären Cluster. Diese Metriken werden auf jeder Reader-DB-Instance in einem sekundären Cluster mit aktivierter Schreibweiterleitung gemessen.
| Aurora-MySQL-Statusvariable | Einheit | Beschreibung |
| --- | --- | --- |
| Aurora\$1fwd\$1replica\$1dml\$1stmt\$1count | Anzahl | Gesamtzahl der DML-Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
| Aurora\$1fwd\$1replica\$1dml\$1stmt\$1duration | Mikrosekunden | Gesamtdauer aller DML-Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
| Aurora\$1fwd\$1replica\$1errors\$1session\$1limit | Anzahl | Anzahl der Sitzungen, die vom primären Cluster aufgrund einer der folgenden Fehlerbedingungen zurückgewiesen wurden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding-ams.html) |
| Aurora\$1fwd\$1replica\$1open\$1sessions | Anzahl | Die Anzahl der Sitzungen, die die Schreibweiterleitung für eine Reader-DB-Instance verwenden. |
| Aurora\$1fwd\$1replica\$1read\$1wait\$1count | Anzahl | Gesamtzahl der Lesen-Nach-Schreiben-Wartezeiten auf dieser Reader-DB-Instance. |
| Aurora\$1fwd\$1replica\$1read\$1wait\$1duration | Mikrosekunden | Gesamtdauer der Wartezeiten aufgrund der Lesekonsistenzeinstellung auf dieser Reader-DB-Instance. |
| Aurora\$1fwd\$1replica\$1select\$1stmt\$1count | Anzahl | Gesamtzahl der SELECT-Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
| Aurora\$1fwd\$1replica\$1select\$1stmt\$1duration | Mikrosekunden | Gesamtdauer der SELECT-Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
# Verwenden der Schreibweiterleitung in einer globalen Aurora-PostgreSQL-Datenbank
**Topics**
+ [Region und Versionsverfügbarkeit der Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-regions-versions-apg)
+ [Aktivieren der Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-enabling-apg)
+ [Überprüfen auf die Aktivierung der Schreibweiterleitung für einen sekundären Cluster in Ausrora PostgreSQL](#aurora-global-database-write-forwarding-describing-apg)
+ [Anwendungs- und SQL-Kompatibilität mit Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-compatibility-apg)
+ [Isolation und Konsistenz für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-isolation-apg)
+ [Transaktionszugriffsmodi mit Schreibweiterleitung](#aurora-global-database-write-forwarding-txns)
+ [Ausführen von Multipart-Anweisungen mit Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-multipart-apg)
+ [Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg)
+ [CloudWatch Amazon-Metriken für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-cloudwatch-apg)
+ [Warte-Ereignisse für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-wait-events-apg)
## Region und Versionsverfügbarkeit der Schreibweiterleitung in Aurora PostgreSQL
Bei Aurora-PostgreSQL-Version 16 und höheren Hauptversionen wird die globale Schreibweiterleitung in allen Nebenversionen unterstützt. In früheren Versionen von Aurora PostgreSQL wird die globale Schreibweiterleitung ab Version 15.4 und höheren Nebenversionen sowie ab Version 14.9 und höheren Nebenversionen unterstützt. Die Schreibweiterleitung ist in jeder AWS Region verfügbar, in der Aurora PostgreSQL-basierte globale Datenbanken verfügbar sind.
Weitere Informationen zur Verfügbarkeit von Versionen und Regionen im Zusammenhang mit globalen Aurora-PostgreSQL-Datenbanken finden Sie unter [Globale Aurora-Datenbanken unterstützen Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.apg).
## Aktivieren der Schreibweiterleitung in Aurora PostgreSQL
Standardmäßig ist die Schreibweiterleitung nicht aktiviert, wenn Sie einen sekundären Cluster zu einer Aurora Global Database hinzufügen. Sie können die Schreibweiterleitung für Ihren sekundären DB-Cluster aktivieren, während Sie ihn erstellen oder jederzeit danach. Bei Bedarf können Sie es später deaktivieren. Das Aktivieren oder Deaktivieren der Schreibweiterleitung führt nicht zu Ausfallzeiten oder einem Neustart.
**Anmerkung**
Sie können die lokale Schreibweiterleitung für Ihre Anwendungen verwenden, die gelegentlich Schreibvorgänge durchführen und read-after-write Konsistenz erfordern, d. h. die Fähigkeit, den letzten Schreibvorgang in einer Transaktion zu lesen.
### Konsole
In der Konsole können Sie die Schreibweiterleitung aktivieren oder deaktivieren, wenn Sie einen sekundären DB-Cluster erstellen oder ändern.
#### Aktivierung oder Deaktivierung der Schreibweiterleitung bei der Erstellung eines sekundären DB-Clusters
Wenn Sie einen neuen sekundären DB-Cluster erstellen, aktivieren Sie die Schreibweiterleitung, indem Sie unter **Lesereplikat-Schreibweiterleitung** das Kontrollkästchen **Globale Schreibweiterleitung aktivieren** markieren. Oder entfernen Sie die Markierung in dem Kontrollkästchen, um das Feature zu deaktivieren. Befolgen Sie die Anweisungen für Ihre DB-Engine unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md), um einen sekundärem DB-Cluster zu erstellen.
Der folgende Screenshot zeigt den Abschnitt **Lesereplikat-Schreibweiterleitung**, bei dem das Kontrollkästchen **Globale Schreibweiterleitung aktivieren** markiert ist.
![\[\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-enable-write-forwarding.png)
#### Aktivierung oder Deaktivierung der Schreibweiterleitung bei der Änderung eines sekundären DB-Clusters
In der Konsole können Sie einen sekundären DB-Cluster ändern, um die Schreibweiterleitung zu aktivieren oder zu deaktivieren.
**So aktivieren oder deaktivieren Sie die Schreibweiterleitung für einen vorhandenen sekundären DB-Cluster mit der Konsole**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie **Datenbanken** aus.
1. Wählen Sie den sekundären DB-Cluster aus und klicken Sie dann auf **Ändern**.
1. Markieren oder löschen Sie im Abschnitt **Lesereplikat-Schreibweiterleitung** das Kontrollkästchen **Globale Schreibweiterleitung aktivieren**.
1. Klicken Sie auf **Weiter**.
1. Wählen Sie für **Einplanung von Änderungen** die Option **Sofort anwenden** aus. Wenn Sie **Während des nächsten geplanten Wartungsfensters anwenden** wählen, ignoriert Aurora diese Einstellung und aktiviert die Schreibweiterleitung sofort.
1. Wählen Sie **Cluster bearbeiten** aus.
### AWS CLI
Um die Schreibweiterleitung mithilfe von zu aktivieren AWS CLI, verwenden Sie die `--enable-global-write-forwarding` Option. Diese Option funktioniert, wenn Sie über den Befehl [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) einen neuen sekundären Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster über den Befehl [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) ändern. Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie die Option `--no-enable-global-write-forwarding` mit denselben CLI-Befehlen verwenden.
In den folgenden Verfahren wird beschrieben, wie Sie die Schreibweiterleitung für einen sekundären DB-Cluster in Ihrem globalen Cluster mithilfe von AWS CLI aktivieren oder deaktivieren.
**So aktivieren oder deaktivieren Sie die Schreibweiterleitung für einen vorhandenen sekundären DB-Cluster**
+ Rufen Sie den [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI Befehl auf und geben Sie die folgenden Werte ein:
+ `--db-cluster-identifier` – der Name des DB-Clusters.
+ `--enable-global-write-forwarding` zum Aktivieren oder `--no-enable-global-write-forwarding` zum Deaktivieren.
Das folgende Beispiel aktiviert die Schreibweiterleitung für den DB-Cluster `sample-secondary-db-cluster`.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-secondary-db-cluster \
--enable-global-write-forwarding
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-secondary-db-cluster ^
--enable-global-write-forwarding
```
### RDS-API
Um die Schreibweiterleitung über die Amazon-RDS-API zu aktivieren, legen Sie den Parameter `EnableGlobalWriteForwarding` auf `true` fest. Dieser Parameter funktioniert, wenn Sie mit der DBCluster Operation Create einen neuen sekundären Cluster [erstellen](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Er funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster mithilfe der DBCluster Operation [Modify ändern](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie den Parameter `EnableGlobalWriteForwarding` auf `false` festlegen.
## Überprüfen auf die Aktivierung der Schreibweiterleitung für einen sekundären Cluster in Ausrora PostgreSQL
Um festzustellen, ob Sie die Schreibweiterleitung aus einem sekundären Cluster verwenden können, können Sie prüfen, ob der Cluster das Attribut besitz `"GlobalWriteForwardingStatus": "enabled"`.
In der AWS-Managementkonsole sehen Sie `Read replica write forwarding` auf der Registerkarte **Konfiguration** der Detailseite für den Cluster. Führen Sie den folgenden AWS CLI Befehl aus, um den Status der Einstellung für die globale Schreibweiterleitung für alle Ihre Cluster zu überprüfen.
Ein sekundärer Cluster zeigt die Werte `"enabled"` oder `"disabled"` an, um anzugeben, ob die Schreibweiterleitung aktiviert oder deaktiviert ist. Der Wert `null` gibt an, dass die Schreibweiterleitung für diesen Cluster nicht verfügbar ist. Entweder ist der Cluster nicht Teil einer globalen Datenbank oder ist der primäre Cluster und nicht kein sekundärer Cluster. Der Wert kann auch `"enabling"` oder `"disabling"` sein, wenn die Schreibweiterleitung gerade aktiviert oder deaktiviert wird.
**Example**
```
aws rds describe-db-clusters --query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'
[
{
"GlobalWriteForwardingStatus": "enabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
},
{
"GlobalWriteForwardingStatus": "disabled",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
},
{
"GlobalWriteForwardingStatus": null,
"DBClusterIdentifier": "non-global-cluster"
}
]
```
Führen Sie den folgenden Befehl aus, um alle sekundären Cluster zu suchen, für die eine globale Schreibweiterleitung aktiviert ist. Dieser Befehl gibt auch den Reader-Endpunkt des Clusters aus. Sie verwenden den Reader-Endpunkt des sekundären Clusters, wenn Sie die Schreibweiterleitung vom sekundären zum primären Cluster in Ihrer globalen Aurora-Datenbank verwenden.
**Example**
```
aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
{
"GlobalWriteForwardingStatus": "enabled",
"ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
"DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
}
]
```
## Anwendungs- und SQL-Kompatibilität mit Schreibweiterleitung in Aurora PostgreSQL
Bestimmte Anweisungen sind nicht zulässig oder können veraltete Ergebnisse erzeugen, wenn Sie sie in einer globalen Datenbank mit Schreibweiterleitung verwenden. Darüber hinaus werden benutzerdefinierte Funktionen und benutzerdefinierte Prozeduren nicht unterstützt. Daher ist die Einstellung `EnableGlobalWriteForwarding` für sekundäre Cluster standardmäßig deaktiviert. Stellen Sie vor einer Aktivierung sicher, dass der Anwendungscode von keiner dieser Einschränkungen betroffen ist.
Sie können die folgenden Arten von SQL-Anweisungen mit Schreibweiterleitung verwenden:
+ Data Manipulation Language (DML)-Anweisungen wie `INSERT`, `DELETE` und `UPDATE`.
+ `SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }`-Anweisungen.
+ `PREPARE`- und `EXECUTE`-Anweisungen.
+ `EXPLAIN`-Anweisungen mit den Anweisungen in dieser Liste
Die folgenden Arten von SQL-Anweisungen werden bei Schreibweiterleitung nicht unterstützt:
+ DDL-Anweisungen (Data Definition Language)
+ `ANALYZE`
+ `CLUSTER`
+ `COPY`
+ Cursor – Cursors werden nicht unterstützt. Stellen Sie daher sicher, dass Sie sie schließen, bevor Sie die Schreibweiterleitung verwenden.
+ `GRANT`\$1`REVOKE`\$1`REASSIGN OWNED`\$1`SECURITY LABEL`
+ `LOCK`
+ `SAVEPOINT`-Anweisungen.
+ `SELECT INTO`
+ `SET CONSTRAINTS`
+ `TRUNCATE`
+ `VACUUM`
## Isolation und Konsistenz für die Schreibweiterleitung in Aurora PostgreSQL
In Sitzungen, die Schreibweiterleitung verwenden, können Sie nur die Isolationsstufen `REPEATABLE READ` und `READ COMMITTED` verwenden. Die `SERIALIZABLE`-Isolationsstufe wird jedoch nicht unterstützt.
Sie können den Grad der Lesekonsistenz in einem sekundären Cluster steuern. Die Lesekonsistenzstufe legt fest, wie viel Wartezeit der sekundäre Cluster vor jeder Leseoperation ausführt, um sicherzustellen, dass einige oder alle Änderungen aus dem primären Cluster repliziert werden. Sie können die Lesekonsistenzstufe anpassen, um sicherzustellen, dass alle aus Ihrer Sitzung weitergeleiteten Schreiboperationen im sekundären Cluster vor nachfolgenden Abfragen angezeigt werden. Sie können diese Einstellung auch verwenden, um sicherzustellen, dass Abfragen auf dem sekundären Cluster stets die aktuellsten Updates des primären Clusters angezeigt werden. Dies gilt auch für diejenigen, die von anderen Sitzungen oder anderen Clustern übermittelt wurden. Um diese Art von Verhalten für Ihre Anwendung anzugeben, wählen Sie den entsprechenden Wert für den `apg_write_forward.consistency_mode`-Parameter aus. Der Parameter `apg_write_forward.consistency_mode` wirkt sich nur auf sekundäre Cluster aus, in denen die Schreibweiterleitung aktiviert ist.
**Anmerkung**
Für den Parameter `apg_write_forward.consistency_mode` können Sie die Werte `SESSION`, `EVENTUAL`, `GLOBAL` oder `OFF` angeben. Standardmäßig ist der Wert auf `SESSION` festgelegt. Wenn Sie den Wert auf `OFF` festlegen, wird die Schreibweiterleitung in der Sitzung deaktiviert.
Wenn Sie den Konsistenzgrad erhöhen, verbringt Ihre Anwendung mehr Zeit damit, darauf zu warten, dass Änderungen zwischen den AWS Regionen übertragen werden. Sie können das Verhältnis zwischen schneller Reaktionszeit und der Gewährleistung festlegen, dass vor der Ausführung Ihrer Abfragen Änderungen an anderen Speicherorten vollständig verfügbar sind.
Bei jeder verfügbaren Konsistenzmodus-Einstellung hat dies folgende Auswirkungen:
+ `SESSION`— Bei allen Abfragen in einer sekundären AWS Region, die Schreibweiterleitung verwendet, werden die Ergebnisse aller in dieser Sitzung vorgenommenen Änderungen angezeigt. Die Änderungen werden unabhängig davon angezeigt, ob die Transaktion übergeben wurde. Wenn notwendig, wartet die Abfrage auf die Replikation der Ergebnisse weitergeleiteter Schreiboperationen zur aktuellen Region. Sie wartet nicht auf aktualisierte Ergebnisse aus Schreiboperationen, die in anderen Regionen oder in anderen Sitzungen innerhalb der aktuellen Region ausgeführt werden.
+ `EVENTUAL`— Bei Abfragen in einer sekundären AWS Region, die Schreibweiterleitung verwendet, können Daten angezeigt werden, die aufgrund von Replikationsverzögerungen leicht veraltet sind. Ergebnisse von Schreiboperationen in derselben Sitzung werden erst angezeigt, wenn die Schreiboperation in der primären Region ausgeführt und zur aktuellen Region repliziert wird. Die Abfrage wartet nicht, bis die aktualisierten Ergebnisse verfügbar sind. Daher könnte sie die älteren Daten oder die aktualisierten Daten abrufen, abhängig vom Zeitpunkt der Anweisungen und der Größe der Replikationsverzögerung.
+ `GLOBAL`— Bei einer Sitzung in einer sekundären AWS Region werden Änderungen vorgenommen, die durch diese Sitzung vorgenommen wurden. Außerdem werden alle vorgenommenen Änderungen sowohl aus der primären AWS Region als auch aus anderen sekundären AWS Regionen angezeigt. Jede Abfrage kann für einen bestimmten Zeitraum warten, abhängig von der Sitzungsverzögerung. Die Abfrage wird fortgesetzt, wenn der sekundäre Cluster zu up-to-date dem Zeitpunkt, zu dem die Abfrage gestartet wurde, alle zugeschriebenen Daten aus dem primären Cluster enthält.
+ `OFF` – Die Schreibweiterleitung ist in der Sitzung deaktiviert.
Weitere Informationen zu allen mit der Schreibweiterleitung verbundenen Parametern finden Sie unter [Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg).
## Transaktionszugriffsmodi mit Schreibweiterleitung
Wenn der Transaktionszugriffsmodus schreibgeschützt ist, wird die Schreibweiterleitung nicht verwendet. Sie können den Zugriffsmodus nur dann auf Lese- und Schreibzugriff festlegen, wenn Sie mit einem DB-Cluster und einer Sitzung verbunden sind, in der die lokale Schreibweiterleitung aktiviert ist.
Weitere Informationen zu den Transaktionszugriffsmodi finden Sie unter [SET TRANSACTION](https://www.postgresql.org/docs/current/sql-set-transaction.html).
## Ausführen von Multipart-Anweisungen mit Schreibweiterleitung in Aurora PostgreSQL
Eine DML-Anweisung kann aus mehreren Teilen bestehen, z. B. einer `INSERT ... SELECT`-Anweisung oder einer `DELETE ... WHERE`-Anweisung. In diesem Fall wird die gesamte Anweisung an den primären Cluster weitergeleitet und dort ausgeführt.
## Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL
Die Aurora-Cluster-Parametergruppen enthalten Einstellungen für die Schreibweiterleitung. Da es sich um Cluster-Parameter handelt, haben alle DB-Instances in allen Clustern die gleichen Werte für diese Variablen. Details zu diesen Parametern sind in der folgenden Tabelle zusammengefasst, mit Nutzungshinweisen unterhalb der Tabelle.
| Name | Scope | Typ | Standardwert | Zulässige Werte |
| --- | --- | --- | --- | --- |
| apg\$1write\$1forward.connect\$1timeout | Sitzung | Sekunden | 30 | 0 – 2147483647 |
| apg\$1write\$1forward.consistency\$1mode | Sitzung | enum | Sitzung | SESSION, EVENTUAL, GLOBAL, OFF |
| apg\$1write\$1forward.idle\$1in\$1transaction\$1session\$1timeout | Sitzung | Millisekunden | 86400000 | 0 – 2147483647 |
| apg\$1write\$1forward.idle\$1session\$1timeout | Sitzung | Millisekunden | 300000 | 0 – 2147483647 |
| apg\$1write\$1forward.max\$1forwarding\$1connections\$1percent | Global | int | 25 | 1-100 |
Der `apg_write_forward.max_forwarding_connections_percent`-Parameter definiert die Obergrenze der Datenbankverbindungsslots, die zum Umgang mit von Readern weitergeleiteten Abfragen verwendet werden können. Er wird als Prozentsatz der Einstellung `max_connections` für die Writer-DB-Instance im primären Cluster ausgedrückt. Wenn beispielsweise `max_connections` `800` und `apg_write_forward.max_forwarding_connections_percent` `10` ist, dann lässt der Writer maximal 80 weitergeleitete Sitzungen gleichzeitig zu. Diese Verbindungen stammen aus demselben, von der Einstellung `max_connections` verwalteten Verbindungspool. Diese Einstellung gilt nur für den primären Cluster, wenn für mindestens einen sekundären Cluster die Schreibweiterleitung aktiviert ist.
Verwenden Sie die folgenden Einstellungen auf dem sekundären Cluster:
+ `apg_write_forward.consistency_mode` – Ein Parameter auf Sitzungsebene, der den Grad der Lesekonsistenz auf dem sekundären Cluster steuert. Gültige Werte sind `SESSION`, `EVENTUAL`, `GLOBAL` oder `OFF`. Standardmäßig ist der Wert auf `SESSION` festgelegt. Wenn Sie den Wert auf `OFF` festlegen, wird die Schreibweiterleitung in der Sitzung deaktiviert. Weitere Informationen über Konsistenzebenen finden Sie unter [Isolation und Konsistenz für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-isolation-apg). Dieser Parameter ist nur in Reader-Instances sekundärer Cluster relevant, für die Schreibweiterleitung aktiviert ist und die sich in einer Aurora Global Database befinden.
+ `apg_write_forward.connect_timeout` – Die maximale Anzahl von Sekunden, die der sekundäre Cluster beim Herstellen einer Verbindung zum primären Cluster wartet, bevor er aufgibt. Ein Wert von `0` bedeutet, dass auf unbestimmte Zeit gewartet werden soll.
+ `apg_write_forward.idle_in_transaction_session_timeout` – Die Anzahl der Millisekunden, die der primäre Cluster auf Aktivität für eine Verbindung wartet, die aus einem sekundären Cluster mit einer offenen Transaktion weitergeleitet wird, bevor er sie schließt. Wenn die Sitzung über diesen Zeitraum hinaus inaktiv ist, bricht Aurora die Sitzung ab. Durch einen Wert des Typs `0` wird der Timout deaktiviert.
+ `apg_write_forward.idle_session_timeout` – Die Anzahl der Millisekunden, die der primäre Cluster auf Aktivität für eine Verbindung wartet, die aus einem sekundären Cluster weitergeleitet wird, bevor er sie schließt. Wenn die Sitzung über diesen Zeitraum hinaus inaktiv bleibt, beendet Aurora die Sitzung. Durch einen Wert des Typs `0` wird der Timout deaktiviert.
## CloudWatch Amazon-Metriken für die Schreibweiterleitung in Aurora PostgreSQL
Die folgenden CloudWatch Amazon-Metriken gelten für den primären Cluster, wenn Sie die Schreibweiterleitung auf einem oder mehreren sekundären Clustern verwenden. Diese Metriken werden alle auf der Writer-DB-Instance im primären Cluster gemessen.
| CloudWatch Metrik | Einheiten und Beschreibung |
| --- | --- |
| `AuroraForwardingWriterDMLThroughput` | Anzahl pro Sekunde Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde von dieser Writer-DB-Instance verarbeitet werden. |
| `AuroraForwardingWriterOpenSessions` | Anzahl Anzahl der offenen Sitzungen auf dieser Writer-DB-Instance, die weitergeleitete Anfragen verarbeiten. |
| `AuroraForwardingWriterTotalSessions` | Anzahl Anzahl der weitergeleiteten Sitzungen auf dieser Writer-DB-Instance. |
Die folgenden CloudWatch Metriken gelten für jeden sekundären Cluster. Diese Metriken werden auf jeder Reader-DB-Instance in einem sekundären Cluster mit aktivierter Schreibweiterleitung gemessen.
| CloudWatch Metrik | Einheit und Beschreibung |
| --- | --- |
| `AuroraForwardingReplicaCommitThroughput` | Anzahl pro Sekunde Anzahl der Commits in Sitzungen, die von diesem Replikat pro Sekunde weitergeleitet werden. |
| `AuroraForwardingReplicaDMLLatency` | Millisekunden Durchschnittliche Antwortzeit in Millisekunden bei der Weiterleitung DMLs auf dem Replikat. |
| `AuroraForwardingReplicaDMLThroughput` | Anzahl pro Sekunde Anzahl der weitergeleiteten DML-Anweisungen, die in diesem Replikat pro Sekunde verarbeitet werden. |
| `AuroraForwardingReplicaErrorSessionsLimit` | Anzahl Anzahl der Sitzungen, die vom primären Cluster zurückgewiesen wurden, weil das Limit für die maximale Zahl von Verbindungen oder die maximale Schreibweiterleitung erreicht wurde. |
| `AuroraForwardingReplicaOpenSessions` | Anzahl Die Anzahl der Sitzungen, die die Schreibweiterleitung für eine Replikat-Instance verwenden. |
| `AuroraForwardingReplicaReadWaitLatency` | Millisekunden Durchschnittliche Wartezeit in Millisekunden, die das Replikat darauf wartet, mit der LSN des primären Clusters konsistent zu sein. Das Ausmaß, in dem die Reader-DB-Instance vor der Verarbeitung einer Abfrage wartet, ist von der Einstellung apg\$1write\$1forward.consistency\$1mode abhängig. Weitere Informationen zu dieser Einstellung finden Sie unter [Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg). |
## Warte-Ereignisse für die Schreibweiterleitung in Aurora PostgreSQL
Amazon Aurora generiert die folgenden Warteereignisse, wenn Sie die Schreibweiterleitung mit Aurora PostgreSQL verwenden.
**Topics**
+ [IPC: AuroraWriteForwardConnect](#apg-waits.ipcaurorawriteforwardconnect)
+ [IPC: AuroraWriteForwardConsistencyPoint](#apg-waits.ipcaurorawriteforwardconsistencypoint)
+ [IPC: AuroraWriteForwardExecute](#apg-waits.ipc:aurorawriteforwardexecute)
+ [IPC: AuroraWriteForwardGetGlobalConsistencyPoint](#apg-waits.ipc:aurorawriteforwardgetglobalconsistencypoint)
+ [IPC: AuroraWriteForwardXactAbort](#apg-waits.ipc:aurorawriteforwardxactabort)
+ [IPC: AuroraWriteForwardXactCommit](#apg-waits.ipc:aurorawriteforwardxactcommit)
+ [IPC: AuroraWriteForwardXactStart](#apg-waits.ipc:aurorawriteforwardxactstart)
### IPC: AuroraWriteForwardConnect
Das `IPC:AuroraWriteForwardConnect`-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster darauf wartet, dass eine Verbindung zum Writer-Knoten des primären DB-Clusters geöffnet wird.
**Wahrscheinliche Ursachen für erhöhte Wartezeiten**
Dieses Ereignis nimmt zu, wenn die Anzahl der Verbindungsversuche vom Leseknoten einer sekundären Region zum Writer-Knoten des primären DB-Clusters zunimmt.
**Aktionen**
Reduzieren Sie die Anzahl gleichzeitiger Verbindungen von einem sekundären Knoten zum Writer-Knoten der primären Region.
### IPC: AuroraWriteForwardConsistencyPoint
Das `IPC:AuroraWriteForwardConsistencyPoint`-Ereignis beschreibt, wie lange eine Abfrage von einem Knoten im sekundären-DB-Cluster darauf wartet, dass die Ergebnisse weitergeleiteter Schreiboperationen in die aktuelle Region repliziert werden. Dieses Ereignis wird nur generiert, wenn der Parameter `apg_write_forward.consistency_mode` auf Sitzungsebene auf einen der folgenden Werte gesetzt ist:
+ `SESSION` – Abfragen auf einem sekundären Knoten warten auf die Ergebnisse aller in dieser Sitzung ausgeführten Änderungen.
+ `GLOBAL` – Abfragen auf einem sekundären Knoten warten auf die Ergebnisse der in dieser Sitzung vorgenommenen Änderungen sowie auf alle festgeschriebenen Änderungen sowohl aus der primären Region als auch aus anderen sekundären Regionen im globalen Cluster.
Informationen zum Einstellen des Parameters `apg_write_forward.consistency_mode` finden Sie unter [Konfigurationsparameter für die Schreibweiterleitung in Aurora PostgreSQL](#aurora-global-database-write-forwarding-params-apg).
**Wahrscheinliche Ursachen für erhöhte Wartezeiten**
Zu den häufigsten Ursachen für längere Wartezeiten gehören:
+ Erhöhte Replikatverzögerung, gemessen anhand der CloudWatch `ReplicaLag` Amazon-Metrik. Weitere Informationen zu dieser Metrik finden Sie unter [Überwachung einer Aurora PostgreSQL-Replikation](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Monitoring).
+ Erhöhte Last auf dem Writer-Knoten der primären Region oder auf dem sekundären Knoten.
**Aktionen**
Ändern Sie Ihren Konsistenzmodus je nach den Anforderungen Ihrer Anwendung.
### IPC: AuroraWriteForwardExecute
Das `IPC:AuroraWriteForwardExecute`-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster darauf wartet, dass eine weitergeleitete Abfrage abgeschlossen wird und Ergebnisse vom Writer-Knoten des primären DB-Clusters abgerufen werden.
**Wahrscheinliche Ursachen für erhöhte Wartezeiten**
Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:
+ Abrufen einer großen Zahl von Zeilen aus dem Writer-Knoten der primären Region.
+ Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.
+ Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.
+ Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.
**Aktionen**
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
+ Optimieren Sie Abfragen, um nur die erforderlichen Daten abzurufen.
+ Optimieren Sie DML-Operationen (Data Manipulation Language), um nur die erforderlichen Daten zu ändern.
+ Wenn der sekundäre Knoten oder der Writer-Knoten der primären Region durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.
### IPC: AuroraWriteForwardGetGlobalConsistencyPoint
Das `IPC:AuroraWriteForwardGetGlobalConsistencyPoint`-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster, der den Konsistenzmodus GLOBAL verwendet, darauf wartet, den globalen Konsistenzpunkt vom Writer-Knoten zu erhalten, bevor er eine Abfrage ausführt.
**Wahrscheinliche Ursachen für erhöhte Wartezeiten**
Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:
+ Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.
+ Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.
+ Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.
**Aktionen**
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
+ Ändern Sie Ihren Konsistenzmodus je nach den Anforderungen Ihrer Anwendung.
+ Wenn der sekundäre Knoten oder der Writer-Knoten der primären Region durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.
### IPC: AuroraWriteForwardXactAbort
Das `IPC:AuroraWriteForwardXactAbort`-Ereignis tritt ein, wenn ein Back-End-Prozess auf dem sekundären DB-Cluster auf das Ergebnis einer Remote-Bereinigungsabfrage wartet. Bereinigungsabfragen werden ausgegeben, um den Prozess nach dem Abbruch einer per Schreibweiterleitung weitergeleiteten Transaktion wieder in den entsprechenden Zustand zu versetzen. Amazon Aurora führt diese entweder aus, weil ein Fehler gefunden wurde oder weil ein Benutzer einen expliziten `ABORT`-Befehl ausgegeben oder eine laufende Abfrage abgebrochen hat.
**Wahrscheinliche Ursachen für erhöhte Wartezeiten**
Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:
+ Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.
+ Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Bereinigungsabfrage-Anforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.
+ Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.
**Aktionen**
Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen.
+ Untersuchen Sie die Ursache für die abgebrochene Transaktion.
+ Wenn der sekundäre Knoten oder der Writer-Knoten der primären Region durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.
### IPC: AuroraWriteForwardXactCommit
Das `IPC:AuroraWriteForwardXactCommit`-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster auf das Ergebnis eines weitergeleiteten Commit-Transaktionsbefehls wartet.
**Wahrscheinliche Ursachen für erhöhte Wartezeiten**
Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:
+ Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.
+ Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.
+ Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.
**Aktionen**
Wenn der sekundäre Knoten oder der Writer-Knoten der primären Region durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.
### IPC: AuroraWriteForwardXactStart
Das `IPC:AuroraWriteForwardXactStart`-Ereignis tritt ein, wenn ein Backend-Prozess auf dem sekundären DB-Cluster auf das Ergebnis eines weitergeleiteten Transaktionsstartbefehls wartet.
**Wahrscheinliche Ursachen für erhöhte Wartezeiten**
Zu den häufigsten Ursachen für längere Wartezeiten zählen auch die Folgenden:
+ Eine erhöhte Netzwerklatenz zwischen dem sekundären Knoten und dem Writer-Knoten der primären Region erhöht die Zeit, die der sekundäre Knoten benötigt, um Daten vom Writer-Knoten zu empfangen.
+ Eine erhöhte Belastung des sekundären Knotens kann die Übertragung der Abfrageanforderung vom sekundären Knoten zum Writer-Knoten der primären Region verzögern.
+ Eine erhöhte Belastung des Writer-Knotens der primären Region kann die Übertragung der Daten vom Writer-Knoten zum sekundären Knoten verzögern.
**Aktionen**
Wenn der sekundäre Knoten oder der Writer-Knoten der primären Region durch die CPU- oder Netzwerkbandbreite eingeschränkt ist, sollten Sie erwägen, ihn auf einen Instance-Typ mit mehr CPU-Kapazität oder mehr Netzwerkbandbreite umzustellen.
# Verwenden von Umstellung oder Failover in Amazon Aurora Global Database
Die Funktion von Aurora Global Database bietet einen höheren Business Continuity und Disaster Recovery (BCDR)-Schutz als die standardmäßige [Hochverfügbarkeit](Concepts.AuroraHighAvailability.md), die von einem Aurora-DB-Cluster in einer einzelnen AWS-Region bereitgestellt wird. Mithilfe von Aurora Global Database können Sie für eine schnellere Wiederherstellung nach raren, nicht geplanten regionalen Notfällen planen oder vollständige Service-Level-Ausfälle schnell beheben.
Sie können die folgenden Anleitungen und Verfahren nutzen, um Ihre BCDR-Strategie mit der Funktion von Aurora Global Database zu planen, zu testen und zu implementieren.
**Topics**
+ [Planen in Bezug auf Business Continuity und Disaster Recovery](#aurora-global-database-bcdr-planning)
+ [Durchführen von Umstellungen für Amazon Aurora Global Databases](#aurora-global-database-disaster-recovery.managed-failover)
+ [Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall](#aurora-global-database-failover)
+ [Verwalten von RPOs für Aurora PostgreSQL–basierte globale Datenbanken](#aurora-global-database-manage-recovery)
+ [Regionsübergreifende Resilienz für sekundäre Cluster globaler Datenbanken](aurora-global-database-secondary-availability.md)
## Planen in Bezug auf Business Continuity und Disaster Recovery
Um Ihre BCDR-Strategie zu planen, sollten Sie die folgende branchenspezifische Terminologie kennen und wissen, wie diese Begriffe im Zusammenhang mit den Funktionen von Aurora Global Database zu verstehen sind.
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. Bei Aurora Global Database 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](#aurora-global-database-manage-recovery).
Die Durchführung einer Umstellung oder eines 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:
+ **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 Replikation der globalen Aurora-Datenbank über die AWS-Regionen zum Zeitpunkt des Ausfalls ab. Weitere Informationen hierzu finden Sie unter [Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall](#aurora-global-database-failover).
+ **Umstellung** – Dieser Vorgang wurde zuvor als „verwaltetes geplantes Failover“ bezeichnet. Verwenden Sie diesen Ansatz für kontrollierte Szenarien, z. B. für die betriebliche Wartung und andere geplante betriebliche Verfahren, bei denen alle Aurora-Cluster und andere Services, mit denen sie interagieren, in einem fehlerfreien Zustand sind. 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](#aurora-global-database-disaster-recovery.managed-failover).
**Anmerkung**
Vor einer Umstellung auf einen sekundären Headless-DB-Cluster von Aurora bzw. vor einem Failover zu diesem müssen Sie ihm 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](aurora-global-database-attach.console.headless.md).
## Durchführen von Umstellungen für Amazon Aurora Global Databases
**Anmerkung**
Umstellungen wurden früher als **verwaltete geplante Failover** bezeichnet.
Mithilfe von Umstellungen 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 Wartungen 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 regionsübergreifende „Follow-the-Sun“-Anwendungen. 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 Methode ohne Datenverlust, um nach einem Failover zur ursprünglichen Primärregion zurückzukehren.
**Anmerkung**
Umstellungen sind für die Verwendung bei einer globalen Aurora-Datenbank konzipiert, bei der sich alle Aurora-Cluster sowie andere Services, mit denen sie agieren, in einem fehlerfreien Zustand befinden. Folgen Sie zur Wiederherstellung nach einem ungeplanten Ausfall dem entsprechenden Verfahren unter [Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall](#aurora-global-database-failover).
Sie können verwaltete regionsübergreifende Umstellungen mit Aurora Global Database nur durchführen, wenn die primären und sekundären DB-Cluster dieselben Engine-Haupt- und Nebenversionen haben. Je nach Engine und Engine-Versionen müssen die Patch-Level möglicherweise identisch sein oder können unterschiedlich sein. Eine Liste der Engines und Engine-Versionen, die diese Operationen zwischen primären und sekundären Clustern mit unterschiedlichen Patch-Leveln unterstützen, finden Sie unter [Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failover](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility). 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 macht Aurora den Cluster in der von Ihnen ausgewählten sekundären Region zu Ihrem primären Cluster. Der Umstellungsmechanismus behält die bestehende Replikationstopologie Ihrer globalen Datenbank bei: Sie hat immer noch dieselbe Anzahl von Aurora-Clustern in denselben Regionen. Ehe der Umstellungsprozess gestartet wird, wartet Aurora darauf, das alle Ziel-Cluster der sekundären Region vollständig mit dem Cluster der primären Region synchronisiert sind. Dann ist der DB-Cluster in der primären Region schreibgeschützt. Der gewählte sekundäre Cluster stuft einen seiner schreibgeschützten Knoten auf den Status eines vollständigen Writers hoch, sodass der sekundäre Cluster die Rolle des primären Clusters übernehmen kann. Da der sekundäre Ziel-Cluster zu Beginn des Prozesses mit dem primären Cluster synchronisiert wurde, 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.
**Anmerkung**
Informationen zur Verwaltung von Replikations-Slots für Aurora PostgreSQL nach einer Umstellung finden Sie unter [Verwalten logischer Slots für Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots).
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.
+ Überprüfen Sie die Verzögerungszeiten für alle sekundären Aurora-DB-Cluster in der globalen Aurora-Datenbank. Verwenden Sie 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 Amazon CloudWatch, um die `AuroraGlobalDBRPOLag`-Metrik für alle sekundären DB-Cluster anzuzeigen. 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. Wenn Sie diese Metriken untersuchen, sollten Sie beim aktuellen primären Cluster beginnen.
Weitere Informationen zu den CloudWatch-Metriken für Aurora finden Sie unter [Metriken auf Cluster-Ebene für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters).
+ Der sekundäre DB-Cluster, der während einer Umstellung hochgestuft wird, hat möglicherweise andere Konfigurationseinstellungen als der alte primäre DB-Cluster. Wir empfehlen, dass Sie die folgenden Arten von Konfigurationseinstellungen für alle Cluster in Ihren globalen Aurora-DB-Clustern konsistent halten. Auf diese Weise können Leistungsprobleme, Workload-Inkompatibilitäten und anderes anomales Verhalten nach einer Umstellung minimiert werden.
+ **Konfigurieren einer Parametergruppe für Aurora-DB-Cluster für die neue primäre Version, falls erforderlich** – Wenn Sie 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](aurora-global-database-modifying.parameters.md).
+ **Konfigurieren Sie Überwachungstools und -optionen wie Amazon CloudWatch Events und Alarme** – Konfigurieren Sie den hochgestuften DB-Cluster mit den gleichen Protokollierungsfunktionen, Alarmen usw. wie für die globale Datenbank erforderlich. 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-Cluster und zur Überwachung finden Sie unter [Überwachung von Amazon Aurora Aurora-Metriken mit Amazon CloudWatch](monitoring-cloudwatch.md).
+ **Konfigurieren Sie Integrationen mit anderen AWS-Services** – Wenn Ihre globale Aurora-Datenbank mit AWS-Services wie AWS Secrets Manager, AWS Identity and Access Management, Amazon S3 und AWS Lambda integriert ist, müssen Sie sicherstellen, dass diese bedarfsgerecht konfiguriert sind. Weitere Informationen zur Integration globaler Aurora-Datenbanken in IAM, Amazon S3 und Lambda finden Sie unter [Verwendung der globalen Amazon Aurora Aurora-Datenbanken mit anderen AWS Diensten](aurora-global-database-interop.md). Weitere Informationen zu Secrets Manager finden Sie unter [So automatisieren Sie die Replikation von Secrets in AWS Secrets Manager über verschiedene AWS-Regionen hinweg](https://aws.amazon.com/blogs/security/how-to-automate-replication-of-secrets-in-aws-secrets-manager-across-aws-regions/).
Wenn Sie den Writer-Endpunkt von Aurora Global Database 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 der Cluster-Endpunkt des neuen primären Clusters verwendet wird. 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.
Stellen Sie, wenn Sie RDS-Proxy verwenden, 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](rds-proxy-gdb.md#rds-proxy-gdb.endpoints).
Sie können eine Umstellung einer globalen Aurora-Datenbank mit der AWS-Managementkonsole, der AWS CLI oder der RDS-API durchführen.
### Konsole
**So führen Sie eine Umstellung in Ihrer Aurora Global Database durch**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie **Datenbanken** aus und suchen Sie die globale Aurora-Datenbank, für die Sie eine Umstellung ausführen möchten.
1. Wählen Sie im Menü **Aktionen** die Option **Failover für globale Datenbank ausführen** aus.
![\[Anzeige der Datenbankliste mit geöffnetem Aktionsmenü, das die Option „Umschalten oder Failover der globalen Datenbank“ zeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-1.png)
1. Wählen Sie **Umschaltung**.
![\[Das Dialogfeld Umschalten oder Failover der globalen Datenbank, mit aktivierter Option Failover (Datenverlust zulassen).\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-2.png)
1. 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.
1. 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.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-switchover-3.png)
### AWS CLI
**So führen Sie eine Umstellung auf einer Aurora Global Database durch**
Verwenden Sie den CLI-Befehl `[switchover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-global-cluster.html)`, um eine Umstellung für Aurora Global Database auszuführen. Mit dem Befehl können Sie Werte für die folgenden Parameter übertragen.
+ `--region` – Geben Sie die AWS-Region an, in der der primäre DB-Cluster der globalen Aurora-Datenbank 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 primäres Cluster für die globale Aurora-Datenbank hochstufen möchten.
Für Linux, macOS oder Unix:
```
aws rds --region region_of_primary \
switchover-global-cluster --global-cluster-identifier global_database_id \
--target-db-cluster-identifier arn_of_secondary_to_promote
```
Für 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
```
### RDS-API
Um eine Umstellung für Aurora Global Database durchzuführen, führen Sie die API-Operation [SwitchoverGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverGlobalCluster.html) aus.
## Wiederherstellen einer globalen Amazon Aurora-Datenbank nach einem ungeplanten Ausfall
In sehr seltenen Fällen kann es bei 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.
Aurora Global Database bietet zwei Failover-Methoden, die Sie in einer Notfallwiederherstellungssituation verwenden können:
+ 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](#aurora-global-database-failover.managed-unplanned).
+ 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](#aurora-global-database-failover.manual-unplanned).
**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. Bei einem Failover kann es auch zu *Split-Brain*-Problemen kommen.
### 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.
Bei einem verwalteten Failover wird der sekundäre Cluster in Ihrer 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 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.
**Anmerkung**
Informationen zur Verwaltung von Replikations-Slots für Aurora PostgreSQL nach einem Failover finden Sie unter [Verwalten logischer Slots für Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots).
**Anmerkung**
Sie können verwaltete regionsübergreifende Failover mit Aurora Global Database nur durchführen, wenn die primären und sekundären DB-Cluster dieselben Engine-Haupt- und Nebenversionen haben. Je nach Engine und Engine-Versionen müssen die Patch-Level möglicherweise identisch sein oder können unterschiedlich sein. Eine Liste der Engines und Engine-Versionen, die diese Operationen zwischen primären und sekundären Clustern mit unterschiedlichen Patch-Leveln unterstützen, finden Sie unter [Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failover](aurora-global-database-upgrade.md#aurora-global-database-upgrade.minor.incompatibility). Bevor Sie mit dem Failover 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. Wenn Ihre Engine-Versionen identische Patch-Level erfordern, aber unterschiedliche Patch-Level ausführen, können Sie das Failover manuell durchführen, indem Sie die Schritte unter [Ausführen von manuellen geplanten Failovers für globale Aurora-Datenbanken](#aurora-global-database-failover.manual-unplanned) ausführen.
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 eine Hochstufung auf volle Lese-/Schreibfunktionen erfolgte.
Um sicherzustellen, dass sich die Daten in einem konsistenten Zustand befinden, erstellt Aurora nach der Wiederherstellung ein neues Speicher-Volume für die alte primäre Region. Bevor das neue Speicher-Volume in der AWS-Region erstellt wird, versucht Aurora, zum Zeitpunkt des Fehlers einen Snapshot des alten Speicher-Volumes zu erstellen. Auf diese Weise können Sie den Snapshot wiederherstellen und somit auch alle fehlenden Daten. 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-Bereich der AWS-Managementkonsole. Sie können auch den AWS CLI-Befehl `describe-db-cluster-snapshots` oder die `DescribeDBClusterSnapshots`-API-Operation verwenden, um Details zum 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 durchgeführt wird. 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 unter [DB-Cluster-Ereignisse](USER_Events.Messages.md#USER_Events.Messages.cluster). Da ein Fencing (Umgrenzen) von Schreibvorgängen ein Best-Effort-Versuch ist, ist es möglich, dass Schreibvorgänge in der alten primären Region vorübergehend 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.
+ Schalten Sie Anwendungen offline, um zu verhindern, dass Schreibvorgänge an den primären Cluster von Aurora Global Database gesendet werden.
+ Stellen Sie sicher, dass alle Anwendungen, die eine Verbindung zum primären DB-Cluster herstellen, den globalen Writer-Endpunkt verwenden. Dieser Endpunkt hat einen Wert, der auch dann gleich bleibt, wenn eine neue Region aufgrund einer Umstellung oder eines Failovers zum primären Cluster wird. Aurora implementiert zusätzliche Sicherheitsvorkehrungen, um die Möglichkeit von Datenverlusten bei Schreibvorgängen zu minimieren, die über den globalen Endpunkt übermittelt werden. Weitere Informationen zu globalen Writer-Endpunkten finden Sie unter [Verbinden mit Amazon Aurora Global Database](aurora-global-database-connecting.md).
+ Wenn Sie den globalen Writer-Endpunkt verwenden und Ihre Anwendungs- oder Netzwerkschichten DNS-Werte zwischenspeichern, setzen Sie die Gültigkeitsdauer (TTL) Ihres DNS-Caches auf einen niedrigen Wert, z B. auf 5 Sekunden. Auf diese Weise registriert Ihre Anwendung DNS-Änderungen schnell im globalen Writer-Endpunkt. Aurora versucht zwar, Schreibvorgänge in der alten primären Region zu blockieren, es ist jedoch nicht garantiert, dass die Aktion erfolgreich ist. Durch die Reduzierung der DNS-Cache-Lebensdauer wird die Wahrscheinlichkeit von Split-Brain-Problemen weiter minimiert. Alternativ können Sie nach dem RDS-Ereignis suchen, das Sie darüber informiert, wann Aurora DNS-Änderungen für den globalen Writer-Endpunkt beobachtet hat. Auf diese Weise können Sie überprüfen, ob Ihre Anwendung die DNS-Änderung auch registriert hat, bevor Sie den Schreibverkehr Ihrer Anwendung neu starten.
+ Ü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 für alle Aurora-PostgreSQL-basierten Versionen globaler 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 Amazon CloudWatch, um die `AuroraGlobalDBRPOLag`-Metrik für alle sekundären DB-Cluster anzuzeigen. 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 den CloudWatch-Metriken für Aurora finden Sie unter [Metriken auf Cluster-Ebene für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.clusters).
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 einer Parametergruppe für Aurora-DB-Cluster für den neuen primären Cluster, falls erforderlich** – Sie können Ihre Parametergruppen für Aurora-DB-Cluster für jeden Aurora-Cluster in Ihrer globalen Aurora-Datenbank separat 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](aurora-global-database-modifying.parameters.md).
+ **Konfigurieren Sie Überwachungstools und -optionen wie Amazon CloudWatch Events und Alarme** – Konfigurieren Sie den hochgestuften DB-Cluster mit den gleichen Protokollierungsfunktionen, Alarmen usw. wie für die globale Datenbank erforderlich. 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 zur Überwachung von Aurora-DB-Clustern finden Sie unter [Überwachung von Amazon Aurora Aurora-Metriken mit Amazon CloudWatch](monitoring-cloudwatch.md).
+ **Konfigurieren von Integrationen in andere AWS-Services** – Wenn Ihre globale Aurora-Datenbank in andere AWS-Services wie AWS Secrets Manager, AWS Identity and Access Management, Amazon S3 und AWS Lambda integriert ist, müssen Sie sicherstellen, dass diese für den Zugriff aus sekundären Regionen konfiguriert sind. Weitere Informationen zur Integration globaler Aurora-Datenbanken in IAM, Amazon S3 und Lambda finden Sie unter [Verwendung der globalen Amazon Aurora Aurora-Datenbanken mit anderen AWS Diensten](aurora-global-database-interop.md). Weitere Informationen zu Secrets Manager finden Sie unter [So automatisieren Sie die Replikation von Secrets in AWS Secrets Manager über verschiedene AWS-Regionen hinweg](https://aws.amazon.com/blogs/security/how-to-automate-replication-of-secrets-in-aws-secrets-manager-across-aws-regions/).
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 mit dieser 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, so dass 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 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.
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 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](rds-proxy-gdb.md#rds-proxy-gdb.endpoints).
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 Namen `rds:unplanned-global-failover-name-of-old-primary-DB-cluster-timestamp`. Sie finden diesen Snapshot im Bereich **Snapshots** der AWS-Managementkonsole. Sie können diesen Snapshot auch in den Informationen sehen, die von der API-Operation [DescribeDBClusterSnapshots](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterSnapshots.html) zurückgegeben wird.
**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](aurora-copy-snapshot.md).
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](#aurora-global-database-disaster-recovery.managed-failover).
Sie können ein Failover mit Aurora Global Datenbase mit der AWS-Managementkonsole, der AWS CLI oder der RDS-API ausführen.
#### Konsole
**So starten Sie den verwalteten Failover-Prozess in Ihrer globalen Aurora-Datenbank**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie **Datenbanken** aus und suchen Sie die globale Aurora-Datenbank, für die Sie ein Failover ausführen möchten.
1. Wählen Sie im Menü **Aktionen** die Option **Failover für globale Datenbank ausführen** aus.
![\[Anzeige der Datenbankliste mit geöffnetem Aktionsmenü, das die Option „Umschalten oder Failover der globalen Datenbank“ zeigt\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-1.png)
1. Wählen Sie **Failover (Datenverlust zulassen)**.
![\[Das Dialogfeld „Globale Datenbank wechseln“ oder „Failover“, wobei „Failover (Datenverlust zulassen)“ ausgewählt ist.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-2.png)
1. 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.
1. 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 in der Liste **Datenbanken** angezeigt, wie im folgenden Bild zu sehen ist.
![\[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.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-managed-failover-5.png)
#### AWS CLI
**So führen Sie das verwaltete Failover für eine globale Aurora-Datenbank durch**
Verwenden Sie den CLI-Befehl `[failover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-global-cluster.html)`, 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 die AWS-Region an, in der der sekundäre DB-Cluster ausgeführt wird, den Sie als neuen primären DB-Cluster für die globale Aurora-Datenbank verwenden möchten.
+ `--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 Linux, macOS oder Unix:
```
aws rds --region region_of_selected_secondary \
failover-global-cluster --global-cluster-identifier global_database_id \
--target-db-cluster-identifier arn_of_secondary_to_promote \
--allow-data-loss
```
Für 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
```
#### RDS-API
Um ein Failover mit Aurora Global Database durchzuführen, führen Sie die API-Operation [FailoverGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverGlobalCluster.html) 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.
**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 verwenden, um Verzögerungszeiten für sekundäre 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.
**So führen Sie ein manuelles Failover auf einen sekundären Cluster nach einem ungeplanten Ausfall in der primären Region durch:**
1. Beenden Sie die Ausgabe von DML-Anweisungen und anderen Schreibvorgängen auf dem primären Aurora-DB-Cluster in der AWS-Region mit dem Ausfall.
1. Identifizieren Sie einen Aurora-DB-Cluster aus einer sekundären AWS-Region, der als neuer primärer DB-Cluster verwendet werden soll. Wenn Sie zwei oder mehr sekundäre AWS-Regionen in Ihrer globalen Aurora-Datenbank haben, wählen Sie den sekundären Cluster mit der geringsten Replikationsverzögerung.
1. 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](aurora-global-database-detaching.md).
1. 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](rds-proxy-gdb.md#rds-proxy-gdb.endpoints).
1. Fügen Sie dem DB-Cluster eine AWS-Region 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](aurora-global-database-attaching.md).
1. Fügen Sie nach Bedarf weitere AWS-Regionen hinzu, um die Topologie wieder zu erstellen, 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 aufgrund eines Ausfalls in einer AWS-Region eine Neukonfiguration vorgenommen haben, können Sie diese AWS-Region auf primär zurücksetzen, nachdem der Ausfall behoben wurde. 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](#aurora-global-database-disaster-recovery.managed-failover).
## 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.
Der RPO wird verwendet, wenn Ihre Datenbank nach einem Failover den Betrieb in einer neuen AWS-Region 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**
Bei einer globalen Datenbank mit nur zwei AWS-Regionen empfehlen wir, den Standardwert des Parameters `rds.global_db_rpo` in der Parametergruppe der sekundären Region beizubehalten. Andernfalls könnte ein Failover aufgrund eines Verlusts der primären AWS-Region dazu führen, dass Aurora Transaktionen unterbricht. Warten Sie stattdessen, bis Aurora den Neuaufbau des Clusters in der alten ausgefallenen AWS-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](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres).
**Topics**
+ [Festlegen des Recovery Point Objective](#aurora-global-database-set-rpo)
+ [Anzeigen des Recovery Point Objective (Zeitraums zwischen zwei Datensicherungen)](#aurora-global-database-view-rpo)
+ [Deaktivieren des Recovery Point Objective](#aurora-global-database-disable-rpo)
### 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-Managementkonsole, die AWS CLI oder die RDS-API verwenden.
#### Konsole
**So legen Sie den RPO fest:**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. 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 auf `default.aurora-postgresql11`.
+ Legen Sie in Ihrer benutzerdefinierten DB-Parametergruppe den Wert des Parameters **rds.global\$1db\$1rpo** 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 in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
#### AWS CLI
Zum Festlegen des Parameters `rds.global_db_rpo` verwenden Sie den CLI-Befehl [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html). 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) festgelegt `my_custom_global_parameter_group`.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name my_custom_global_parameter_group \
--parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-cluster-parameter-group ^
--db-cluster-parameter-group-name my_custom_global_parameter_group ^
--parameters "ParameterName=rds.global_db_rpo,ParameterValue=600,ApplyMethod=immediate"
```
#### RDS-API
Um den Parameter `rds.global_db_rpo` zu ändern, verwenden Sie die Amazon-RDS-API-Operation [ModifyDBClusterParameterGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterParameterGroup.html).
### 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 Linux, macOS oder Unix:
```
aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-test-apg-global \
--source user
```
Für 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](USER_WorkingWithParamGroups.ViewingCluster.md).
### 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-Managementkonsole, die AWS CLI oder die RDS-API zurücksetzen.
#### Konsole
**So deaktivieren Sie den RPO:**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Parameter groups (Parametergruppen)** aus.
1. Wählen Sie in der Liste Ihre primäre DB-Cluster-Parametergruppe aus.
1. Wählen Sie **Parameter bearbeiten** aus.
1. Wählen Sie das Feld neben dem Parameter **rds.global\$1db\$1rpo** aus.
1. Klicken Sie auf **Reset (Zurücksetzen)**.
1. 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 in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
#### AWS CLI
Um den Parameter `rds.global_db_rpo` zurückzusetzen, verwenden Sie den Befehl [reset-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/reset-db-cluster-parameter-group.html).
Für Linux, macOS oder Unix:
```
aws rds reset-db-cluster-parameter-group \
--db-cluster-parameter-group-name global_db_cluster_parameter_group \
--parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"
```
Für Windows:
```
aws rds reset-db-cluster-parameter-group ^
--db-cluster-parameter-group-name global_db_cluster_parameter_group ^
--parameters "ParameterName=rds.global_db_rpo,ApplyMethod=immediate"
```
#### RDS-API
Um den Parameter `rds.global_db_rpo` zurückzusetzen, verwenden Sie die Amazon-RDS-API-Operation [ResetDBClusterParameterGroup](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ResetDBClusterParameterGroup.html).
# Regionsübergreifende Resilienz für sekundäre Cluster globaler Datenbanken
Die Aurora-PostgreSQL-Versionen 16.6, 15.10, 14.15, 13.18, 12.22 oder höher und die Aurora-MySQL-Versionen 3.09 oder höher enthalten Verbesserungen in Bezug auf die Verfügbarkeit, die es Lesereplikaten der sekundären Region ermöglichen, die Servicekontinuität bei ungeplanten Ereignissen wie Hardwarefehlern, Netzwerkunterbrechungen zwischen AWS-Regionen, großen Datenübertragungen zwischen den Clustern und anderen Ereignissen aufrechtzuerhalten.
Obwohl die Lesereplikate für Ihre Anwendungsanfragen verfügbar bleiben, kann sich die Verzögerung bei der Replikation weiter erhöhen, bis das Problem des ungeplanten Ereignisses behoben ist. Sie können die Verzögerung zwischen primären und sekundären Clustern mithilfe der `AuroraGlobalDBProgressLag`-CloudWatch-Metrik überwachen. Um die durchgehende Verzögerung zu messen, einschließlich aller Verzögerungen zwischen dem Cluster-Volume und den DB-Instances des sekundären Clusters, fügen Sie die Werte der CloudWatch-Metriken `AuroraGlobalDBProgressLag` und `AuroraReplicaLag` hinzu. Weitere Informationen zu Metriken finden Sie unter [Amazon Aurora-Referenz für Metriken](metrics-reference.md).
Die Leseverfügbarkeit der globalen Datenbank für Aurora MySQL und früheren Versionen von Aurora PostgreSQL kann während dieser ungeplanten Ereignisse beeinträchtigt sein.
Weitere Informationen zu neuen Funktionen in Aurora PostgreSQL 16.6, 15.10, 14.15, 13.18 und 12.22 finden Sie unter [PostgreSQL 16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) in den *Aurora-PostgreSQL-Versionshinweisen*
Weitere Informationen zu neuen Funktionen in den Aurora-MySQL-Versionen 3.09 und höher finden Sie unter [Aktualisierungen der Datenbank-Engine für Version 3 von Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) in den *Aurora-MySQL-Versionshinweisen*.
# Überwachen einer globalen Amazon-Aurora-Datenbank
Wenn Sie die Aurora-DB-Cluster erstellen, aus denen Ihre Aurora globale Datenbank besteht, können Sie viele Optionen auswählen, mit denen Sie die Leistung Ihres DB-Clusters überwachen können. Diese Optionen umfassen Folgendes:
+ Amazon RDS Performance Insights – Es ermöglicht Performance-Schema in der zugrunde liegenden Aurora-Datenbank-Engine. Weitere Informationen über Performance Insights und Aurora globale Datenbanken finden Sie unter [Überwachung einer Amazon Aurora globalen Datenbank mit Amazon RDS Performance Insights](#aurora-global-database-pi).
+ „Enhanced Monitoring“ (Erweiterte Überwachung) – Es generiert Metriken für die Prozess- oder Thread-Nutzung auf der CPU. Weitere Informationen zur erweiterten Überwachung finden Sie unter [Überwachen von Betriebssystem-Metriken mithilfe von „Enhanced Monitoring“·(Erweiterte·Überwachung)](USER_Monitoring.OS.md).
+ Amazon CloudWatch Logs — Veröffentlicht bestimmte Protokolltypen in CloudWatch Logs. Fehlerprotokolle werden standardmäßig veröffentlicht. Sie können jedoch andere für Ihre Aurora-Datenbank-Engine spezifische Protokolle auswählen.
+ Für Aurora MySQL–basierte Aurora-DB-Cluster können Sie das Audit-Log, das allgemeine Protokoll und das langsame Abfrage-Log exportieren.
+ Für Aurora PostgreSQL–basierte Aurora-DB-Cluster können Sie das PostgreSQL-Protokoll exportieren.
+ Für Aurora-MySQL-basierte globale Datenbanken können Sie bestimmte `information_schema`-Tabellen verwenden, um den Status Ihrer globalen Aurora-Datenbank und deren Instances zu überprüfen. Um zu erfahren wie dies geht, vgl. [Überwachung der Aurora-MySQL-basierten globalen Datenbanken](#aurora-global-database-monitoring.mysql).
+ Für Aurora-PostgreSQL-basierte globale Datenbanken können Sie bestimmte Funktionen verwenden, um den Status Ihrer Aurora globalen Datenbank und ihrer Instances zu überprüfen. Um zu erfahren wie, siehe [Überwachen von Aurora-PostgreSQL-basierten globalen Datenbanken](#aurora-global-database-monitoring.postgres).
Der folgende Screenshot zeigt einige der Optionen, die auf der Registerkarte Überwachung eines primären Aurora-DB-Clusters in einer Aurora globalen Datenbank verfügbar sind.
![\[Registerkarte „Überwachung“: In der Dropdownliste „Überwachung“ werden CloudWatch die Optionen „Erweiterte Überwachung“, „Betriebssystemprozessliste“ und „Performance Insights“ angezeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-monitoring-options.png)
Weitere Informationen finden Sie unter [Überwachung von Metriken in einem Amazon-Aurora-Cluster](MonitoringAurora.md).
## Überwachung einer Amazon Aurora globalen Datenbank mit Amazon RDS Performance Insights
Sie können Amazon RDS Performance Insights für Ihre globalen Aurora-Datenbanken verwenden. Sie aktivieren diese Funktion einzeln für jeden Aurora-DB-Cluster in Ihrer Aurora globalen Datenbank. Dazu wählen Sie **Performance Insights aktivieren** im Abschnitt **Zusätzliche Konfiguration** der Seite „Datenbank erstellen“. Oder Sie können Ihre Aurora-DB-Cluster ändern, um diese Funktion zu verwenden, nachdem sie in Betrieb sind. Sie können Performance Insights für jeden Cluster, der zur Aurora globalen Datenbank gehört, aktivieren bzw. deaktivieren.
Die von Performance Insights erstellten Berichte gelten für jeden Cluster in der globalen Datenbank. Wenn Sie einer globalen Aurora-Datenbank AWS-Region , die bereits Performance Insights verwendet, eine neue Sekundärdatenbank hinzufügen, stellen Sie sicher, dass Sie Performance Insights im neu hinzugefügten Cluster aktivieren. Die Performance-Insights-Einstellung wird nicht von der vorhandenen globalen Datenbank übernommen.
Sie können wechseln, AWS-Regionen während Sie die Performance Insights Insights-Seite für eine DB-Instance aufrufen, die an eine globale Datenbank angehängt ist. Möglicherweise werden Ihnen jedoch unmittelbar nach dem Wechsel keine Leistungsinformationen angezeigt AWS-Regionen. Obwohl die DB-Instances in jeder DB-Instance identische Namen haben können AWS-Region, ist die zugehörige Performance Insights Insights-URL für jede DB-Instance unterschiedlich. Wählen Sie nach dem Umschalten AWS-Regionen erneut den Namen der DB-Instance im Performance Insights Insights-Navigationsbereich aus.
Für DB-Instances, die einer globalen Datenbank zugeordnet sind, können sich in jeder AWS-Region andere Faktoren auf die Leistung auswirken. Beispielsweise AWS-Region können die DB-Instances in jeder Instanz unterschiedliche Kapazitäten haben.
Weitere Informationen zum Verwenden von Performance Insights finden Sie unter [Überwachung mit Performance Insights auf ](USER_PerfInsights.md).
## Überwachung von globalen Aurora-Datenbanken mithilfe von Datenbank-Aktivitätsstreams
Durch die Verwendung von Datenbank-Aktivitätsstreams können Sie Alarme für die Prüfung von Aktivitäten in den DB-Clustern Ihrer globalen Datenbank überwachen und einstellen. Sie starten einen Datenbank-Aktivitätsstream separat auf jedem DB-Cluster. Jeder Cluster liefert Auditdaten innerhalb seiner eigenen AWS-Region an seinen eigenen Kinesis-Stream. Weitere Informationen finden Sie unter [Überwachung von Amazon Aurora mithilfe von Datenbankaktivitätsstreams](DBActivityStreams.md).
## Überwachung der Aurora-MySQL-basierten globalen Datenbanken
Um den Status einer auf Aurora MySQL basierenden globalen Datenbank abzurufen, fragen Sie die Tabellen [information\$1schema.aurora\$1global\$1db\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.aurora_global_db_status) und [information\$1schema.aurora\$1global\$1db\$1instance\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.aurora_global_db_instance_status) ab.
**Anmerkung**
Die Tabellen `information_schema.aurora_global_db_status` und `information_schema.aurora_global_db_instance_status` sind nur mit globalen Aurora-MySQL-Datenbanken ab Version 3.04.0 verfügbar.
**So überwachen Sie eine Aurora-MySQL-basierte globale Datenbank**
1. Stellen Sie mithilfe eines MySQL-Clients eine Verbindung zum primären Cluster-Endpunkt der globalen Datenbank her. Weitere Informationen zum Herstellen einer Verbindung finden Sie unter [Verbinden mit Amazon Aurora Global Database](aurora-global-database-connecting.md).
1. Fragen Sie die Tabelle `information_schema.aurora_global_db_status` in einem mysql-Befehl ab, um die primären und sekundären Volumes aufzulisten. Diese Abfrage gibt die Verzögerungszeiten der sekundären DB-Cluster der globalen Datenbank zurück, wie im folgenden Beispiel dargestellt.
```
mysql> select * from information_schema.aurora_global_db_status;
```
```
AWS_REGION | HIGHEST_LSN_WRITTEN | DURABILITY_LAG_IN_MILLISECONDS | RPO_LAG_IN_MILLISECONDS | LAST_LAG_CALCULATION_TIMESTAMP | OLDEST_READ_VIEW_TRX_ID
-----------+---------------------+--------------------------------+------------------------+---------------------------------+------------------------
us-east-1 | 183537946 | 0 | 0 | 1970-01-01 00:00:00.000000 | 0
us-west-2 | 183537944 | 428 | 0 | 2023-02-18 01:26:41.925000 | 20806982
(2 rows)
```
Die Ausgabe enthält eine Zeile für jeden DB-Cluster der globalen Datenbank, die die folgenden Spalten enthält:
+ **AWS\$1REGION**— Die AWS-Region , in der sich dieser DB-Cluster befindet. Eine nach Engine AWS-Regionen aufgelistete Tabellen finden Sie unter[Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ **HIGHEST\$1LSN\$1WRITTEN** – die höchste Log-Sequenznummer (LSN), die derzeit auf diesem DB-Cluster geschrieben wird.
Eine *Log-Sequenznummer (LSN)* ist eine eindeutige Sequenznummer, die einen Datensatz im Datenbank-Transaktionslog identifiziert. LSNs sind so angeordnet, dass eine größere LSN für eine spätere Transaktion steht.
+ **DURABILITY\$1LAG\$1IN\$1MILLISECONDS** – die Differenz der Zeitstempelwerte zwischen `HIGHEST_LSN_WRITTEN` in einem sekundären DB-Cluster und `HIGHEST_LSN_WRITTEN` im primären DB-Cluster. Der Wert ist immer 0 im primären DB-Cluster der globalen Aurora-Datenbank.
+ **RPO\$1LAG\$1IN\$1MILLISECONDS** – die Verzögerung des Zeitraums im Hinblick auf Recovery Point Objective (RPO). Die RPO-Verzögerung ist die Zeit, die benötigt wird, bis die letzte Benutzertransaktion COMMIT auf einem sekundären DB-Cluster gespeichert wird, nachdem sie auf dem primären DB-Cluster einer globalen Aurora-Datenbank abgelegt wurde. Der Wert ist immer 0 im primären DB-Cluster der globalen Aurora-Datenbank.
Einfach ausgedrückt berechnet diese Metrik das Recovery Point Objective für jeden DB-Cluster voon Aurora MySQL in der globalen Aurora-Datenbank, d. h., wie viele Daten bei einem Ausfall verloren gehen könnten. Wie die Verzögerung wird auch RPO zeitlich gemessen.
+ **LAST\$1LAG\$1CALCULATION\$1TIMESTAMP** – der Zeitstempel mit Angabe des Zeitpunkts, zu dem die Werte für `DURABILITY_LAG_IN_MILLISECONDS` und `RPO_LAG_IN_MILLISECONDS` zuletzt berechnet wurden. Ein Zeitwert wie `1970-01-01 00:00:00+00` bedeutet, dass dies der primäre DB-Cluster ist.
+ **OLDEST\$1READ\$1VIEW\$1TRX\$1ID** – die ID der ältesten Transaktion, bis zu der die Writer-DB-Instance Daten löschen kann.
1. Fragen Sie die Tabelle `information_schema.aurora_global_db_instance_status` ab, um alle sekundären DB-Instances sowohl für den primären DB-Cluster als auch für sekundäre DB-Cluster aufzulisten.
```
mysql> select * from information_schema.aurora_global_db_instance_status;
```
```
SERVER_ID | SESSION_ID | AWS_REGION | DURABLE_LSN | HIGHEST_LSN_RECEIVED | OLDEST_READ_VIEW_TRX_ID | OLDEST_READ_VIEW_LSN | VISIBILITY_LAG_IN_MSEC
---------------------+--------------------------------------+------------+-------------+----------------------+-------------------------+----------------------+------------------------
ams-gdb-primary-i2 | MASTER_SESSION_ID | us-east-1 | 183537698 | 0 | 0 | 0 | 0
ams-gdb-secondary-i1 | cc43165b-bdc6-4651-abbf-4f74f08bf931 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 0
ams-gdb-secondary-i2 | 53303ff0-70b5-411f-bc86-28d7a53f8c19 | us-west-2 | 183537689 | 183537692 | 20806928 | 183537682 | 677
ams-gdb-primary-i1 | 5af1e20f-43db-421f-9f0d-2b92774c7d02 | us-east-1 | 183537697 | 183537698 | 20806930 | 183537691 | 21
(4 rows)
```
Die Ausgabe enthält eine Zeile für jede DB-Instance der globalen Datenbank, die die folgenden Spalten enthält:
+ **SERVER\$1ID** – die Server-ID für die DB-Instance.
+ **SESSION\$1ID** – eine eindeutige ID für die aktuelle Sitzung. Der Wert `MASTER_SESSION_ID` bezeichnet die (primäre) Writer-DB-Instance.
+ **AWS\$1REGION**— Die AWS-Region , in der sich diese DB-Instance befindet. Eine nach Engine AWS-Regionen aufgelistete Tabellen finden Sie unter[Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ **DURABLE\$1LSN** – die LSN, die im Speicher als dauerhaft definiert wurde.
+ **HIGHEST\$1LSN\$1RECEIVED** – die höchste LSN, die die DB-Instance von der DB-Writer-Instance empfangen hat.
+ **OLDEST\$1READ\$1VIEW\$1TRX\$1ID** – die ID der ältesten Transaktion, bis zu der die Writer-DB-Instance Daten löschen kann.
+ **OLDEST\$1READ\$1VIEW\$1LSN** – die älteste LSN, die von der DB-Instance zum Lesen aus dem Speicher verwendet wird.
+ **VISIBILITY\$1LAG\$1IN\$1MSEC** – für Reader im primären DB-Cluster, wie weit diese DB-Instance der Writer-DB-Instance in Millisekunden hinterherhinkt. Für Reader in einem sekundären DB-Cluster, wie weit diese DB-Instance dem sekundären Volume in Millisekunden hinterherhinkt.
Um zu sehen, wie sich diese Werte im Laufe der Zeit verändern, betrachten Sie den folgenden Transaktionsblock, in dem eine Tabelleneinfügung eine Stunde dauert.
```
mysql> BEGIN;
mysql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert;
mysql> COMMIT;
```
In einigen Fällen kann es nach der `BEGIN`-Anweisung zu einer Netzwerktrennung zwischen dem primären DB-Cluster und dem sekundären DB-Cluster kommen. In diesem Fall beginnt der Wert **DURABILITY\$1LAG\$1IN\$1MILLISECONDS** des sekundäre DB-Clusters zu steigen. Am Ende der `INSERT`-Anweisung beträgt der Wert **DURABILITY\$1LAG\$1IN\$1MILLISECONDS** 1 Stunde. Der Wert **RPO\$1LAG\$1IN\$1MILLISECOND** ist jedoch 0, da alle Benutzerdaten, die zwischen dem primären DB-Cluster und dem sekundären DB-Cluster übertragen werden, immer noch dieselben sind. Sobald die `COMMIT`-Anweisung abgeschlossen ist, steigt der Wert **RPO\$1LAG\$1IN\$1MILLISECONDS**Wert steigt.
## Überwachen von Aurora-PostgreSQL-basierten globalen Datenbanken
Verwenden Sie die Funktionen `aurora_global_db_status` und `aurora_global_db_instance_status`, um den Status einer Aurora-PostgreSQL-basierten globalen Datenbank anzuzeigen.
**Anmerkung**
Die Funktionen `aurora_global_db_status` und `aurora_global_db_instance_status` werden nur von Aurora PostgreSQL unterstützt.
**So überwachen Sie eine Aurora PostgreSQL-basierte globale Datenbank**
1. Stellen Sie mithilfe eines PostgreSQL-Dienstprogramms wie psql eine Verbindung zum primären Cluster-Endpunkt der globalen Datenbank her. Weitere Informationen zum Herstellen einer Verbindung finden Sie unter [Verbinden mit Amazon Aurora Global Database](aurora-global-database-connecting.md).
1. Sie verwenden die Funktion `aurora_global_db_status` in einem psql-Befehl, um die primären und sekundären Volumes aufzulisten. Dadurch werden die Verzögerungszeiten der sekundären DB-Cluster der globalen Datenbank angezeigt.
```
postgres=> select * from aurora_global_db_status();
```
```
aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin
------------+---------------------+------------------------+-----------------+----------------------------+----------------+---------------
us-east-1 | 93763984222 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0
us-west-2 | 93763984222 | 900 | 1090 | 2020-05-12 22:49:14.328+00 | 2 | 3315479243
(2 rows)
```
Die Ausgabe enthält eine Zeile für jeden DB-Cluster der globalen Datenbank, die die folgenden Spalten enthält:
+ **aws\$1region** — Die AWS-Region , in der sich dieser DB-Cluster befindet. Eine nach Engine aufgelistete Tabellen finden Sie AWS-Regionen unter. [Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)
+ **highest\$1lsn\$1written** – Die höchste Log-Sequenznummer (LSN), die derzeit auf diesem DB-Cluster geschrieben wird.
Eine *Log-Sequenznummer (LSN)* ist eine eindeutige Sequenznummer, die einen Datensatz im Datenbank-Transaktionslog identifiziert. LSNs sind so angeordnet, dass eine größere LSN für eine spätere Transaktion steht.
+ **durability\$1lag\$1in\$1msec** – Die Zeitstempeldifferenz zwischen der höchsten Log-Sequenznummer, die auf einem sekundären DB-Cluster (`highest_lsn_written`) geschrieben wurde, und der `highest_lsn_written` auf dem primären DB-Cluster.
+ **rpo\$1lag\$1in\$1msec** – Die Verzögerung des Zeitraums zwischen zwei Datensicherungen (RPO). Diese Verzögerung ist die Zeitdifferenz zwischen dem letzten Benutzertransaktions-Commit, der auf einem sekundären DB-Cluster gespeichert ist, und dem letzten Benutzertransaktions-Commit, der auf dem primären DB-Cluster gespeichert ist.
+ **last\$1lag\$1calculation\$1time** – Der Zeitstempel mit Angabe des Zeitpunkts, zu dem die Werte für `durability_lag_in_msec` und `rpo_lag_in_msec` zuletzt berechnet wurden.
+ **feedback\$1epoch** – Die Epoche, die ein sekundärer DB-Cluster beim Erzeugen von Hot-Standby-Informationen verwendet.
*Hot-Standby* bedeutet, dass ein DB-Cluster eine Verbindung herstellen und Abfragen durchführen kann, während sich der Server im Wiederherstellungs- oder Standby-Modus befindet. Hot-Standby-Feedbacks sind Informationen über den DB-Cluster, wenn dieser sich im Hot-Standby-Modus befindet. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html).
+ **feedback\$1xmin** – Die minimale (älteste) aktive Transaktions-ID, die von einem sekundären DB-Cluster verwendet wird.
1. Verwenden Sie die Funktion `aurora_global_db_instance_status`, um alle sekundären DB-Instances sowohl für den primären DB-Cluster als auch für sekundäre DB-Cluster aufzulisten.
```
postgres=> select * from aurora_global_db_instance_status();
```
```
server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
--------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------
apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID | us-east-1 | 93763985102 | | | | |
apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1 | 93763985099 | 93763985102 | 2 | 3315479243 | 93763985095 | 10
apg-global-db-rpo-elephantro-mammothrw-n1 | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2 | 93763985095 | 93763985099 | 2 | 3315479243 | 93763985089 | 1017
(3 rows)
```
Die Ausgabe enthält eine Zeile für jede DB-Instance der globalen Datenbank, die die folgenden Spalten enthält:
+ **server\$1id** – Die Server-ID für die DB-Instance.
+ **session\$1id** – Eine eindeutige ID für die aktuelle Sitzung.
+ **aws\$1region** — Die AWS-Region , in der sich diese DB-Instance befindet. Eine nach Engine aufgelistete Tabellen finden Sie AWS-Regionen unter. [Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)
+ **durable\$1lsn** – Der LSN wurde im Speicher dauerhaft gemacht.
+ **highest\$1lsn\$1rcvd** – Die höchste LSN, die die DB-Instance von der DB-Writer-Instance empfangen hat.
+ **feedback\$1epoch** – Die Epoche, die die DB-Instance beim Erzeugen der Hot-Standby-Informationen verwendet.
*Hot standby* bedeutet, dass eine DB-Instance eine Verbindung herstellen und Abfragen durchführen kann, während sich der Server im Wiederherstellungs- oder Standby-Modus befindet. Hot-Standby-Feedbacks sind Informationen über die DB-Instance, wenn diese sich im Hot-Standby-Modus befindet. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zu [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html).
+ **feedback\$1xmin** – Die minimale (älteste) aktive Transaktions-ID, die von der DB-Instance verwendet wird.
+ **oldest\$1read\$1view\$1lsn** – Die älteste LSN, die von der DB-Instance zum Lesen aus dem Speicher verwendet wird.
+ **visibility\$1lag\$1in\$1msec** – Wie stark diese DB-Instance gegenüber der DB-Schreiber-Instance zeitlich verzögert ist.
Um zu sehen, wie sich diese Werte im Laufe der Zeit verändern, betrachten Sie den folgenden Transaktionsblock, in dem eine Tabelleneinfügung eine Stunde dauert.
```
psql> BEGIN;
psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert;
psql> COMMIT;
```
In einigen Fällen kann es nach der `BEGIN`-Anweisung zu einer Netzwerktrennung zwischen dem primären DB-Cluster und dem sekundären DB-Cluster kommen. Wenn dies der Fall ist, beginnt sich der `durability_lag_in_msec`-Wert des sekundären DB-Clusters zu erhöhen. Am Ende der `INSERT`-Anweisung beträgt der `durability_lag_in_msec`-Wert 1 Stunde. Der Wert `rpo_lag_in_msec` ist jedoch 0, da alle Benutzerdaten, die zwischen dem primären DB-Cluster und dem sekundären DB-Cluster übertragen werden, immer noch dieselben sind. Sobald die `COMMIT`-Anweisung abgeschlossen ist, erhöht sich der `rpo_lag_in_msec`-Wert.
# Blue/Green Bereitstellungen für Amazon Aurora Global Database verwenden
Amazon Blue/Green RDS-Bereitstellungen bieten die Möglichkeit, Datenbankänderungen sicher zu testen. Für Ihre globale Datenbank ermöglichen blue/green Bereitstellungen die Durchführung von Upgrades und Wartungsarbeiten mit minimalen Ausfallzeiten. Sie können eine vollständig verwaltete Staging-Umgebung (grün) erstellen, die Ihre gesamte Produktionsumgebung (blau) widerspiegelt, einschließlich des primären Clusters und aller zugehörigen sekundären Regionen in mehreren AWS Regionen. Die Staging-Umgebung entspricht Ihrem Produktions-Setup, sodass Sie Änderungen zuverlässig testen können, bevor Sie zur neuen Umgebung wechseln. Während des gesamten Prozesses sorgen blue/green Bereitstellungen dafür, dass die Staging- und Produktionsumgebung synchron bleiben. Wenn Sie bereit sind, Ihre Staging-Umgebung zur neuen Produktionsumgebung zu machen, führen Sie einen Switchover durch. blue/green Bei diesem Vorgang werden Ihre primären und alle sekundären Regionen auf die grüne Umgebung umgestellt, wobei die Ausfallzeiten in der Regel unter einer Minute liegen. Der Service benennt Cluster, Instances und Endpoints automatisch um, sodass sie der ursprünglichen Produktionsumgebung entsprechen, sodass Ihre Anwendungen ohne Konfigurationsänderungen auf die neue Produktionsumgebung zugreifen können und der Betriebsaufwand minimiert wird.
**Topics**
+ [Vorteile der Verwendung von Blue/Green Bereitstellungen mit Aurora Global Database](#aurora-blue-green-benefits)
+ [So funktionieren Blue/Green Bereitstellungen mit Aurora Global Database](#aurora-blue-green-howitworks)
## Vorteile der Verwendung von Blue/Green Bereitstellungen mit Aurora Global Database
+ Führen Sie Hauptversionen, Nebenversionen und Systemupdates, einschließlich Datenbank-Patches und Betriebssystem-Upgrades, auf Aurora Global Databases durch und sorgen Sie dabei für minimale Ausfallzeiten.
+ Erstellen Sie eine produktionsbereite (grüne) Staging-Umgebung sowohl in den primären als auch in den sekundären Regionen der globalen Datenbank, um neuere Datenbankfunktionen zu testen und zu implementieren.
+ Sicheres Switchover mithilfe integrierter Switchover-Leitplanken mit Ausfallzeiten in der Regel unter einer Minute, je nach Arbeitslast.
+ Behält die Disaster-Recovery-Funktionen während des Blue/Green Switchover-Prozesses bei und ermöglicht so ein globales Datenbank-Failover während des Switchovers. Blue/Green
+ Ihr Datenverkehr wird an die neue Produktionsumgebung weitergeleitet, ohne dass Änderungen an der Anwendung erforderlich sind.
## So funktionieren Blue/Green Bereitstellungen mit Aurora Global Database
Einzelheiten zum Erstellen, Anzeigen, Wechseln und Löschen eines Blue/Green Deployments finden Sie unter[Verwenden von Amazon Aurora Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md). Sie können dies für Upgrades von Haupt- oder Nebenversionen, zur Verbesserung der Datenbankleistung durch Parameteraktualisierungen und zur Einführung neuer Datenbankfunktionen bei minimaler Ausfallzeit verwenden.
Im Folgenden wird dargestellt, wie ein blue/green Einsatz für Aurora Global Database mit einer sekundären Region vor und nach einem blue/green Switchover aussieht.
![\[Ein Beispiel für eine Blue/Green Bereitstellung für Aurora Global Database.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/Aurora Global Database_Blue_Green_example.png)
Sie können ein blue/green Deployment von der Hauptregion Ihrer globalen Datenbank aus erstellen. Wählen Sie die Engine-Konfigurationen wie Haupt- oder Nebenversion der Engine, DB-Parametergruppe und DB-Cluster-Parametergruppe für die grüne Umgebung aus. Amazon RDS kopiert die Topologie der blauen Umgebung für die grüne Umgebung. Eine visuelle Darstellung in AWS-Managementkonsole ist wie unten dargestellt.
![\[Zusammenfassung eines Blue/Green Einsatzes.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/auroraglobaldatabase_bluegreen.png)
**Anmerkung**
Globales Failover wird während eines blue/green Switchovers unterstützt, aber globales Switchover wird während eines Switchovers nicht unterstützt. blue/green
Wenn Sie während eines blue/green RDS-Switchovers einen globalen Failover einleiten, wird die Zielregion automatisch zur blauen Umgebung zurückgesetzt oder zur grünen Umgebung weitergeleitet, bevor der globale Failover stattfindet.
Informationen zum Erstellen, Anzeigen, Wechseln und Löschen von blue/green Bereitstellungen finden Sie unter. [Verwenden von Amazon Aurora Blue/Green Deployments für Datenbank-Updates](blue-green-deployments.md) Folgen Sie demselben Arbeitsablauf für globale Datenbanken, wobei die spezifischen Anweisungen in den entsprechenden Schritten aufgeführt sind.
# Verwendung der globalen Amazon Aurora Aurora-Datenbanken mit anderen AWS Diensten
Sie können Ihre globalen Aurora-Datenbanken mit anderen AWS Diensten wie Amazon S3 und verwenden AWS Lambda. Dies erfordert, dass alle Aurora-DB-Cluster in Ihrer globalen Datenbank die gleichen Privilegien, externen Funktionen usw. in den jeweiligen AWS-Regionen aufweisen. Da ein schreibgeschützter sekundärer Aurora-DB-Cluster in einer Aurora globalen Datenbank zur Rolle des primären Clusters hochgestuft werden kann, empfehlen wir, dass Sie im Voraus Schreibrechte für alle Aurora-DB-Cluster für alle Dienste einrichten, die Sie mit Ihrer Aurora globalen Datenbank verwenden möchten.
In den folgenden Verfahren sind die jeweils AWS-Service zu ergreifenden Maßnahmen zusammengefasst.
**Um AWS Lambda Funktionen aus einer globalen Aurora-Datenbank aufzurufen**
1. Führen Sie für alle Aurora-Cluster, aus denen die globale Aurora-Datenbank besteht, die unter beschriebenen Schritte au [Aufrufen einer Lambda-Funktion aus einem Amazon Aurora MySQL-DB-Cluster](AuroraMySQL.Integrating.Lambda.md).
1. Legen Sie für jeden Cluster in der Aurora globalen Datenbank den (ARN) der neuen IAM (IAM) -Rolle fest.
1. Verknüpfen Sie die in [Eine IAM-Rolle erstellen, um Amazon Aurora den Zugriff auf AWS Services zu ermöglichen](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md) erstellte Rolle mit allen Clustern in der globalen Aurora-Datenbank, um Datenbankbenutzern in einer globalen Aurora-Datenbank das Aufrufen von Lambda-Funktionen zu erlauben.
1. Konfigurieren Sie jeden Cluster in der globalen Aurora-Datenbank so, dass ausgehende Verbindungen zu Lambda zugelassen werden. Detaillierte Anweisungen finden Sie unter [Aktivierung der Netzwerkkommunikation von Amazon Aurora zu anderen AWS Diensten](AuroraMySQL.Integrating.Authorizing.Network.md).
**So laden Sie Daten aus Amazon S3**
1. Führen Sie für alle Aurora-Cluster, aus denen die globale Aurora-Datenbank besteht, die unter beschriebenen Schritte au [Laden von Daten in einen Amazon Aurora MySQL-DB-Cluster aus Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.LoadFromS3.md).
1. Legen Sie bei jedem Aurora-Cluster in der globalen Datenbank für den Amazon-Ressourcennamen (ARN) der neuen IAM-Rolle entweder den Cluster-Parameter `aurora_load_from_s3_role` oder `aws_default_s3_role` fest Wenn für `aurora_load_from_s3_role` keine IAM-Rolle angegeben wird, verwendet Aurora die unter `aws_default_s3_role` angegebene IAM-Rolle.
1. Um Datenbankbenutzern in einer globalen Aurora-Datenbank den Zugriff auf Amazon S3 zu gewähren, verknüpfen Sie die in [Eine IAM-Rolle erstellen, um Amazon Aurora den Zugriff auf AWS Services zu ermöglichen](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md) erstellte Rolle mit jedem Aurora-Cluster in der globalen Datenbank.
1. Konfigurieren Sie jeden Aurora-Cluster in der globalen Datenbank so, dass ausgehende Verbindungen zu S3 zugelassen werden. Detaillierte Anweisungen finden Sie unter [Aktivierung der Netzwerkkommunikation von Amazon Aurora zu anderen AWS Diensten](AuroraMySQL.Integrating.Authorizing.Network.md).
**So speichern Sie abgefragte Daten auf Amazon S3**
1. Führen Sie für alle Aurora-Cluster, aus denen die globale Aurora-Datenbank besteht, die unter [Speichern von Daten aus einem Amazon Aurora MySQL-DB-Cluster in Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.SaveIntoS3.md) oder [Exportieren von Daten aus einem/einer Aurora PostgreSQL-DB-Cluster zu Amazon S3](postgresql-s3-export.md) beschriebenen Verfahren durch.
1. Legen Sie bei jedem Aurora-Cluster in der globalen Datenbank für den Amazon-Ressourcennamen (ARN) der neuen IAM-Rolle entweder den Cluster-Parameter `aurora_select_into_s3_role` oder `aws_default_s3_role` fest Wenn für `aurora_select_into_s3_role` keine IAM-Rolle angegeben wird, verwendet Aurora die unter `aws_default_s3_role` angegebene IAM-Rolle.
1. Um Datenbankbenutzern in einer globalen Aurora-Datenbank den Zugriff auf Amazon S3 zu gewähren, verknüpfen Sie die in [Eine IAM-Rolle erstellen, um Amazon Aurora den Zugriff auf AWS Services zu ermöglichen](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md) erstellte Rolle mit jedem Aurora-Cluster in der globalen Datenbank.
1. Konfigurieren Sie jeden Aurora-Cluster in der globalen Datenbank so, dass ausgehende Verbindungen zu S3 zugelassen werden. Detaillierte Anweisungen finden Sie unter [Aktivierung der Netzwerkkommunikation von Amazon Aurora zu anderen AWS Diensten](AuroraMySQL.Integrating.Authorizing.Network.md).
## Verwenden von Amazon Application Recovery Controller (ARC) mit Aurora Global Database
Bei der Planung Ihrer Strategie für Geschäftskontinuität und Notfallwiederherstellung müssen Sie die Wiederherstellung für alle Anwendungsstapel und deren Abhängigkeiten orchestrieren. [Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/region-switch.html) ist in Aurora Global Database integriert, um diesen Prozess über ARC Region Switch, eine zentralisierte Lösung für die automatisierte Wiederherstellung von Anwendungen in mehreren Regionen, zu automatisieren. Region Switch orchestriert die Failover-Schritte für AWS Konten und Regionen, stellt Wiederherstellungs-Dashboards in Echtzeit bereit und generiert Compliance-Berichte, indem Daten über Ressourcen und Konten hinweg aggregiert werden. Erfahren Sie mehr über die [Verwendung von Region Switch für Aurora Global Database](https://docs.aws.amazon.com/r53recovery/latest/dg/aurora-global-database-block.html).
# Aktualisieren einer globalen Datenbank von Amazon Aurora
Das Upgrade einer globalen Aurora-Datenbank folgt den gleichen Verfahren wie das Upgrade von Aurora-DB-Clustern. Im Folgenden sind jedoch einige wichtige Unterschiede aufgeführt, die Sie beachten müssen, bevor Sie den Prozess starten.
Wir empfehlen, den primären und den sekundären DB-Cluster auf dieselbe Version zu aktualisieren. 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 Failover](#aurora-global-database-upgrade.minor.incompatibility).
## Hauptversions-Upgrades
Wenn Sie ein Hauptversions-Upgrade einer Amazon Aurora Global Database durchführen, aktualisieren Sie den globalen Datenbank-Cluster statt der einzelnen darin enthaltenen Cluster.
Informationen zum Aktualisieren einer globalen Aurora-PostgreSQL-Datenbank auf eine höhere Hauptversion finden Sie unter [Hauptversions-Upgrades für globale Datenbanken](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.GlobalDB).
**Anmerkung**
Mit einer globalen Aurora-Datenbank, die auf Aurora PostgreSQL basiert, können Sie kein Hauptversions-Upgrade der Aurora-DB-Engine durchführen, wenn die Recovery Point Objective (RPO)-Funktion aktiviert ist. Weitere Informationen über RPO-Funktion finden Sie unter [Verwalten von RPOs für Aurora PostgreSQL–basierte globale Datenbanken](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery).
Informationen zum Aktualisieren einer globalen Aurora-MySQL-Datenbank auf eine höhere Hauptversion finden Sie unter [In-Situ-Hauptversions-Upgrades für globale Datenbanken](AuroraMySQL.Upgrading.Procedure.md#AuroraMySQL.Upgrading.GlobalDB).
**Anmerkung**
Bei einer globalen Aurora-Datenbank, die auf Aurora MySQL basiert, können Sie ein direktes Upgrade von Aurora-MySQL-Version 2 auf Version 3 nur durchführen, wenn Sie den `lower_case_table_names`-Parameter auf den Standardwert setzen und Ihre globale Datenbank neu starten.
Um ein Hauptversions-Upgrade auf Aurora MySQL Version 3 bei Verwendung von `lower_case_table_names` durchzuführen, gehen Sie wie folgt vor:
Entfernen Sie alle sekundären Regionen aus dem globalen Cluster. Führen Sie die Schritte unter [Entfernen eines Clusters aus einer Amazon Aurora Global Database](aurora-global-database-detaching.md) aus.
Aktualisieren Sie die Engine-Version der primären Region zu Aurora-MySQL-Version 3. Führen Sie die Schritte unter [Erläuterung der Durchführung eines direkten Upgrades](AuroraMySQL.Upgrading.Procedure.md) aus.
Fügen Sie dem globalen Cluster sekundäre Regionen hinzu. Führen Sie die Schritte unter [Hinzufügen einer AWS-Region zu einer globalen Amazon-Aurora-Datenbank](aurora-global-database-attaching.md) aus.
Sie können stattdessen auch die Snapshot-Wiederherstellungsmethode verwenden. Weitere Informationen finden Sie unter [Wiederherstellen aus einem DB-Cluster-Snapshot](aurora-restore-snapshot.md).
## Unterversion-Upgrades
Sie können Ihre globale Aurora-Datenbank in allen Regionen mit einem einzigen verwalteten Vorgang und minimalen Ausfallzeiten auf eine neuere Minor-Engine-Version aktualisieren, sodass Sie nicht jeden Cluster einzeln manuell aktualisieren müssen und der Betriebsaufwand für das globale Clustermanagement reduziert wird.
### Grundlegendes zu Upgrades für kleinere Versionen der globalen Datenbank
Sie können die Nebenversion Ihrer globalen Datenbank über die RDS-API aktualisieren, AWS CLI, oder AWS-Managementkonsole. Dieser einzelne Vorgang orchestriert das Upgrade für Ihren primären Cluster und alle sekundären Cluster (Spiegelcluster). Wenn während des Upgrades Probleme auftreten, wird der Service automatisch auf die bestehende Version zurückgesetzt.
**Anmerkung**
Diese verwaltete Funktion wird derzeit nur für Aurora PostgreSQL-kompatible Engines unterstützt.
Wenn Sie mit dem `modify-global-cluster` Befehl ein Upgrade der globalen Datenbank-Nebenversion initiieren, geben Sie die Ziel-Engine-Version an, und der Service koordiniert das Upgrade für alle Cluster. Dieses Upgrade wird sofort angewendet.
Für Linux, macOS oder Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine-version target_engine_version
```
Für Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine-version target_engine_version
```
### Überlegungen zu Upgrades kleinerer Versionen
Wenn Sie ein Upgrade einer Nebenversion für Ihre globale Datenbank planen, sollten Sie Folgendes berücksichtigen:
+ Die verwaltete Funktion gilt nur für Upgrades kleinerer Versionen. Bei Patch-Versions-Upgrades werden weiterhin bestehende Wartungsaktionen für Systemupdates verwendet.
+ Die verwaltete Funktion wird nur für globale Aurora PostgreSQL-Cluster unterstützt.
Sie können jeden Cluster in Ihrer globalen Cluster-Topologie einzeln aktualisieren. Wenn Sie sich für diesen Ansatz entscheiden, führen Sie ein Upgrade aller sekundären Cluster durch, bevor Sie das Upgrade des primären Clusters durchführen. Stellen Sie beim Upgrade sicher, dass Ihre primären und sekundären DB-Cluster auf dieselbe Nebenversion und dasselbe Patch-Level aktualisiert werden. Um das Patch-Level zu aktualisieren, wenden Sie alle ausstehenden Wartungsaktionen auf den sekundären Cluster an. Informationen zum Aktualisieren einer globalen Aurora-PostgreSQL-Datenbank auf eine kleinere Hauptversion finden Sie unter [So führen Sie Upgrades von Nebenversionen durch und wenden Patches an](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor).
### Kleinere Versionsupgrades für die globale Aurora MySQL-Datenbank
Informationen zum Aktualisieren einer globalen Aurora-MySQL-Datenbank auf eine Unterversion finden Sie unter [Upgrade von Aurora MySQL durch Ändern der Engine-Version](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md).
Bevor Sie die Aktualisierung durchführen, lesen Sie die folgenden Hinweise:
+ Eine Aktualisierung der Unterversion eines sekundären Clusters hat keinerlei Auswirkungen auf die Verfügbarkeit oder Nutzung des primären Clusters.
+ Ein sekundärer Cluster muss über mindestens eine DB-Instance verfügen, um ein Unterversions-Upgrade durchzuführen.
+ Wenn Sie eine globale Aurora-MySQL-Datenbank auf Version 2.11.\$1 aktualisieren, müssen Sie Ihre primären und sekundären DB-Cluster auf exakt dieselbe Version aktualisieren, einschließlich des Patch-Levels.
+ Um verwaltete regionsübergreifende Umstellungen oder Failover zu unterstützen, müssen Sie Ihre primären und sekundären DB-Cluster möglicherweise auf genau dieselbe Version aktualisieren, einschließlich des Patch-Levels. Diese Anforderung gilt für Aurora MySQL und einige Aurora-PostgreSQL-Versionen. Eine Liste der Versionen, die Umstellungen und Failover zwischen Clustern mit unterschiedlichen Patch-Leveln ermöglichen, finden Sie unter [Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failover](#aurora-global-database-upgrade.minor.incompatibility).
### Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failover
Wenn Ihre globale Aurora-Datenbank eine der folgenden Engine-Nebenversionen ausführt, können Sie verwaltete regionsübergreifende Umstellungen oder Failover durchführen, auch wenn die Patch-Level Ihrer primären und sekundären DB-Cluster nicht übereinstimmen. Bei Engine-Nebenversionen, die niedriger sind als die in dieser Liste aufgeführten, müssen Ihre primären und sekundären DB-Cluster dieselben Haupt- und Nebenversionen sowie Patch-Level ausführen, um verwaltete regionsübergreifende Umstellungen und Failover durchführen zu können. Sehen Sie sich unbedingt die Versionsinformationen und die Hinweise in der folgenden Tabelle an, wenn Sie Upgrades für Ihren primären Cluster und/oder Ihre sekundären Cluster planen.
**Anmerkung**
Bei manuellen regionsübergreifenden Failovern können Sie den Failover-Vorgang ausführen, solange auf dem sekundären Ziel-DB-Cluster dieselbe Engine-Haupt- und -Nebenversion wie auf dem primären DB-Cluster ausgeführt wird. In diesem Fall müssen die Patch-Level nicht übereinstimmen.
Wenn Ihre Engine-Versionen identische Patch-Level erfordern, können Sie das Failover manuell durchführen, indem Sie die Schritte unter [Ausführen von manuellen geplanten Failovers für globale Aurora-Datenbanken](aurora-global-database-disaster-recovery.md#aurora-global-database-failover.manual-unplanned) ausführen.
| Datenbank-Engine | Engine-Nebenversionen | Hinweise |
| --- | --- | --- |
| Aurora MySQL | Keine Nebenversionen | Keine der Nebenversionen von Aurora MySQL unterstützt verwaltete regionsübergreifende Umstellungen und Failover, wenn die Patch-Level der primären und sekundären DB-Cluster nicht übereinstimmen. |
| Aurora PostgreSQL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-upgrade.html) | Mit den in der vorherigen Spalte aufgeführten Engine-Versionen können Sie verwaltete regionsübergreifende Umstellungen oder Failover von einem primären DB-Cluster mit einem Patch-Level auf einen sekundären DB-Cluster mit einem anderen Patch-Level durchführen. Bei niedrigeren Nebenversionen können Sie verwaltete regionsübergreifende Umstellungen und Failover nur durchführen, wenn die Patch-Level der primären und sekundären DB-Cluster übereinstimmen. Wenn Sie einen Cluster Ihrer globalen Datenbank auf eine der folgenden Patch-Versionen aktualisieren, können Sie regionsübergreifende Umstellungen oder Failover erst durchführen, wenn alle Cluster in Ihrer globalen Datenbank eine dieser Patch-Versionen oder eine neuere ausführen. Patch-Versionen 16.1.6, 16.2.4, 16.3.2 und 16.4.2 Patch-Versionen 15.3.8, 15.4.9, 15.5.6, 15.6.4, 15.7.2 und 15.8.2 Patch-Versionen 14.8.8, 14.9.9, 14.10.6, 14.11.4, 14.12.2 und 14.13.2 |