Instanz wiederherstellen – Übersicht

Mit Cloud SQL können Sie Ihre Instanzen aus einer Sicherung oder durch Ausführen einer Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) wiederherstellen. So können Sie eine Instanz für einen bestimmten Zeitraum oder Zeitpunkt wiederherstellen, indem Sie die Sicherung entweder in einer vorhandenen Instanz oder in einer neuen Instanz wiederherstellen. Zum Wiederherstellen 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 eine neue Instanz wiederherstellen, 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 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 eine Sicherung wiederhergestellt haben, werden die Sicherungskonfigurationen der Zielinstanz auf die Standardwerte zurückgesetzt. Wenn Ihre Quellinstanz benutzerdefinierte Sicherungskonfigurationen hatte oder erweiterte Sicherungen verwendet wurden, müssen Sie die Sicherungskonfigurationen nach Abschluss der Wiederherstellung aktualisieren.

Aus einer Sicherung wiederherstellen

Mit Cloud SQL können Sie eine Instanz aus einer Sicherung wiederherstellen. Sie können eine Sicherung einer aktiven oder gelöschten Instanz verwenden, um sie in einer neuen oder vorhandenen Instanz wiederherzustellen. Sie können jede verfügbare Sicherung verwenden, um die Instanz wiederherzustellen. Weitere Informationen zur Funktionsweise von Sicherungen in Cloud SQL finden Sie unter Sicherungen.

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

  • In einer neuen Instanz wiederherstellen
  • Auf einer vorhandenen Instanz wiederherstellen
  • 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 Daten daraus wiederherzustellen.

Informationen zum Wiederherstellen einer Instanz mithilfe einer Sicherung finden Sie unter Instanz mithilfe einer Sicherung wiederherstellen.

Wiederherstellung auf einen bestimmten Zeitpunkt (PITR)

Mit PITR können Sie Ihre Instanz auf einen bestimmten Zeitpunkt der Datenbank zurücksetzen. Wenn beispielsweise ein Fehler zu einem Datenverlust führt, haben Sie die Möglichkeit, genau den Zustand der Datenbank wiederherzustellen, den sie zum Zeitpunkt vor Auftreten des Fehlers hatte. Im Gegensatz zur Wiederherstellung aus einer Sicherung wird bei der PITR immer eine neue Instanz erstellt. Sie können keine PITR 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 PITR standardmäßig aktiviert. Sie müssen die Funktion manuell deaktivieren.

Wenn Sie eine Cloud SQL Enterprise-Instanz in der Google Cloud Konsole erstellen, ist PITR standardmäßig aktiviert. Wenn Sie die Instanz mit der gcloud CLI, Terraform oder der Cloud SQL Admin API erstellen, ist PITR standardmäßig deaktiviert. Um PITR für diese Instanzen zu aktivieren, 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 PITR

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

Am 9. Januar 2023 haben wir die Speicherung von Transaktionslogs für PITR in Cloud Storage eingeführt. Seit der Einführung gelten die folgenden Bedingungen:

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

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

  • Wenn Sie nach dem 9. Januar 2023 eine Cloud SQL Enterprise-Instanz aktualisieren, in der Transaktionslogs für PITR auf dem Laufwerk auf Cloud SQL Enterprise Plus gespeichert werden, wechselt der Upgradeprozess den Speicherort der für PITR verwendeten Transaktionslogs auf Cloud Storage. Weitere Informationen finden Sie unter Upgrade einer Instanz auf Cloud SQL Enterprise Plus mithilfe eines direkten Upgrades ausführen.

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

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

Weitere Informationen zum Prüfen des Speicherorts der für PITR verwendeten Transaktionslogs finden Sie unter Speicherort von Transaktionslogs für Ihre Instanz prüfen.

Bei Instanzen, die Write-Ahead-Logs nur auf dem Laufwerk speichern, können Sie den Speicherort der für PITR verwendeten Transaktionslogs mit der gcloud CLI oder der Cloud SQL Admin API vom Laufwerk zu Cloud Storage ändern. Weitere Informationen finden Sie unter Transaktionsprotokollspeicher auf Cloud Storage umstellen.

Damit die Logs für Ihre Instanz in Cloud Storage statt auf dem Laufwerk gespeichert werden, führen Sie die folgenden Schritte aus:

  • Netzwerkarchitektur der Instanz prüfen Wenn die Instanz die alte Netzwerkarchitektur verwendet, 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 Wiederherstellung zu einem bestimmten Zeitpunkt 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

Cloud SQL behält Transaktionslogs in Cloud Storage bis zu dem Wert bei, der in der PITR-Konfigurationseinstellung transactionLogRetentionDays 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 Aufbewahrungstage für Transaktionslogs finden Sie unter Aufbewahrung von Transaktionslogs festlegen.

Obwohl eine Instanz die für die PITR verwendeten Write-Ahead-Logs in Cloud Storage speichert, werden auch eine kleinere Anzahl von doppelten Write-Ahead-Logs auf dem Laufwerk gespeichert, um die Replikation der Logs in Cloud Storage zu ermöglichen. Wenn Sie eine Instanz mit aktivierter PITR erstellen, speichert die Instanz ihre Write-Ahead-Logs für PITR standardmäßig in Cloud Storage. Cloud SQL legt den Wert der Flags expire_logs_days und binlog_expire_logs_seconds automatisch auf den entsprechenden Wert für einen Tag fest. Das entspricht einem Tag mit Protokollen auf der Festplatte.

