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.
Amazon Aurora-Zuverlässigkeit
Aurora ist darauf ausgelegt, zuverlässig, beständig und fehlertolerant zu sein. Sie können Ihren Aurora-DB-Cluster so gestalten, dass eine bessere Verfügbarkeit erzielt wird, indem Sie beispielsweise Aurora-Replicas hinzufügen und in verschiedenen Availability Zones platzieren. Zudem beinhaltet Aurora mehrere automatische Funktionen, die es zu einer verlässlichen Datenbanklösung machen.
Themen
Automatische Speicherplatzreparatur
Da Aurora mehrere Kopien Ihrer Daten in drei Availability Zones aufbewahrt, sind die Risiken für einen laufwerksbedingten Verlust von Daten stark reduziert. Aurora erkennt automatisch Fehler in den Laufwerk-Volumes, aus denen das Cluster-Volume besteht. Wenn ein Segment eines Laufwerk-Volumes ausfällt, repariert Aurora das Segment umgehend. Wenn Aurora das Laufwerk-Segment repariert, verwendet es die Daten in den anderen Volumes des Cluster-Volumes, um sicherzustellen, dass die Daten im reparierten Segment auf dem aktuellen Stand sind. Dadurch vermeidet Aurora Datenverluste und reduziert die Notwendigkeit, eine point-in-time Wiederherstellung nach einem Festplattenausfall durchzuführen.
Überlebensfähiger Seiten-Cache
Bei Aurora wird der Seiten-Cache jeder DB-Instance in einem von der Datenbank separaten Prozess verwaltetet, was dem Seiten-Cache ermöglicht, unabhängig von der Datenbank zu überleben. (Der Seiten-Cache wird auch InnoDB-Pufferpool auf Aurora My SQL und Puffer-Cache auf Aurora Postgre SQL genannt.)
Im unwahrscheinlichen Fall eines Datenbankausfalls bleibt der Seiten-Cache im Arbeitsspeicher, was aktuelle Datenseiten im Seiten-Cache „warm“ hält, wenn die Datenbank neu gestartet wird. Dies bringt einen Leistungsgewinn, da umgangen werden kann, dass die ersten Abfragen Lese-I/O-Operationen zum „Aufwärmen“ des Seiten-Caches ausführen müssen.
Für Aurora My verhält SQL sich der Seiten-Cache beim Neustart und beim Failover wie folgt:
-
Sie können die Writer-Instance neu starten, ohne die Reader-Instances neu zu starten.
-
Wenn die Reader-Instances beim Neustart der Writer-Instance nicht neu gestartet werden, verlieren sie ihre Seiten-Caches nicht.
-
Wenn die Reader-Instances beim Neustart der Writer-Instance neu gestartet werden, verlieren sie ihre Seiten-Caches.
-
-
Wenn eine Reader-Instance neu gestartet wird, überleben die Seiten-Caches auf den Writer- und Reader-Instances.
-
Wenn der DB-Cluster ein Failover ausführt, wirkt sich dies ähnlich aus wie ein Neustart einer Writer-Instance. Auf der neuen Writer-Instance (zuvor die Reader-Instance) bleibt der Seiten-Cache erhalten, aber auf der Reader-Instance (zuvor der Writer-Instance) überlebt der Seiten-Cache nicht.
Für Aurora Postgre können Sie das Cluster-Cache-Management verwendenSQL, um den Seiten-Cache einer bestimmten Reader-Instance beizubehalten, die nach einem Failover zur Writer-Instance wird. Weitere Informationen finden Sie unter Schnelle Wiederherstellung nach Failover mit der Cluster-Cacheverwaltung für Aurora PostgreSQL.
Wiederherstellung nach ungeplanten Neustarts
Aurora ist für die nahezu umgehende Wiederherstellung nach einem ungeplanten Neustart und die weitere Bereitstellung Ihrer Anwendungsdaten ohne das Binärprotokoll ausgelegt. Aurora führt die Wiederherstellung asynchron auf parallelen Threads durch, sodass Ihre Datenbank nach einem ungeplanten Neustart sofort geöffnet und verfügbar ist.
Weitere Informationen erhalten Sie unter Fehlertoleranz für einen Aurora-DB-Cluster und Optimierungen reduzieren die Neustartzeit der Datenbank.
Im Folgenden finden Sie Überlegungen zur Binärprotokollierung und Wiederherstellung nach einem ungeplanten Neustart auf Aurora MySQL:
-
Die Aktivierung der Binärprotokollierung auf Aurora wirkt sich direkt auf die Wiederherstellungsdauer nach einem ungeplanten Neustart aus, da die DB-Instance gezwungen wird, das Binärprotokoll wiederherzustellen.
-
Der Typ der Binärprotokollierung wirkt sich auf die Größe und die Effizienz der Protokollierung aus. Einige Formate protokollieren dieselbe Menge an Datenbankaktivitäten mehr Informationen in den Binärprotokollen auf als andere. Die folgenden Einstellungen für den Parameter
binlog_formatführen zu unterschiedlichen Mengen an Protokolldaten:-
ROW– die meisten Protokolldaten -
STATEMENT– die wenigsten Protokolldaten -
MIXED– Eine mittlere Menge an Protokolldaten, was normalerweise die beste Kombination von Datenintegrität und Leistung darstellt
Die Menge der Binärprotokolldaten wirkt sich auf die Wiederherstellungszeit aus. Wenn in den Binärprotokollen mehr Daten protokolliert sind, muss die DB-Instance bei der Wiederherstellung mehr Daten verarbeiten, was wiederum die Wiederherstellungsdauer erhöht.
-
-
Um den Rechenaufwand zu reduzieren und die Wiederherstellungszeiten mit der binären Protokollierung zu verkürzen, können Sie das erweiterte Binlog verwenden. Das erweiterte Binlog verbessert die Wiederherstellungszeit der Datenbank um bis zu 99%. Weitere Informationen finden Sie unter Erweitertes Binlog für Aurora My einrichten SQL.
-
Aurora benötigt die Binärprotokolle nicht, um Daten innerhalb eines DB-Clusters zu replizieren oder point-in-time restore (PITR) durchzuführen.
-
Wenn Sie das Binärprotokoll nicht für die externe Replikation (oder einen externen Binärprotokoll-Stream) benötigen, empfehlen wir Ihnen, den Parameter
binlog_formataufOFFzu setzen, um die Binärprotokollierung zu deaktivieren. Dies reduziert die Wiederherstellungsdauer.
Weitere Informationen über die Binärprotokollierung und Replikation in Aurora finden Sie unter Replikation mit Amazon Aurora. Weitere Informationen zu den Auswirkungen der verschiedenen SQL Replikationstypen von My finden Sie in der Dokumentation My unter Vor- und Nachteile der anweisungsbasierten und zeilenbasierten Replikation
