Verwenden von Amazon Aurora Global Databases

Globale Amazon-Aurora-Datenbanken umfassen mehrere AWS-Regionen, was globale Lesevorgänge mit niedriger Latenz ermöglicht und eine schnelle Wiederherstellung nach einem seltenen Ausfall ermöglicht, der sich auf ein gesamtes auswirken könnte AWS-Region. Eine globale Aurora-Datenbank hat einen primären DB-Cluster in einer Region und bis zu fünf sekundäre DB-Cluster in verschiedenen Regionen.

Themen

• Übersicht über Amazon Aurora Global Databases
• Vorteile von Amazon Aurora Global Databases
• Verfügbarkeit von Regionen und Versionen
• Einschränkungen von globalen Amazon Aurora-Datenbanken
• Erste Schritte mit globalen Amazon-Aurora-Datenbanken
• Verwalten einer Amazon Aurora Global Database
• Herstellen einer Verbindung mit einer Amazon Aurora Global Database
• Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank
• Verwenden von Umstellung oder Failover in einer Amazon Aurora Global Database
• Überwachung einer Amazon Aurora Global Database
• Verwenden von globalen Amazon-Aurora-Datenbanken mit anderen AWS-Services
• Aktualisieren einer Amazon Aurora Global Database

Übersicht über Amazon Aurora Global Databases

Durch die Verwendung einer globalen Amazon-Aurora-Datenbank können Sie Ihre global verteilten Anwendungen mit einer einzigen Aurora-Datenbank ausführen, die mehrere AWS-Regionen umfasst.

Eine globale Aurora-Datenbank besteht aus einer primären AWS-Region , in die Ihre Daten geschrieben werden, und bis zu fünf schreibgeschützten sekundären AWS-Regionen. Schreibvorgänge erfolgen direkt auf den primären DB-Cluster in der primären AWS-Region. Aurora repliziert Daten AWS-Regionen mithilfe einer dedizierten Infrastruktur auf den sekundären Cluster, wobei die Latenz normalerweise unter einer Sekunde liegt.

Im folgenden Diagramm finden Sie ein Beispiel für eine globale Aurora-Datenbank, die sich über zwei erstreckt AWS-Regionen.

Sie können jeden sekundären Cluster unabhängig hochskalieren, indem Sie eine oder mehrere Aurora-Replicas (schreibgeschützte Aurora-DB-Instances) zum Verarbeiten schreibgeschützter Workloads hinzufügen.

Nur der primäre Cluster führt Schreibvorgänge aus. Clients, die Schreibvorgänge ausführen, stellen eine Verbindung mit dem DB-Cluster-Endpunkt des primären DB-Clusters her. Wie im Diagramm dargestellt, verwendet die globale Aurora-Datenbank für die Replikation das Cluster-Speichervolume und nicht die Datenbank-Engine. Weitere Informationen hierzu finden Sie unter Übersicht über Amazon-Aurora-Speicher.

Globale Aurora-Datenbanken sind für Anwendungen mit weltweiter Präsenz konzipiert. Mit den schreibgeschützten sekundären DB-Clustern (AWS-Regionen) können Sie Lesevorgänge näher an Anwendungsbenutzern unterstützen. Mit dem Feature zur Schreibweiterleitung können Sie globale Aurora-Datenbanken 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.

Eine globale Aurora-Datenbank unterstützt je nach Szenario zwei verschiedene Operationen zum Ändern der Region Ihres primären DB-Clusters: globale Datenbank-Umstellung und globales Datenbank-Failover.

