Instanz wiederherstellen

Diese Seite enthält Informationen, die Sie kennen sollten, bevor Sie eine Instanz aus einer Sicherung wiederherstellen oder eine Wiederherstellung zu einem bestimmten Zeitpunkt (Point-In-Time Recovery, PITR) ausführen.

Was geschieht während der Wiederherstellung?

Wenn Sie eine Instanz wiederherstellen, werden die folgenden Daten aus der primären Instanz in der neuen Instanz wiederhergestellt:

  • Datenbanken
  • Nutzer

Durch den Wiederherstellungsvorgang wird die Instanz neu gestartet.

Wiederherstellung zu einem bestimmten Zeitpunkt

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) können Sie eine Instanz auf einem bestimmten Stand wiederherstellen. Wenn beispielsweise ein Fehler zu einem Datenverlust geführt hat, haben Sie die Möglichkeit, genau den Zustand der Datenbank wiederherzustellen, den sie zum Zeitpunkt vor Auftreten des Fehlers hatte.

PITR erstellt immer eine neue Instanz. Sie können keine PITR mit einer vorhandenen Instanz ausführen. Die neue Instanz übernimmt die Einstellungen der Quellinstanz, ähnlich wie beim Klonen von Instanzen. Damit die neue Instanz diese Einstellungen jedoch übernehmen kann, muss der Status der Instanz RUNNABLE sein.

Cloud SQL verwendet Transaktionslogs für PITR. Wenn Sie PITR für eine Instanz aktivieren und die Instanz dann aus einer Sicherung wiederherstellen, löscht Cloud SQL die Transaktionslogs, mit denen Sie PITR aus der wiederhergestellten Instanz verwenden können.

Führen Sie folgende Aktionen aus, um sicherzustellen, dass die Logs für Ihre Instanz in Cloud Storage statt auf dem Laufwerk gespeichert werden:

Eine Schritt-für-Schritt-Anleitung zum Durchführen der Wiederherstellung zu einem bestimmten Zeitpunkt finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt verwenden.

Allgemeine Tipps zur Wiederherstellung

Wenn Sie eine Instanz aus einer Sicherung wiederherstellen, sei es in derselben Instanz oder in einer anderen Instanz, sollten Sie Folgendes beachten:

  • Mit der Wiederherstellung werden alle Daten in der Zielinstanz überschrieben.
  • Während der Wiederherstellung ist die Zielinstanz nicht für Verbindungen verfügbar. Bestehende Verbindungen werden getrennt.
  • Wenn Sie eine Instanz wiederherstellen, die Lesereplikate hat, müssen Sie alle Replikate löschen und nach Abschluss der Wiederherstellung neu erstellen.
  • Durch den Wiederherstellungsvorgang wird die Instanz neu gestartet.

Eine detaillierte Anleitung, wie Sie eine Wiederherstellung ausführen, finden Sie unter:

Tipps und Anforderungen zur Wiederherstellung in einer anderen Instanz

Beachten Sie zum Wiederherstellen einer Sicherung auf einer anderen Instanz die folgenden Einschränkungen und Best Practices:

  • Die Zielinstanz muss eine Datenbank der gleichen Version haben wie die Instanz, von der die Sicherung erstellt wurde.

  • Cloud SQL setzt die Speicherkapazität der Zielinstanz immer auf den Höchstwert der Größe des konfigurierten Laufwerks und des Sicherungslaufwerks. Das Sicherungslaufwerk ist die Größe des Laufwerks zum Zeitpunkt der Sicherung.

  • Die Speicherkapazität der Zielinstanz muss mindestens so groß sein wie die Kapazität der Instanz, die gesichert wird. Der tatsächlich genutzte Speicher spielt dabei keine Rolle. Die Speicherkapazität der Instanz können Sie in der Console auf der Seite Cloud SQL-Instanzen einsehen. Diese Anforderung gilt unabhängig davon, ob Sie die PITR einer einzelnen Datenbank machen.

  • Die Zielinstanz muss den Status RUNNABLE haben.

  • Die Zielinstanz und die gesicherte Instanz können sich in der Anzahl der Kerne oder dem verfügbaren Speicherplatz unterscheiden.

  • Die Zielinstanz kann sich in einer anderen Region als die Quellinstanz befinden.

  • Während eines Ausfalls können Sie weiterhin eine Liste der Sicherungen in einem bestimmten Projekt abrufen. Weitere Informationen finden Sie unter Sicherungen während eines Ausfalls ansehen.

