Instanz wiederherstellen – Übersicht

In Cloud SQL können Sie Ihre Instanzen aus einer Sicherung oder durch die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) wiederherstellen. So können Sie eine Instanz zu einem bestimmten Zeitraum oder Zeitpunkt wiederherstellen, indem Sie entweder die Sicherung in einer vorhandenen Instanz wiederherstellen oder die Sicherung in einer neuen Instanz wiederherstellen. Für die Wiederherstellung können Sie die Sicherung einer aktiven oder gelöschten Instanz verwenden. Beim Wiederherstellungsvorgang werden die Einstellungen, Datenbanken und Nutzer der Quellinstanz übernommen und in der von Ihnen ausgewählten Zielinstanz festgelegt.

Wenn Sie die Wiederherstellung in einer neuen Instanz durchführen, kann sich die Zielinstanz in einer anderen Region oder einem anderen Projekt als die Quellinstanz befinden. Die Zielinstanz kann auch eine andere Anzahl von Kernen oder eine andere Menge an Arbeitsspeicher als die Quellinstanz verwenden.

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.

Beachten Sie beim Wiederherstellen einer Instanz Folgendes:

  • Mit der Wiederherstellung werden alle Daten in der Zielinstanz überschrieben.
  • Die Flags aus der Quellinstanz werden nicht wiederhergestellt. Alle Flags, die zuvor für die Zielinstanz festgelegt wurden, werden nach der Wiederherstellung beibehalten.
  • Während der Wiederherstellung ist die Zielinstanz nicht für Verbindungen verfügbar. Bestehende Verbindungen werden getrennt.
  • Wenn Sie die Wiederherstellung in einer Instanz durchführen, 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.
  • Nachdem Sie die Wiederherstellung aus einer Sicherung durchgeführt haben, werden die Sicherungskonfigurationen der Zielinstanz auf die Standardwerte gesetzt. Wenn Ihre Quellinstanz benutzerdefinierte Sicherungskonfigurationen hatte oder erweiterte Sicherungen verwendet wurden, müssen Sie die Sicherungskonfigurationen nach Abschluss der Wiederherstellung aktualisieren.

Wiederherstellung mit einer Sicherung

In Cloud SQL können Sie eine Instanz mit einer Sicherung wiederherstellen. Sie können eine Sicherung aus einer aktiven oder gelöschten Instanz verwenden und sie in einer neuen oder vorhandenen Instanz wiederherstellen. Sie können jede verfügbare Sicherung verwenden, um die Instanz wiederherzustellen. Weitere Informationen zu Sicherungen in Cloud SQL finden Sie unter Übersicht über Sicherungen.

Wenn Sie eine Instanz mit einer Sicherung wiederherstellen, haben Sie folgende Möglichkeiten:

  • In einer neuen Instanz wiederherstellen
  • In einer vorhandenen Instanz wiederherstellen
  • In einer Instanz in einem anderen Projekt oder einer anderen Region wiederherstellen

Im Falle eines Ausfalls können Sie weiterhin eine Liste der Sicherungen in einem bestimmten Projekt abrufen, um die Wiederherstellung durchzuführen.

Informationen zum Wiederherstellen Ihrer Instanz mit einer Sicherung finden Sie unter Instanz mit einer Sicherung wiederherstellen.

Wiederherstellung zu einem bestimmten Zeitpunkt (PITR)

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) können Sie Ihre Instanz zu einem bestimmten Zeitpunkt der Datenbank wiederherstellen. Wenn beispielsweise ein Fehler zu einem Datenverlust geführt hat, haben Sie die Möglichkeit, den Zustand der Datenbank wiederherzustellen, den sie vor dem Auftreten des Fehlers hatte. Im Gegensatz zur Wiederherstellung mit einer Sicherung wird bei der PITR immer eine neue Instanz erstellt. Sie können die PITR nicht für eine vorhandene Instanz durchführen. Die neue Instanz übernimmt die Einstellungen der Quellinstanz, ähnlich wie beim Erstellen eines Klons.

Wenn Sie eine Cloud SQL Enterprise Plus-Instanz erstellen, ist die PITR standardmäßig aktiviert. Sie müssen die Funktion manuell deaktivieren, wenn sie nicht aktiviert sein soll.