• Verwenden Sie für geplante operative Verfahren wie die regionale Rotation die globale Datenbank-Umstellung (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.

• Um Ihre globale Aurora-Datenbank nach einem Ausfall in der primären Region wiederherzustellen, verwenden Sie das globale Datenbank-Failover. Mit dieser Funktion führen Sie ein Failover ihres primären DB-Clusters auf eine andere Region durch (regionsübergreifendes Failover). Weitere Informationen hierzu finden Sie unter Ausführen von verwalteten geplanten Failovers für globale Aurora-Datenbanken.

Vorteile von Amazon Aurora Global Databases

Durch die Verwendung globaler Aurora-Datenbanken profitieren Sie von folgenden Vorteilen:

• Globale Lesevorgänge mit lokaler Latenz – Wenn Sie Niederlassungen auf der ganzen Welt haben, können Sie eine globale Aurora-Datenbank 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 (Aurora-Replikate) hinzufügen. Der sekundäre Cluster ist schreibgeschützt und kann daher bis zu 16 schreibgeschützte Aurora-Replica-Instances anstelle dem üblichen Limit von 15 für einen einzelnen Aurora-Cluster unterstützen.

• Schnelle Replikation von primären zu sekundären Aurora-DB-Clustern – Die von einer Aurora globalen Datenbank 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 und globalen Datenbanken finden Sie unter Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken.

Einschränkungen von globalen Amazon Aurora-Datenbanken

Für globale Aurora-Datenbanken gelten aktuell die folgenden Einschränkungen:

• Globale Aurora-Datenbanken sind in bestimmten AWS-Regionen und nur für bestimmte Aurora MySQL- und Aurora PostgreSQL-Versionen verfügbar. Weitere Informationen finden Sie unter Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken.

• Globale Aurora-Datenbanken haben bestimmte Konfigurationsanforderungen für unterstützte Aurora-DB-Instance-Klassen, eine maximale Anzahl von AWS-Regionen usw. Weitere Informationen finden Sie unter Anforderungen an die Konfiguration einer Amazon Aurora globalen Datenbank.

• Für Aurora MySQL mit MySQL 5.7-Kompatibilität erfordern globale Aurora-Datenbankumstellungen Version 2.09.1 oder eine höhere Nebenversion.

• Sie können verwaltete regionsübergreifende Umstellungen oder Failovers für eine globale Aurora-Datenbank nur durchführen, wenn die primären und sekundären DB-Cluster dieselben Engine-Haupt-, Neben- und Patch-Level-Versionen haben. Die Patch-Level können jedoch unterschiedlich sein, wenn es sich bei den Nebenversionen der Engine um eine der folgenden Versionen handelt.

  Datenbank-Engine	Engine-Nebenversionen
  Aurora PostgreSQL	Version 14.5 und höhere Unterversionen Version 13.8 und höhere Unterversionen Version 12.12 und höhere Unterversionen Version 11.17 und höhere Unterversionen

  Weitere Informationen finden Sie unter Patch-Level-Kompatibilität für verwaltete regionsübergreifende Umstellungen und Failovers.

• Globale Aurora-Datenbanken unterstützen derzeit die folgenden Aurora-Funktionen nicht:

  • Aurora Serverless v1

  • Rückverfolgung in Aurora

• Einschränkungen bei der Verwendung der RDS-Proxy-Funktion mit globalen Datenbanken finden Sie unter Einschränkungen für RDS Proxy mit globalen Datenbanken.

• Die automatische Aktualisierung von Unterversionen gilt nicht für Aurora-MySQL- und Aurora-PostgreSQL-Cluster, die Teil einer globalen Aurora-Datenbank sind. Beachten Sie, dass Sie diese Einstellung für eine DB-Instanz angeben können, die Teil eines globalen Datenbank-Clusters ist, aber die Einstellung hat keine Auswirkungen.

• Globale Aurora-Datenbanken unterstützen derzeit kein Aurora Auto Scaling für sekundäre DB-Cluster.

• Um Datenbankaktivitäts-Streams in globalen Aurora-Datenbanken zu verwenden, auf denen Aurora MySQL 5.7 ausgeführt wird, muss die Engine-Version Version 2.08 oder höher sein. Hinweise zu Datenbankaktivitäts-Streams finden Sie unter Überwachung von Amazon Aurora mithilfe von Datenbankaktivitätsstreams.

• Für den Upgrade von globalen Aurora-Datenbanken 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.

  • 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.

  • Mit einer globalen Aurora-Datenbank, die auf Aurora MySQL basiert, können Sie kein Hauptversions-Upgrade von 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.

  Informationen zum Upgrade einer globalen Aurora-Datenbank finden Sie unter Aktualisieren einer Amazon Aurora Global Database.

• Sie können die Aurora-DB-Cluster in Ihrer globalen Aurora-Datenbank nicht einzeln anhalten oder starten. Weitere Informationen hierzu finden Sie unter Stoppen und Starten eines Amazon Aurora-DB-Clusters.

• Aurora Replicas, die mit dem sekundären Aurora-DB-Cluster verbunden sind, können unter bestimmten Umständen neu gestartet werden. Wenn die Writer-DB- AWS-RegionInstance des primären neu gestartet wird oder ein Failover durchführt, werden Aurora-Replikate in sekundären Regionen ebenfalls neu gestartet. Der sekundäre Cluster ist erst dann verfügbar, wenn alle Replikate 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.

  Stellen Sie sicher, dass Sie die Auswirkungen auf Ihre globale Aurora-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.

• Globale Aurora-Datenbanken unterstützen derzeit den inaccessible-encryption-credentials-recoverable Status nicht, 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.

• Aurora-PostgreSQL-basierte DB-Cluster, die in einer globalen Aurora-Datenbank ausgeführt werden, haben folgende Einschränkungen:

  • Die Verwaltung des Cluster-Cache wird für Aurora-PostgreSQL-DB-Cluster, die Teil der globalen Aurora-Datenbanken sind, nicht unterstützt.

  • Wenn der primäre DB-Cluster Ihrer Aurora globalen Datenbank auf eine, Replikat einer Amazon-RDS-PostgreSQL-Instance basiert, können Sie keinen sekundären Cluster erstellen. Versuchen Sie nicht, mithilfe der AWS Management Console, der AWS CLIoder der CreateDBCluster-API-Operation aus diesem Cluster ein sekundäres 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 Aurora-Datenbanken erstellen, indem Sie dieselbe Version der Aurora-DB-Engine wie für den primären Cluster verwenden. Weitere Informationen finden Sie unter Erstellen einer Amazon Aurora Global Database.