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.
Hohe Verfügbarkeit für Amazon Aurora
Die Amazon-Aurora-Architektur beinhaltet eine Trennung von Speicher und Rechenleistung. Aurora enthält einige Hochverfügbarkeitsfunktionen, die sich auf die Daten in Ihrem DB-Cluster beziehen. Die Daten bleiben auch dann sicher, wenn einige oder alle DB-Instances im Cluster nicht mehr verfügbar sind. Weitere Hochverfügbarkeitsfunktionen gelten für die DB-Instances. Diese Funktionen stellen sicher, dass eine oder mehrere DB-Instances bereit sind, Datenbankanforderungen Ihrer Anwendung zu verarbeiten.
Themen
Hohe Verfügbarkeit für Aurora-Daten
Aurora speichert Kopien der Daten in einem DB-Cluster über mehrere Availability Zones in einer einzigen AWS-Region. Dieser Speichervorgang von Aurora erfolgt unabhängig davon, ob die DB-Instances im DB-Cluster mehrere Availability Zones umfassen. Weitere Informationen zu finden Sie unter Auror Verwalten eines Amazon Aurora-DB-Clusters.
Wenn Daten in die primäre DB-Instance geschrieben werden, repliziert Aurora die Daten synchron über die Availability Zones auf sechs Speicherknoten, die Ihrem Cluster-Volume zugeordnet sind. Auf diese Weise werden eine Datenredundanz erreicht, das Blockieren von I/Os verhindert und Latenzspitzen bei System-Backups minimiert. Wenn Sie eine DB-Instance mit hoher Verfügbarkeit ausführen, kann dies die Verfügbarkeit bei geplanten Systemwartungen verbessern. Außerdem kann dies Ihre Datenbanken bei Ausfällen und bei Nichtverfügbarkeit von Availability Zones schützen. Weitere Informationen über Availability Zones finden Sie unter Regionen und Availability Zones.
Hohe Verfügbarkeit für Aurora-DB-Instances
Nachdem Sie die primäre (Writer–) Instance erstellt haben, können Sie bis zu 15 schreibgeschützte Aurora-Replikate erstellen. Die Aurora-Replikate werden auch als Reader-Instances bezeichnet.
Während des day-to-day Betriebs können Sie einen Teil der Arbeit für leseintensive Anwendungen auslagern, indem Sie die Reader-Instanzen zur Verarbeitung von Abfragen verwenden. SELECT Wenn sich ein Problem auf die primäre Instance auswirkt, übernimmt eine dieser Reader-Instances als primäre Instance. Dieser Mechanismus wird als Failover bezeichnet. Viele Aurora-Funktionen gelten für den Failover-Mechanismus. Beispielsweise erkennt Aurora Datenbankprobleme und aktiviert den Failover-Mechanismus bei Bedarf automatisch. Aurora verfügt jedoch über Funktionen, die die Zeit für den Abschluss des Failovers verkürzen. Dadurch wird die Zeit minimiert, in der die Datenbank während eines Failovers nicht zum Schreiben verfügbar ist.
Aurora wurde für eine schnellstmögliche Wiederherstellung konzipiert. Der schnellste Weg zur Wiederherstellung ist oft ein Neustart oder ein Failover auf dieselbe DB-Instance. Ein Neustart ist schneller und mit weniger Aufwand verbunden als ein Failover.
Um eine Verbindungszeichenfolge zu verwenden, die auch dann unverändert bleibt, wenn ein Failover eine neue primäre Instance heraufstuft, stellen Sie eine Verbindung mit dem Cluster-Endpunkt her. Der Cluster-Endpunkt stellt stets die aktuelle primäre Instance im Cluster dar. Weitere Informationen zum Cluster-Endpunkt finden Sie unter Amazon Aurora Aurora-Endpunktverbindungen.
Tipp
Innerhalb jeder AWS-Region Zone stellen Availability Zones (AZs) Standorte dar, die sich voneinander unterscheiden, um bei Ausfällen für Isolation zu sorgen. Wir empfehlen Ihnen, die primäre Instance und die Reader-Replikate in Ihrem DB-Cluster über mehrere Availability Zones zu verteilen, um die Verfügbarkeit Ihres DB-Clusters zu verbessern. Auf diese Weise verursacht ein Problem, das eine gesamte Availability Zone betrifft, keinen Ausfall für Ihren Cluster.
Sie können einen Multi-AZ-DB-Cluster einrichten, indem Sie bei der Erstellung des Clusters eine einfache Auswahl treffen. Sie können den AWS Management Console AWS CLI, den oder den Amazon verwenden RDSAPI. Sie können auch einen vorhandenen Aurora-DB-Cluster in einen Multi-AZ-DB-Cluster konvertieren, indem Sie eine neue Reader-DB-Instance hinzufügen und eine andere Availability Zone angeben.
Hohe Verfügbarkeit über AWS -Regionen hinweg mit globalen Aurora-Datenbanken
Um eine hohe Verfügbarkeit für mehrere zu AWS-Regionen gewährleisten, können Sie globale Aurora-Datenbanken einrichten. Jede globale Aurora-Datenbank umfasst mehrere AWS-Regionen und ermöglicht so globale Lesevorgänge mit geringer Latenz und Notfallwiederherstellung nach Ausfällen über einen Zeitraum von AWS-Region Aurora übernimmt automatisch die Replikation aller Daten und Updates von der primären AWS-Region in jede der sekundären Regionen. Weitere Informationen finden Sie unter Verwenden von Amazon Aurora Global Databases.
Fehlertoleranz für einen Aurora-DB-Cluster
Ein Aurora-DB-Cluster ist darauf ausgelegt, fehlertolerant zu sein. Das Cluster-Volume erstreckt sich über mehrere Availability Zones (AZs) in einer einzigen AWS-Region, und jede Availability Zone enthält eine Kopie der Cluster-Volume-Daten. Diese Funktionalität bedeutet, dass Ihr DB-Cluster einen Fehler in einer Availability Zone ohne Datenverlust und mit einer nur sehr kurzen Unterbrechung des Services toleriert.
Wenn die primäre Instance in einem DB-Cluster ausfällt, führt ein automatisches Failover auf eine von zwei Arten zu einer neuen primären Instance:
-
Durch das Hochstufen einer bestehenden Aurora-Replica zu einer neuen primären Instance
-
Durch das Erstellen einer neuen primären Instance
Wenn ein DB-Cluster über ein oder mehrere Aurora verfügt, wird eine Aurora-Replica während eines Ausfallereignisses zur primären Instance hochgestuft. Ein Fehlerereignis hat eine kurze Unterbrechung zufolge, während die Lese- und Schreibvorgänge mit einer Ausnahme fehlschlagen. Jedoch wird der Service im Normalfall in weniger als 60 Sekunden und oft sogar schon nach 30 Sekunden wiederhergestellt. Wir empfehlen Ihnen, mindestens ein oder mehrere Aurora Replicas in zwei oder mehreren verschiedenen Availability Zones zu erstellen, um die Verfügbarkeit Ihres DB-Clusters zu erhöhen.
Tipp
In Aurora My SQL 2.10 und höher können Sie die Verfügbarkeit während eines Failovers verbessern, indem Sie mehr als eine Reader-DB-Instance in einem Cluster haben. In Aurora My SQL 2.10 und höher startet Aurora nur die Writer-DB-Instance und die Reader-Instance neu, auf die ein Failover ausgeführt wird. Andere Reader-Instances im Cluster bleiben während eines Failovers verfügbar, um Abfragen über Verbindungen zum Reader-Endpunkt fortzusetzen.
Sie können die Verfügbarkeit auch während eines Failovers verbessern, indem Sie RDS Proxy mit Ihrem Aurora-DB-Cluster verwenden. Weitere Informationen finden Sie unter Hochverfügbarkeit mit Amazon RDS Proxy.
Sie können die Reihenfolge, in der Ihre Aurora Replicas auf die primäre Instance nach einem Ausfall hochgestuft werden, anpassen, indem Sie jedem Replica eine Priorität zuweisen. Prioritäten liegen im Bereich zwischen 0 als höchste Priorität und 15 als niedrigste Priorität. Wenn die primäre Instance ausfällt, RDS stuft Amazon die Aurora Replica mit der höchsten Priorität auf die neue primäre Instance hoch. Sie können die Priorität eines Aurora Replica jederzeit anpassen. Das Ändern der Priorität löst kein Failover aus.
Mehrere Aurora Replicas können dieselbe Priorität haben, was zu Hochstufungsebenen führt. Wenn zwei oder mehr Aurora Replicas dieselbe Priorität haben, RDS bewirbt Amazon das Replikat mit der größten Größe. Wenn zwei oder mehr Aurora Replicas dieselbe Priorität und Größe haben, RDS bewirbt Amazon ein beliebiges Replikat in derselben Promotion-Stufe.
Wenn der DB-Cluster keine Aurora-Replikate hat, wird die primäre Instance bei einem Fehlerereignis in derselben AZ neu erstellt. Ein Fehlerereignis hat eine Unterbrechung zufolge, während die Lese- und Schreibvorgänge mit einer Ausnahme fehlschlagen. Der Service wird wiederhergestellt, wenn die primäre Instance erstellt wird. Dies dauert im Normalfall weniger als 10 Minuten. Das Hochstufen eines Aurora Replicas auf eine primäre Instance funktioniert viel schneller als das Erstellen einer neuen primären Instance.
Angenommen, die primäre Instance in Ihrem Cluster ist aufgrund eines Ausfalls, der sich auf eine gesamte AZ auswirkt, nicht verfügbar. In diesem Fall hängt die Möglichkeit, eine neue primäre Instance online zu stellen, davon ab, ob Ihr Cluster eine Multi-AZ-Konfiguration verwendet.
-
Wenn Ihre bereitgestellten Instances oder Ihr Aurora Serverless v2 Cluster Leser-Instances in anderen enthältAZs, verwendet Aurora den Failover-Mechanismus, um eine dieser Reader-Instances zur neuen primären Instance hochzustufen.
-
Wenn Ihr bereitgestellter oder Aurora Serverless v2-Cluster nur eine einzelne DB-Instance enthält oder wenn sich die primäre Instance und alle Reader-Instances in derselben AZ befinden, müssen Sie manuell eine oder mehrere neue DB-Instances in einer anderen AZ erstellen.
-
Wenn Ihr Cluster Aurora Serverless v1 verwendet, erstellt Aurora automatisch eine neue DB-Instance in einer anderen AZ. Dieser Prozess erfordert jedoch eine Host-Ersetzung und dauert daher länger als ein Failover.
Anmerkung
Amazon Aurora unterstützt auch die Replikation mit einer externen My SQL Database oder einer RDS My SQL DB-Instance. Weitere Informationen finden Sie unter Replikation zwischen Aurora und My SQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation).
Hochverfügbarkeit mit Amazon RDS Proxy
Mit RDS Proxy können Sie Anwendungen erstellen, die Datenbankausfälle transparent tolerieren können, ohne komplexen Code zur Fehlerbehandlung schreiben zu müssen. Der Proxy leitet den Datenverkehr automatisch an eine neue Datenbank-Instance weiter, wobei Anwendungsverbindungen erhalten bleiben. Außerdem werden Domain Name System (DNS) -Caches umgangen, um die Failover-Zeiten für Aurora Multi-AZ-Datenbanken um bis zu 66% zu reduzieren. Weitere Informationen finden Sie unter Amazon RDS Proxy für Aurora verwenden.