Für Write-Ahead-Logs für PITR, die auf dem Laufwerk gespeichert sind, die zu Cloud Storage migriert werden oder die bereits zu Cloud Storage migriert wurden, behält Cloud SQL die Logs für den Mindestwert bei, der für eine der folgenden Konfigurationen festgelegt ist:

  • Die Sicherungskonfigurationseinstellung transactionLogRetentionDays
  • Das Flag expire_logs_days oder das Flag binlog_expire_logs_seconds

Cloud SQL legt keine Werte für diese Flags fest, wenn die Write-Ahead-Logs auf der Festplatte gespeichert werden, zu Cloud Storage gewechselt wird oder bereits zu Cloud Storage gewechselt wurde. Wenn Logs auf der Festplatte gespeichert werden, kann sich das Ändern der Werte dieser Flags auf das Verhalten der PITR-Wiederherstellung und die Anzahl der Tage auswirken, für die Logs auf der Festplatte gespeichert werden. Während der Speicherort für Logs auf Cloud Storage umgestellt wird, können Sie die Flag-Werte nicht ändern. Wir empfehlen auch nicht, einen der beiden Flag-Werte auf 0 zu setzen. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

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

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

Bei vom Kunden verwalteten Verschlüsselungs-Schlüsselinstanzen (Customer-Managed Encryption Key, CMEK) werden Write-Ahead-Logs mit der neuesten Version des CMEK verschlüsselt. Zum Wiederherstellen ist die neueste Schlüsselversion für alle Tage erforderlich, die im Rahmen des Parameters retained-transaction-log-days beibehalten werden.

Einschränkungen der Wiederherstellung zu einem bestimmten Zeitpunkt

Wenn für Ihre Instanz die Wiederherstellung zu einem bestimmten Zeitpunkt aktiviert ist und die Größe Ihrer Transaktionslogs auf dem Laufwerk ein Problem für die Instanz verursacht, gelten die folgenden Einschränkungen:

  • Sie können die Wiederherstellung zu einem bestimmten Zeitpunkt deaktivieren und wieder aktivieren, damit Cloud SQL Logs in Cloud Storage in derselben Region wie die Instanz speichert. Cloud SQL löscht jedoch alle vorhandenen Logs, sodass Sie keine PITR-Operation vor dem Zeitpunkt ausführen können, zu dem Sie PITR 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 PITR aktiviert ist und Ihre Logs auf dem Laufwerk gespeichert sind.

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

Nicht verfügbare Instanz wiederherstellen

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie eine Cloud SQL-Instanz wiederherstellen, die nicht verfügbar ist. Die Wiederherstellung zu einem bestimmten Zeitpunkt bietet in der Regel ein Recovery Point Objective (RPO) von fünf Minuten oder weniger.

Wenn die Instanz nicht verfügbar ist, können Sie mit der API den frühesten und neuesten Wiederherstellungszeitpunkt abrufen, gemäß dem Sie die Instanz wiederherstellen können, und die Wiederherstellung bis zu diesem Zeitpunkt durchführen. Wenn auf die Zone, in der die Instanz konfiguriert ist, nicht zugegriffen werden kann, können Sie die Instanz in einer anderen primären oder sekundären Zone wiederherstellen. Dazu geben Sie Werte für die bevorzugten Zonen an.

Angenommen, eine Cloud SQL-Instanz ist ab 16:00 Uhr EST nicht mehr verfügbar. Wenn der letzte Wiederherstellungszeitpunkt um 15:55 Uhr EST (UTC-5) ist, können Sie die Instanz gemäß diesem Zeitpunkt wiederherstellen.

Gelöschte Instanz mithilfe der Wiederherstellung zu einem bestimmten Zeitpunkt wiederherstellen

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie eine Cloud SQL-Instanz nach dem Löschen wiederherstellen. Damit Sie diese Funktion nutzen können, müssen für Ihre Instanz PITR und beibehaltene Backups aktiviert sein, bevor die Instanz gelöscht wird. Wenn diese Option aktiviert ist, werden PITR-Logs beibehalten, nachdem Sie die Instanz gelöscht haben.

Nachdem eine Instanz gelöscht wurde, richten sich die PITR-Logs weiterhin nach den Aufbewahrungseinstellungen, die für die Instanz festgelegt wurden, als sie aktiv war. Die PITR-Logs laufen nach dem Löschen der Instanz basierend auf den Aufbewahrungseinstellungen ab. Der rollierende Zeitraum wird basierend auf dem PITR-Aufbewahrungszeitraum definiert, der 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 letzte 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 beibehaltene PITR-Logs in Google Cloud anhand der folgenden Felder identifiziert werden:

  • instance_deletion_time
  • log_retention_days

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

Das PITR-Wiederherstellungsfenster wird als frühester und spätester Wiederherstellungszeitpunkt definiert, der für die Wiederherstellung Ihrer Instanz mit PITR verfügbar ist. Informationen zum Ermitteln der frühesten und spätesten Wiederherstellungszeiten für Ihre gelöschte Instanz finden Sie unter Früheste und späteste Wiederherstellungszeit abrufen.

Informationen zum Wiederherstellen einer Instanz mit 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.

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

  • Die Zielinstanz muss den Status RUNNABLE aufweisen.

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