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.
Themen
Ü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 AWS-Region, in der Ihre Daten geschrieben werden, und aus bis zu 10 schreibgeschützten sekundären 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 mithilfe einer dedizierten Infrastruktur in die sekundären AWS-Regionen, wobei die Latenzzeit normalerweise unter einer Sekunde liegt.
Das folgende Diagramm zeigt ein Beispiel für eine globale Aurora-Datenbank, die sich über zwei AWS-Regionen erstreckt.
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 Global Database ist für Anwendungen mit weltweiter Präsenz konzipiert. Die schreibgeschützten sekundären DB-Cluster in mehreren AWS-Regionen unterstützen Lesevorgänge näher an den Anwendungsbenutzern. 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 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.
-
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.
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.
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 Aurora-MySQL- und Aurora-PostgreSQL-Versionen verfügbar. Weitere Informationen finden Sie unter Unterstützte Regionen und DB-Engines für globale Aurora-Datenbanken.
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.
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. 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 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.
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.
-
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. 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.
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.
Informationen zum Upgrade von Aurora Global Database finden Sie unter Aktualisieren einer globalen Datenbank von Amazon Aurora.
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.
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 Writer-DB-Instance der primären AWS-Region neu gestartet wird oder ein Failover erfolgt, werden Reader-DB-Instances in sekundären Regionen ebenfalls 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.
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 unterstützt derzeit nicht den Status
inaccessible-encryption-credentials-recoverable, 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 Beendigungszustandinaccessible-encryption-credentials. Weitere Informationen zu diesen Zuständen finden Sie unter Anzeigen des DB-Clusterstatus.-
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, mit der API-Operation AWS-Managementkonsole, AWS CLI oder
CreateDBCluster-API-Operation aus diesem Cluster einen sekundären 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.