Einschränkungen der Wiederherstellungsrate

Es sind maximal drei Wiederherstellungsvorgänge alle 30 Minuten pro Instanz, Region und Projekt möglich. Wenn ein Wiederherstellungsvorgang fehlschlägt, wird es nicht auf dieses Kontingent angerechnet. Wenn Sie das Limit erreichen, schlägt der Vorgang mit einer Fehlermeldung fehl, die Sie darüber informiert, wann Sie den Vorgang noch einmal ausführen können.

Sehen wir uns nun an, wie Cloud SQL die Ratenbegrenzung für Wiederherstellungen ausführt.

Cloud SQL verwendet Tokens aus einem Bucket, um zu ermitteln, wie viele Wiederherstellungsvorgänge gleichzeitig verfügbar sind. Für jede Sicherung gibt es für jedes Zielprojekt und jede Zielregion eine Bucket. Die Zielinstanzen aus demselben Projekt teilen einen Bucket, wenn sie sich in derselben Region befinden. Jeder Bucket kann maximal drei Tokens enthalten, die Sie für Wiederherstellungsvorgänge verwenden können. Alle 10 Minuten wird dem Bucket ein neues Token hinzugefügt. Wenn der Bucket voll ist, läuft das Token über.

Jedes Mal, wenn Sie einen Wiederherstellungsvorgang ausführen, wird ein Token aus dem Bucket gewährt. Wenn der Vorgang erfolgreich ist, wird das Token aus dem Bucket entfernt. Wenn der Vorgang fehlschlägt, wird das Token an den Bucket zurückgegeben. Dies wird im folgenden Diagramm veranschaulicht:

Funktionsweise von Tokens

In der folgenden Abbildung sind beispielsweise Backup1, Backup2 und Backup3 die Sicherungen derselben Quellinstanz.

Tokens für die Begrenzung der Wiederherstellungsrate

  • Jede Sicherung (Backup1, Backup2 und Backup3) hat einen eigenen Bucket mit Tokens für Wiederherstellungsvorgänge, die auf verschiedene Instanzen in Projekt 1 in Region A (Bucket11A, Bucket21A und Bucket31A) ausgerichtet sind. Da jede Sicherung einen eigenen Bucket hat, können Sie jede Sicherung dreimal alle 30 Minuten wiederherstellen.
  • Jede Sicherung hat einen Bucket für ein separates Projekt und für eine separate Region. Wenn es beispielsweise fünf Projekte in einer Region gibt, gibt es fünf Buckets für diese Sicherung in dieser Region, einer in jedem Projekt. In der vorherigen Abbildung haben wir zwei Projekte in Region A: Projekt 1 und Projekt n.
    • Backup1 hat zwei Buckets mit Tokens für Wiederherstellungsvorgänge in Region A. Einen Bucket für Projekt 1 (Bucket11A) und einen Bucket für Projekt n (Bucket1nA).
    • In ähnlicher Weise hat Backup3 zwei Buckets für Wiederherstellungsvorgänge in Region A. Eine für Projekt 1 (Bucket31A) und eine für Projekt n (Bucket3nA).
  • Backup3 hat einen Bucket in Region B für Projekt1, da alle Instanzen im selben Zielprojekt und in derselben Zielregion einen Bucket gemeinsam nutzen.

Nächste Schritte