Wenn Sie eine Cloud SQL Enterprise-Instanz in der Google Cloud Console erstellen, ist die PITR standardmäßig aktiviert. Wenn Sie die Instanz mit der gcloud CLI, Terraform oder der Cloud SQL Admin API erstellen, ist die PITR standardmäßig deaktiviert. Wenn Sie die PITR für diese Instanzen aktivieren möchten, müssen Sie sie manuell aktivieren.

Eine detaillierte Anleitung zur Durchführung einer PITR finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt verwenden.

Logspeicher für die PITR

Bei der PITR werden Logs mit der WAL-Archivierung (Write-Ahead Logging) archiviert. Wenn Sie eine vorhandene Instanz mit einer Sicherung wiederherstellen, werden diese archivierten Logs gelöscht und sind für die Durchführung einer PITR nicht verfügbar. Nur neue Logs, die nach Abschluss der Wiederherstellung generiert wurden, können für die PITR verwendet werden.

Am 31. Mai 2024 wurde die Speicherung von Transaktionslogs für die PITR in Cloud Storageeingeführt. Seitdem gelten folgende Bedingungen:

  • Alle Cloud SQL Enterprise Plus-Instanzen speichern ihre Transaktionslogs, die für die PITR verwendet werden, in Cloud Storage. Nur Cloud SQL Enterprise Plus-Instanzen, die Sie vor dem 1. April 2024 von der Cloud SQL Enterprise-Version aktualisiert und die PITR vor dem 31. Mai 2024 aktiviert hatten, speichern ihre Logs weiterhin auf dem Laufwerk für die PITR.

  • Cloud SQL Enterprise-Instanzen, die vor dem 31. Mai 2024 mit aktivierter PITR erstellt wurden, speichern ihre Logs weiterhin auf dem Laufwerk für die PITR.

  • Wenn Sie nach dem 31. Mai 2024 eine Cloud SQL Enterprise-Instanz aktualisieren, in der Transaktionslogs für die PITR auf dem Laufwerk auf Cloud SQL Enterprise Plus gespeichert werden, wechselt der Upgradeprozess den Speicherort der für die PITR verwendeten Transaktionslogs auf Cloud Storage. Weitere Informationen finden Sie unter Instanz mithilfe eines direkten Upgrades auf Cloud SQL Enterprise Plus aktualisieren.

  • Alle Cloud SQL Enterprise-Instanzen, die Sie nach dem 31. Mai 2024 mit aktivierter PITR erstellen, speichern Logs, die für die PITR in Cloud Storage verwendet werden.

Wenn Ihre Instanz Cloud Storage zum Speichern von Transaktionslogs verwendet, werden die Logs in derselben Region wie die primäre Instanz gespeichert. Diese Logs werden bis zu 35 Tage lang für Cloud SQL Enterprise Plus und 7 Tage lang für Cloud SQL Enterprise gespeichert. Für diesen Logspeicher fallen keine zusätzlichen Kosten pro Instanz an.

Weitere Informationen zum Prüfen des Speicherorts der für die PITR verwendeten Transaktions logs finden Sie unter Prüfen, wo Transaktionslogs für Ihre Instanz gespeichert sind.

Bei Instanzen, die Transaktionslogs nur auf dem Laufwerk speichern, können Sie den Speicherort der für die PITR verwendeten Transaktionslogs mit der gcloud CLI oder der Cloud SQL Admin API von Laufwerk zu Cloud Storage ändern. Weitere Informationen finden Sie unter Transaktionslogspeicher zu Cloud Storage wechseln.

So sorgen Sie dafür, dass Logs für Ihre Instanz in Cloud Storage statt auf dem Laufwerk gespeichert werden:

  • Prüfen Sie die Netzwerkarchitektur der Instanz. Wenn sich die Instanz in der alten Netzwerkarchitektur befindet, dann führen Sie ein Upgrade auf die neue Netzwerkarchitektur durch.

  • Wenn die Größe Ihrer Logs auf dem Laufwerk Leistungsprobleme für Ihre Instanz verursacht, deaktivieren Sie die PITR und aktivieren Sie sie noch einmal. Dadurch wird sichergestellt, dass neue Logs in Cloud Storage statt auf dem Laufwerk gespeichert werden.

Aufbewahrungsdauer für Logs

