Warum dauert mein Amazon Aurora-DB-Cluster-Klon-, meine Snapshot-oder meine Point-in-Time-Wiederherstellung so lange?

Kurzbeschreibung

Die kontinuierlichen Sicherungs- und Wiederherstellungstechniken von Amazon Aurora sind optimiert, um Schwankungen der Wiederherstellungszeiten zu vermeiden. Sie tragen zudem dazu bei, dass das Speichervolumen des Clusters die volle Leistung erreicht, sobald der Cluster verfügbar ist. Lange Wiederherstellungszeiten werden im Allgemeinen durch lang andauernde Transaktionen in der Quelldatenbank zum Zeitpunkt der Erstellung des Backups verursacht.

Lösung

**Hinweis:**Wenn Sie beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehler erhalten, stellen Sie sicher, dass Sie die neueste AWS CLI-Version verwenden.

Amazon Aurora sichert die Änderungen Ihres Cluster-Volumens automatisch und kontinuierlich. Die Backups werden für die Dauer Ihres Backup-Aufbewahrungszeitraums aufbewahrt. Dieses kontinuierliche Backup ermöglicht es Ihnen, Ihre Daten in einem neuen Cluster zu einem beliebigen Zeitpunkt innerhalb des angegebenen Aufbewahrungszeitraums wiederherzustellen. Dadurch wird die Notwendigkeit eines langwierigen Binlog-Roll-Forward-Prozesses vermieden. Da Sie einen neuen Cluster erstellen, werden hierdurch keine Beeinträchtigungen der Leistung oder Störungen Ihrer ursprünglichen Datenbank verursacht.

Wenn Sie eine Clone-, Snapshot- oder Point-in-Time-Wiederherstellung initiieren, ruft der Amazon Relational Database Service (Amazon RDS) in Ihrem Namen die folgenden APIs auf:

• Entweder RestoreDBClusterFromSnapshot oder RestoreDBClusterToPointInTime. Diese APIs erstellen einen neuen Cluster und stellen das Volumen aus dem Amazon Simple Storage Service (Amazon S3) wieder her. Dies kann einige Stunden in Anspruch nehmen. Wenn Sie Daten in einem Aurora-Cluster wiederherstellen, werden alle Daten parallel von Amazon S3 auf die sechs Kopien in Ihren drei Availability Zones übertragen.
• Das Klonen von Cluster-Speichervolumina ist eine Variante von RestoreDBClusterToPointInTime. Hierbei wird das Copy-on-Write-Protokoll verwendet und der Vorgang ist normalerweise in wenigen Minuten abgeschlossen.

Wenn dieser Schritt abgeschlossen ist, wechselt der Cluster in den Status Verfügbar. Sie können Ihren Cluster-Status überprüfen, indem Sie die Konsole aktualisieren oder mithilfe der AWS CLI eine Abfrage durchführen.

Der Instance-Erstellungsprozess beginnt erst, wenn der Cluster verfügbar ist. Dieser erfolgt in zwei Schritten: Einrichtung der Instance-Konfiguration und Datenbank-Crash-Recovery.

Sie können überprüfen, ob die API die Einrichtung der Instance abgeschlossen hat, indem Sie nach der MySQL-Fehlerprotokolldatei suchen. Dies ist selbst dann möglich, wenn sich die Instance im Status Creating befindet. Wenn die Fehlerprotokolldatei zum Herunterladen verfügbar ist, ist die Instance eingerichtet und die Engine führt nun die Crash-Recovery durch. Die Fehlerprotokolldatei ist zusammen mit den Amazon CloudWatch-Metriken zudem die beste Ressource, um den Fortschritt der Datenbank-Crash-Recovery zu überprüfen.

Hinweis: Wenn Sie die AWS-CLI oder API verwenden, um einen Wiederherstellungsvorgang durchzuführen, müssen Sie den Aufruf CreateDBInstance auslösen, da dieser nicht automatisch erfolgt.

Suchen Sie in der Quelldatenbank nach lang andauernden Schreibvorgängen

Es hat sich bewährt, sicherzustellen, dass zum Zeitpunkt des Snapshots, Point-in-Time oder Clones keine lang andauernden Schreibvorgänge in der Quelldatenbank vorliegen. Jede DCL-, DDL- oder DML-Ausführung (offene Schreibtransaktionen) mit langer Laufzeit kann die Zeit erhöhen, die benötigt wird, bis die wiederhergestellte Datenbank verfügbar ist.

Wenn Sie beispielsweise das Binärprotokoll für einen Aurora-Cluster aktivieren, erhöht sich hierdurch die Zeit, die für die Durchführung einer Wiederherstellung benötigt wird. Dies liegt daran, dass InnoDB die Protokolle automatisch überprüft und einen Roll-Forward der Datenbank bis zum aktuellen Zeitpunkt durchführt. Anschließend werden alle Transaktionen, die zum Zeitpunkt der Wiederherstellung noch nicht abgeschlossen waren, rückgängig gemacht. Weitere Informationen zur InnoDB-Crash-Recovery finden Sie unter Innodb-Wiederherstellung.

Wenn die Instance die Erstellungs- und Wiederherstellungsprozesse abgeschlossen hat, sind der Cluster und die Instance bereit, eingehende Verbindungen anzunehmen.

Hinweis: Aurora benötigt das Binärprotokoll nicht. Es ist eine bewährte Methode, dieses zu deaktivieren, sofern es nicht erforderlich ist. Für die regionsübergreifende Replikation können Sie stattdessen die globalen Aurora-Datenbanken auswerten. Die globalen Aurora-Datenbanken benötigen ebenfalls keine Binärprotokolle.

Ähnliche Informationen

Speicher und Zuverlässigkeit von Amazon Aurora

Wiederherstellung aus einem DB-Cluster-Snapshot