Amazon Aurora-Speicher und -Zuverlässigkeit

Im Folgenden können Sie mehr über das Aurora-Speichersubsystem erfahren. Aurora verwendet eine verteilte und gemeinsam genutzte Speicherarchitektur, die ein wichtiger Faktor für Leistung, Skalierbarkeit und Zuverlässigkeit für Aurora-Cluster ist.

Übersicht über Aurora-Speicher

Aurora-Daten werden im Cluster-Volume gespeichert. Hierbei handelt es sich um ein einzelnes, virtuelles Volume, das SSD-Laufwerke verwendet. Ein Cluster-Volume besteht aus Datenkopien, die sich zwischen drei Availability Zones in einer einzelnen AWS-Region befinden. Da Daten automatisch zwischen Availability Zones repliziert werden, bleiben Ihre Daten sehr lange beständig, mit einer geringeren Wahrscheinlichkeit für Datenverlust. Durch diese Replikation wird eine höhere Verfügbarkeit Ihrer Datenbank bei einem Failover sichergestellt. Dies ist möglich, weil die Datenkopien bereits in den anderen Availability Zones vorhanden sind und Datenanfragen für die DB-Instances in Ihrem DB-Cluster weiterhin bearbeitet werden. Die Menge der replizierten Daten ist unabhängig von der Anzahl der DB-Instances in Ihrem Cluster.

Aurora verwendet separaten lokalen Speicher für nicht persistente, temporäre Dateien. Dazu gehören Dateien, die für Zwecke wie das Sortieren großer Datensätze während der Abfrageverarbeitung oder für die Indexerstellung verwendet werden. Weitere Informationen finden Sie unter Temporäre Speicherlimits für Aurora MySQL und Temporäre Speicherlimits für Aurora PostgreSQL.

Inhalt des Cluster-Volumes

Das Aurora-Cluster-Volume enthält all Ihre Benutzerdaten, Schema-Objekte sowie interne Metadaten wie die Systemtabellen und das Binärprotokoll. Beispielsweise speichert Aurora alle Tabellen, Indizes, Binary Large Objects (BLOBs) oder gespeicherte Prozeduren eines Aurora-Clusters im Cluster-Volume.

Die verschiedene Speicherquellen nutzende Architektur von Aurora sorgt dafür, dass Ihre Daten von den DB-Instances im Cluster unabhängig sind. So können Sie eine DB-Instance schnell hinzufügen, weil Aurora keine neue Kopie der Tabellendaten erstellt. Stattdessen stellt die DB-Instance eine Verbindung zum freigegebenen Volume her, das bereits alle Daten von Ihnen enthält. Sie können eine DB-Instance aus einem Cluster entfernen, ohne die zugrunde liegenden Daten aus dem Cluster entfernen zu müssen. Aurora entfernt die Daten nur, wenn Sie den gesamten Cluster löschen.

Wie sich die Größe des Aurora-Speichers automatisch ändert

Aurora-Cluster-Volumes nehmen automatisch an Größe zu, wenn die Datenmenge in Ihrer Datenbank zunimmt. Die maximale Größe für ein Aurora-Cluster-Volumen beträgt je nach Version der DB-Engine 128 Tebibyte (TiB) oder 64 TiB. Weitere Informationen zur maximalen Größe für eine bestimmte Version finden Sie unter Amazon Aurora-Größenbeschränkungen. Diese automatische Speicherskalierung wird mit einem leistungsstarken und hochverteilten Speicher-Subsystem kombiniert. Dadurch ist Aurora eine gute Wahl für Ihre wichtigen Unternehmensdaten, wenn Ihre Hauptziele Zuverlässigkeit und Hochverfügbarkeit sind.

Informationen zum Anzeigen des Volume-Status finden Sie unter Anzeigen des Volume-Status für einen Aurora MySQL-DB-Cluster oder Anzeigen des Volume-Status für einen Aurora PostgreSQL-DB-Cluster. Für Möglichkeiten, die Lagerkosten mit anderen Prioritäten auszugleichen, beschreibt Speicherskalierung, wie die Amazon Aurora-Metriken AuroraVolumeBytesLeftTotal und VolumeBytesUsed in CloudWatch zu überwachen sind.

Wenn Aurora-Daten entfernt werden, wird der für diese Daten zugewiesene Speicherplatz freigegeben. Beispiele für das Entfernen von Daten sind das Löschen oder Abschneiden einer Tabelle. Diese automatische Reduzierung der Speichernutzung hilft Ihnen, Speichergebühren zu minimieren.

Anmerkung

Die hier beschriebenen Speicherlimits und das dynamische Größenanpassungsverhalten gelten für persistente Tabellen und andere Daten, die auf dem Cluster-Volume gespeichert sind. Daten für temporäre Tabellen werden in der lokalen DB-Instance für Aurora PostgreSQL und Aurora MySQL Version 1 gespeichert.

Bei Aurora MySQL Version 2 werden temporäre Tabellendaten standardmäßig auf dem Cluster-Volume für Writer-Instances und im lokalen Speicher für Reader-Instances gespeichert. Weitere Informationen finden Sie unter Speicher-Engine für temporäre Tabellen auf der Festplatte.

Bei Aurora MySQL Version 3 werden temporäre Tabellendaten in der lokalen DB-Instance oder auf dem Cluster-Volume gespeichert. Weitere Informationen finden Sie unter Neues temporäres Tabellenverhalten in Aurora MySQL Version 3.