In Cloud SQL werden Transaktionslogs in Cloud Storage bis zu dem Wert aufbewahrt, der in der transactionLogRetentionDays PITR-Konfigurationseinstellung festgelegt ist. Dieser kann zwischen 1 und 35 Tagen für Cloud SQL Enterprise Plus und 1 bis 7 Tage für Cloud SQL Enterprise liegen. Wenn für diesen Parameter kein Wert festgelegt ist, beträgt die Standardaufbewahrungsdauer für Transaktionslogs 14 Tage für Cloud SQL Enterprise Plus-Instanzen und 7 Tage für Cloud SQL Enterprise-Instanzen. Weitere Informationen zum Festlegen der Aufbewahrungsdauer für Transaktionslogs finden Sie unter Aufbewahrung von Transaktionslogs festlegen.

Obwohl eine Instanz die für die PITR verwendeten Transaktionslogs in Cloud Storage speichert, werden auch eine kleinere Anzahl doppelter Transaktionslogs auf dem Laufwerk aufbewahrt, um die Replikation der Logs in Cloud Storage zu ermöglichen. Wenn Sie eine Instanz mit aktivierter PITR erstellen, speichert die Instanz standardmäßig ihre Transaktionslogs für die PITR in Cloud Storage. Cloud SQL setzt außerdem den Wert der Flags expire_logs_days und binlog_expire_logs_seconds automatisch auf den Wert für einen Tag. Das entspricht einem Tag Logs auf dem Laufwerk.

Bei PITR-Transaktionslogs, die auf dem Laufwerk gespeichert sind, die zu Cloud Storage verschoben werden oder bereits zu Cloud Storage verschoben wurden , werden die Logs in Cloud SQL für den Mindestwert aufbewahrt, der für eine der folgenden Konfigurationen festgelegt ist:

  • Die Sicherungskonfigurationseinstellung transactionLogRetentionDays
  • Das expire_logs_days oder das binlog_expire_logs_seconds Flag

In Cloud SQL werden keine Werte für diese Flags festgelegt, wenn die Transaktionslogs auf dem Laufwerk gespeichert sind, zu Cloud Storage verschoben werden oder bereits zu Cloud Storage verschoben wurden. Wenn Logs auf dem Laufwerk gespeichert sind, kann das Ändern der Werte dieser Flags das Verhalten der PITR-Wiederherstellung und die Anzahl der Tage beeinflussen, für die Logs auf dem Laufwerk gespeichert werden. Während der Speicherort der Logs zu Cloud Storage verschoben wird, können Sie die Flagwerte nicht ändern. Wir empfehlen außerdem, keinen der Flagwerte auf 0 zu setzen. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

  • Konfigurationseinstellung transactionLogRetentionDays
  • Datenbank-Flag expire_logs_days
  • Datenbank-Flag binlog_expire_logs_seconds

Um Leistungsprobleme zu vermeiden, sollten Sie beispielsweise den Wert der Flags über mehrere Tage hinweg jeden Tag um einen Tag reduzieren. So werden nicht alle Transaktionslogs gleichzeitig in Cloud SQL gelöscht.

Bei vom Kunden verwalteten Verschlüsselungs-Schlüsselinstanzen (Customer-Managed Encryption Key, CMEK), werden Transaktionslogs mit der neuesten Version des CMEK verschlüsselt. Für die Wiederherstellung ist die neueste Schlüsselversion für alle Tage erforderlich, die im Parameter retained-transaction-log-days aufbewahrt werden.

Einschränkungen der PITR

Die folgenden Einschränkungen gelten, wenn die PITR für Ihre Instanz aktiviert ist und die Größe Ihrer Transaktionslogs auf dem Laufwerk ein Problem für Ihre Instanz verursacht:

  • Sie können die PITR deaktivieren und wieder aktivieren, damit Logs in Cloud Storage in derselben Region wie die Instanz gespeichert werden. In Cloud SQL werden jedoch alle vorhandenen Logs gelöscht, sodass Sie die PITR erst wieder ab dem Zeitpunkt ausführen können, zu dem Sie sie wieder aktiviert haben.
  • Sie können die Speichergröße der Instanz erhöhen, die erhöhte Speichernutzung der Größe des Transaktionslogs könnte jedoch nur temporär sein.
  • Damit unerwartete Speicherprobleme vermieden werden, empfehlen wir die Aktivierung von automatischen Speichererweiterungen. Diese Empfehlung gilt nur, wenn für Ihre Instanz die PITR aktiviert ist und Ihre Logs auf dem Laufwerk gespeichert sind.
  • Die Wiederherstellung zu einem bestimmten Zeitpunkt kann für Ihre Zielinstanz Cloud SQL nicht aktiviert werden, wenn sie mehrere Datenbanken mit demselben physischen Namen hat.

Datenbank-Snapshots

