Warum dauert die Wiederherstellung meines Aurora-MySQL-kompatiblen DB-Cluster-Snapshots so lange?

Kurzbeschreibung

Der Snapshot-Wiederherstellungsprozess für einen mit Amazon Aurora MySQL kompatiblen DB-Cluster umfasst eine Reihe wichtiger Aufgaben. Während dieses Vorgangs wird beispielsweise ein Aurora-Cluster erstellt, ebenso wie das hochverfügbare Cluster-Volume. Prozesse wie Statusüberprüfung, Speicher- und Hardwarezuweisung und das Schreiben von Datenmengen wirken sich allesamt darauf aus, wie viel Zeit für die Wiederherstellung eines Snapshots benötigt wird.

Die Snapshot-Wiederherstellungszeit wird von einer Reihe von Faktoren beeinflusst:

• Bei Aurora-Clustern wird ein einzelner Cluster auf drei Availability Zones (AZs) verteilt, um eine hohe Verfügbarkeit zu gewährleisten. Wenn der Aurora-Cluster aus dem Snapshot wiederhergestellt wird, stellt er Speicher in diesen drei AZs bereit. Sobald der Cluster verfügbar ist, erstellt er weitere sechs Kopien innerhalb des Cluster-Volumes zum Speichern von Daten. Das Speicher-Volume per Striping ist auf Hunderte Speicherknoten verteilt, die wiederum auf drei verschiedene AZs verteilt sind.
• Nachdem der Aurora-Cluster erstellt wurde, lädt der Cluster Daten von Amazon Simple Storage Solution S3 (Amazon S3) auf die Speicherknoten herunter. Dies tut der Cluster, bevor die Daten verfügbar werden. Im Gegensatz zum Wiederherstellungsprozess für Instances von Amazon Relational Database Service (Amazon RDS) für MySQL findet nach der Wiederherstellung kein Lazy Loading statt.
• Aurora-Wiederherstellungen sind nicht-linear. Sie können also beispielsweise zwei separate Cluster wiederherstellen, einen mit 1 GB Daten und einen anderen mit 10 GB Daten. Die Wiederherstellung des größeren Datensatzes dauert nicht zehnmal so lange, sondern nur etwas länger als die Wiederherstellung des kleineren Datensatzes.
• Zu den weiteren Prozessen im Rahmen der Wiederherstellung gehören Statusüberprüfungen, Speicher- und Hardwarezuweisung sowie das Schreiben von Datenmengen. All diese Prozesse sind zeitaufwändig, müssen aber präzise ausgeführt werden, um eine optimale Leistung zu erzielen.

Lösung

Sie können je nach Anwendungsfall die Cloning-Funktion für einen Aurora-Cluster oder die Backtrack-Funktion verwenden, wenn Sie Änderungen an Ihren Aurora-Datenbanken vornehmen.

Aurora-Cluster-Cloning

Die Verwendung der Cloning-Funktion für einen Aurora-Cluster ist der schnellste Weg, um eine identische Kopie Ihres aktuellen Clusters zu erstellen. Nachdem der geklonte Cluster erstellt wurde, können Sie Ihre Änderungen am geklonten Cluster testen, ohne dass sich dies auf den ursprünglichen Cluster auswirkt. Wenn der Test erfolgreich ist, können Sie Änderungen am ursprünglichen Cluster vornehmen.

Hinweis: Es ist immer noch eine bewährte Methode, einen Snapshot Ihres Clusters zu erstellen, bevor Sie Änderungen an einer Datenbank vornehmen.

Hier sind einige gängige Anwendungsfälle für das Klonen eines vorhandenen Aurora-Clusters:

• Sie möchten mit Änderungen, wie Schemaänderungen oder Änderungen von Parametergruppen, experimentieren und deren Auswirkungen bewerten.
• Sie möchten arbeitsintensive Vorgänge, wie das Exportieren von Daten oder das Ausführen von Analyseabfragen, durchführen.
• Sie möchten eine Kopie eines Produktions-DB-Clusters in einer Nicht-Produktionsumgebung zu Entwicklungs- oder Testzwecken erstellen.

Aurora-Backtracking-Funktion

Sie können für Ihre Aurora-Cluster auch die Backtracking-Funktion verwenden. Mit Backtracking können Sie Fehler schnell rückgängig machen, indem Sie Ihre Daten direkt zurückspulen. Für das Backtracking eines DB-Clusters ist keine Erstellung eines neuen DB-Clusters erforderlich und es dauert daher nur wenige Minuten.

Diese Funktion hat jedoch Einschränkungen. Erstens ist sie nur für Cluster verfügbar, bei denen diese Funktion bei der Erstellung aktiviert wurde. Wenn diese Funktion in Ihrem Cluster also nicht aktiviert ist, müssen Sie eine Snapshot-Wiederherstellung durchführen, um das Backtracking zu aktivieren. Außerdem unterstützt Backtracking keine Binärprotokollreplikation, und die regionsübergreifende Replikation muss deaktiviert werden, bevor Sie Backtracking konfigurieren oder verwenden können. Die Grenze für ein Backtrack-Fenster beträgt 72 Stunden.

Überlegungen

Die Aurora-Cluster-Cloning- und -Backtrack-Funktionen wurden eingeführt, um die Aurora-Wiederherstellungszeit in bestimmten Anwendungsfällen zu verbessern. Das Erstellen regelmäßiger Snapshots ist jedoch immer noch eine bewährte Methode, und dieser Ansatz sollte auch gewählt werden, bevor Sie geplante Änderungen an einer Datenbank vornehmen.

Stellen Sie außerdem sicher, dass zum Zeitpunkt des Snapshots, der Point-in-Time-Wiederherstellung oder des Klonens keine langandauernden Schreibvorgänge in der Quelldatenbank ausgeführt werden. Jede langandauernde DCL, DDL oder DML (offene Schreibtransaktionen) kann sich darauf auswirken, wie viel Zeit benötigt wird, bis die wiederhergestellte Datenbank verfügbar ist.

Ähnliche Informationen

Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster

Backtracking eines Aurora-DB-Clusters

---