Die maximale Größe temporärer Tabellen im lokalen Speicher ist durch die maximale lokale Speichergröße der DB-Instance begrenzt. Die lokale Speichergröße hängt von der Instance-Klasse ab, die Sie verwenden. Weitere Informationen finden Sie unter Temporäre Speicherlimits für Aurora MySQL und Temporäre Speicherlimits für Aurora PostgreSQL.

Einige Speicherfunktionen, wie die maximale Größe eines Cluster-Volumes und die automatische Größenanpassung beim Entfernen von Daten, hängen von der Aurora-Version des Clusters ab. Weitere Informationen finden Sie unter Speicherskalierung. Außerdem erfahren Sie, wie Sie Speicherprobleme vermeiden und den zugewiesenen Speicher und freien Speicherplatz in Ihrem Cluster überwachen können.

Informationen zur Abrechnung des Aurora-Datenspeichers

Auch wenn ein Aurora-Cluster-Volume auf bis zu 128 tebibytes (TiB) anwachsen kann, werden Ihnen nur die Kosten für den Speicherplatz berechnet, den Sie in einem Aurora-Cluster-Volume verwenden. In früheren Aurora-Versionen konnte das Cluster-Volume Speicherplatz wiederverwenden, der beim Entfernen von Daten freigegeben wurde, der zugewiesene Speicherplatz nahm jedoch nie ab. Wenn Aurora-Daten jetzt entfernt werden, z. B. durch Löschen einer Tabelle oder Datenbank, verringert sich der insgesamt zugewiesene Speicherplatz um einen vergleichbaren Betrag. So können Sie Speicherkosten senken, indem Sie Tabellen, Indizes, Datenbanken usw. löschen, die Sie nicht mehr benötigen.

Tipp

Bei früheren Versionen ohne die Funktion für die dynamische Größenanpassung muss die Speicherverwendung für einen Cluster zurückgesetzt werden, um einen logischen Dump auszuführen und auf einem neuen Cluster wiederherzustellen. Diese Operation kann bei großen Datenmengen sehr lange dauern. Wenn eine solche Situation auftritt, sollten Sie das Upgrade Ihres Clusters auf eine Version durchführen, die die dynamische Größenanpassung des Volumes unterstützt.

Informationen dazu, welche Aurora-Versionen die dynamische Größenanpassung unterstützen und wie Sie Speicherkosten durch Überwachen der Speichernutzung für Ihren Cluster minimieren können, finden Sie unter Speicherskalierung. Informationen zur Speicherabrechnung von Aurora-Backups finden Sie unter Grundlegendes zur Sicherungsspeicher-Nutzung in Amazon Aurora. Weitere Informationen über die Preise für Aurora-Datenspeicher finden Sie unter Amazon RDS for Aurora: Preise.

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
• Überlebensfähiger Seiten-Cache
• Wiederherstellung nach einem Ausfall

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 Datenverlust und reduziert die Notwendigkeit, eine zeitpunktbezogene Wiederherstellung durchzuführen, um sich von einem Laufwerksausfall zu erholen.

Ü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 als InnoDB-Puffer-Pool in Aurora MySQL und Puffer-Cache in Aurora PostgreSQL bezeichnet.)

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.

Bei Aurora MySQL ist das Verhalten des Seiten-Caches beim Neustart und Failover wie folgt:

• Versionen vor 2.10 – Wenn die Writer-DB-Instance neu gestartet wird, bleibt der Seiten-Cache der Writer-Instance erhalten, während Reader-DB-Instances ihre Seiten-Caches verlieren.

• Version 2.10 und höher – Sie können die Writer-Instance ohne die Reader-Instances neu 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.

Bei Aurora PostgreSQL können Sie die Cluster-Cache-Verwaltung verwenden, um den Seiten-Cache einer bestimmten Reader-Instance beizubehalten, die nach dem Failover zur Writer-Instance wird. Weitere Informationen finden Sie unter Schnelle Wiederherstellung nach Failover mit der Cluster-Cacheverwaltung für Aurora PostgreSQL.

Wiederherstellung nach einem Ausfall

Aurora wurde entwickelt, um sich nach einem Absturz fast augenblicklich zu erholen und Ihre Anwendungsdaten weiterhin ohne das Binärprotokoll bereitzustellen. Aurora führt die Wiederherstellung nach einem Absturz asynchron auf parallelen Threads durch, sodass Ihre Datenbank nach einem Absturz sofort geöffnet und verfügbar ist.

Weitere Informationen über den Wiederherstellungsprozess nach einem Absturz finden Sie unter Fehlertoleranz für einen Aurora-DB-Cluster.

Die folgenden Betrachtungen gelten für eine Binärprotokollierung und die Wiederherstellung nach einem Absturz auf Aurora MySQL:

• Die Aktivierung der Binärprotokollierung auf Aurora wirkt sich direkt auf die Wiederherstellungsdauer nach einem Absturz aus, weil die DB-Instance gezwungen wird, das Binärprotokoll herzustellen.

• 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_format fü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.

• Aurora benötigt die Binärprotokolle nicht, um Daten in einem DB-Cluster zu replizieren oder eine Wiederherstellung zu einem bestimmten Zeitpunkt (PITR, Point in Time Restore) 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_format auf OFF zu 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 über die Auswirkungen der Verwendung unterschiedlicher MySQL-Replikationstypen finden Sie unter Vorteile und Nachteile einer auf Anweisungen und einer auf Zeilen basierenden Replikation in der MySQL-Dokumentation.