Sie können SQL Server-Datenbank-Snapshots nicht für Datenbanken in einer Instanz verwenden, für die die PITR aktiviert ist.

Datenbank-Snapshots können die vollständige Datenbanksicherung und Transaktionslogsicherung beeinträchtigen, auf die die PITR angewiesen ist. Diese Beeinträchtigung kann verhindern, dass PITR-Vorgänge für Datenbanken in der Instanz erfolgreich ausgeführt werden.

Datenbankwiederherstellungsmodell für die PITR

Wenn Sie die PITR für eine Instanz aktivieren, legt Cloud SQL das Wiederherstellungsmodell der vorhandenen und nachfolgenden Datenbanken automatisch auf das vollständige Wiederherstellungsmodell fest.

Weitere Informationen zu SQL Server-Wiederherstellungsmodellen finden Sie in der Microsoft-Dokumentation.

Eine detaillierte Anleitung zur Durchführung einer PITR finden Sie unter [Wiederherstellung zu einem bestimmten Zeitpunkt verwenden][perform-pitr].

Gelöschte Instanz mit der PITR wiederherstellen

Mit der PITR können Sie eine Cloud SQL-Instanz nach dem Löschen wiederherstellen. Damit Sie diese Funktion verwenden können, müssen die PITR und Aufbewahrung von Sicherungen für Ihre Instanz aktiviert sein, bevor die Instanz gelöscht wird. Wenn die PITR aktiviert ist, werden die PITR-Logs nach dem Löschen der Instanz aufbewahrt.

Nachdem eine Instanz gelöscht wurde, gelten für die PITR-Logs weiterhin die Aufbewahrungseinstellungen, die für die Instanz festgelegt wurden, als sie aktiv war. Die PITR-Logs werden nach dem Löschen der Instanz basierend auf den Aufbewahrungseinstellungen nach und nach gelöscht. Der Zeitraum wird basierend auf der PITR-Aufbewahrungsdauer definiert, die für die Instanz vor dem Löschen festgelegt wurde. Wenn für Ihre Cloud SQL Enterprise Plus-Instanz beispielsweise eine PITR-Aufbewahrungsdauer von 14 Tagen festgelegt ist, wird das neueste PITR-Log 14 Tage nach dem Löschen der Instanz gelöscht. Wenn ein PITR-Log abläuft, kann es nicht wiederhergestellt werden.

Da Instanznamen nach dem Löschen einer Instanz in Cloud SQL wiederverwendet werden können, können aufbewahrte PITR-Logs in Cloud Logging mit den folgenden Feldern identifiziert werden: Google Cloud

  • instance_deletion_time
  • log_retention_days

Mithilfe dieser Felder können Sie feststellen, ob ein PITR-Log zu einer gelöschten Instanz gehört.

Der PITR-Wiederherstellungszeitraum wird als frühester und spätester Wiederherstellungszeitpunkt definiert, zu dem Sie Ihre Instanz mit der PITR wiederherstellen können. Informationen zum Ermitteln des frühesten und spätesten Wiederherstellungszeitpunkts für Ihre gelöschte Instanz finden Sie unter Frühesten und spätesten Wiederherstellungszeitpunkt abrufen.

Informationen zum Wiederherstellen einer Instanz mit der PITR nach dem Löschen der Instanz finden Sie unter PITR für eine gelöschte Instanz ausführen.

Anforderungen für die Wiederherstellung in einer neuen Instanz

Wenn Sie Ihre Instanz in einer neuen Instanz wiederherstellen, beachten Sie die folgenden Anforderungen:

  • Die Zielinstanz muss dieselbe Datenbankversion haben wie die gesicherte Instanz.

  • Beim Erstellen einer neuen Instanz ist die Funktion storageAutoResize standardmäßig aktiviert. Alle nachfolgend erstellten Sicherungen übernehmen dieselbe storageAutoResize-Einstellung. Das bedeutet, dass die Speicherkapazität der Instanz bei der Wiederherstellung einer Sicherung in einer neuen oder vorhandenen Instanz nach Bedarf automatisch angepasst wird. Für ältere Instanzen ist diese Funktion nicht aktiviert. Informationen zum Prüfen der Instanzeinstellungen finden Sie unter Instanzeinstellungen ansehen. Diese Anforderung gilt unabhängig davon, ob Sie die PITR einer einzelnen Datenbank machen.

  • Die Zielinstanz muss den Status RUNNABLE haben.

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 er 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.

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