Warum dauert es so lange, einen Snapshot meiner Amazon RDS für MySQL-DB-Instance wiederherzustellen?

Kurzbeschreibung

Lange Snapshot-Wiederherstellungszeiten werden in der Regel durch lange Datenbankwiederherstellungen verursacht. Die Wiederherstellungszeit hängt von dem Workload auf Ihrer Instance ab, als der Snapshot erstellt wurde. Wenn für Ihre Quell-DB-Instance die Binärdaten-Protokollierung aktiviert ist, kann die Wiederherstellung länger dauern. Infolgedessen kann sich auch die Dauer Ihrer Snapshot-Wiederherstellung auswirken.

Behebung

Wenn Sie einen Snapshot wiederherstellen, führt Amazon RDS einen Wiederherstellungsprozess durch und die MySQL-DB-Engine wird auf einer neuen DB-Instance gestartet. Der Start der neuen DB-Instance kann je nach Dauer der Wiederherstellungssitzung während eines Instance-Startups bis zu ein paar Minuten dauern. Weitere Informationen finden Sie unter InnoDB-Crash Recovery auf der MySQL-Website.

**Hinweis:**Es kommt zu einer gewissen Latenz (oder verzögertem Laden), bis das Volumen vollständig von Amazon Simple Storage Service (Amazon S3) aufgebraucht ist. Weitere Informationen zu verzögertem Laden finden Sie unter Stellen aus einem Snapshot wiederher.

Um die Dauer der Snapshot-Wiederherstellung in Amazon RDS zu reduzieren, sollten Sie die folgenden Ansätze in Betracht ziehen:

• Planen Sie ein Backup-Fenster ein oder erstellen Sie außerhalb der Spitzenzeiten einen manuellen Snapshot Ihrer DB-Instance. Aktivitäten, die während der Erstellung eines Snapshots auf der Quell-DB-Instance ausgeführt werden, wirken sich auf die Datenbankwiederherstellungszeit und alle Snapshot-Wiederherstellungszeiten aus.
• Wenn eine Quell-Instance während eines Snapshots den magnetischen Speichertyp verwendet, befindet sich die neu wiederhergestellte Instance in einem modifizierenden Zustand. Wenn Sie beispielsweise einen DB-Snapshot als Speichertyp General Purpose SSD (GP2) oder bereitgestellten IOPS (PIOPS) wiederherstellen, erfolgt die zugrunde liegende Volume-Änderung. Aus diesem Grund weist Ihre neue Instance auf einen „ändernden“ Status hin. Während dieser Zeit können Sie immer noch eine Verbindung zu einer Amazon RDS-Instance herstellen, obwohl es zu Leistungseinbußen kommen kann.
• Stellen Sie Ihre Instance vorübergehend auf eine höhere DB-Instance-Klasse zurück (z. B. eine Instance-Klasse mit mehr Arbeitsspeicher oder RAM). Durch ein Upgrade der DB-Instance-Klasse können die Wiederherstellungszeiten nach einem Absturz verbessert werden. Sie gewinnen vorübergehend mehr Ressourcen, was dazu beitragen kann, die gesamte Wiederherstellungszeit nach einem Absturz zu verkürzen. Nachdem die Snapshot-Wiederherstellung abgeschlossen ist, können Sie die Instance-Klasse herunterskalieren.

Um die Dauer der Snapshot-Wiederherstellung für Snapshots mit aktivierter Binärdaten-Protokollierung in Amazon RDS zu reduzieren, sollten Sie Folgendes berücksichtigen:

• Wenn die Binärdaten-Protokollierung aktiviert ist (z. B. wenn für die Quell-Instance automatische Backups aktiviert sind), wirken sich Binärdaten-Protokolle direkt auf die Snapshot-Wiederherstellungszeit aus. Während der Wiederherstellung nach einem Absturz führt der Snapshot-Wiederherstellungsprozess auch eine Wiederherstellung des Binärdaten-Protokolls durch.
• Vermeiden Sie große Transaktionen und große Binlogdateien, um die Wiederherstellungszeiten von Binlogs zu verkürzen. Je mehr Daten in den Binärdaten-Protokollen protokolliert werden, desto mehr Daten muss der Wiederherstellungsprozess während einer Binlog-Wiederherstellung verarbeiten. Dadurch wird die Wiederherstellungszeit verlängert, was auch die Snapshot-Wiederherstellungszeiten erhöht.
• Verwenden Sie, wann immer möglich, die richtige Transaktionsgröße. Große Transaktionen werden gleichzeitig in die Binärdaten-Logdatei geschrieben und nicht auf verschiedene Dateien aufgeteilt. Infolgedessen wird die Binärdaten-Protokollierungsdatei sehr umfangreich, was die Wiederherstellungszeit nach einem Absturz verlängert.
• Die Art des verwendeten Binärdaten-Protokollierungsformats kann sich auch auf die Größe und Effizienz der Wiederherstellung auswirken. Einige Formate (wie die zeilenbasierte Protokollierung) protokollieren mehr Informationen als andere in den Binärdaten-Protokollen. Anweisungen, die eine große Anzahl von Zeilen in einer Tabelle ändern, veranlassen die DB-Engine, Binlogeinträge für jede geänderte Zeile zu generieren. Als Ergebnis erhalten Sie eine große Binlog-Datei. Weitere Informationen zum zeilenbasierten Protokollierungsformat finden Sie unter Verwendung von zeilenbasierter Protokollierung und Replikation auf der MySQL-Website. Weitere Informationen zu den verschiedenen Arten von Binärdaten-Protokollierungsformaten finden Sie auf der MySQL-Website unter Vor- und Nachteile der anweisungsbasierten und zeilenbasierten Replikation.