Instanz wiederherstellen – Übersicht

MySQL   |  PostgreSQL   |  SQL Server

Mit Cloud SQL können Sie Ihre Instanzen aus einer Sicherung oder durch eine Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) wiederherstellen. So können Sie eine Instanz auf einen bestimmten Zeitraum oder Zeitpunkt wiederherstellen, indem Sie die Sicherung entweder in einer vorhandenen Instanz oder 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 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 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 der Quellinstanz werden nicht wiederhergestellt. Alle Flags, die zuvor für die Zielinstanz festgelegt wurden, bleiben nach der Wiederherstellung erhalten.
• Während der Wiederherstellung ist die Zielinstanz nicht für Verbindungen verfügbar. Bestehende Verbindungen werden getrennt.
• Wenn Sie eine Wiederherstellung in einer Instanz mit Lesereplikaten durchführen, müssen Sie alle Replikate löschen und nach Abschluss des Wiederherstellungsvorgangs 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 hat, müssen Sie die Sicherungskonfigurationen nach Abschluss der Wiederherstellung aktualisieren.

Wichtig: Wenn Sie eine Sicherung auf einer vorhandenen Instanz wiederherstellen, muss die Zielinstanz mindestens so viele Rechen- und Arbeitsspeicherressourcen (vCPU und RAM) haben wie die Quellinstanz, aus der die Sicherung erstellt wurde. Wenn Sie eine Sicherung auf einer Instanz mit deutlich weniger Ressourcen wiederherstellen, kann der Wiederherstellungsvorgang aufgrund von Ressourcenbeschränkungen beim Starten und Wiederherstellen der Datenbank fehlschlagen. Möglicherweise werden Fehler wie database failed to start after multiple retries angezeigt.

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 und sie in einer neuen oder vorhandenen Instanz wiederherstellen. 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 – Übersicht.

Wenn Sie eine Instanz mithilfe einer Sicherung wiederherstellen, können Sie Folgendes tun:

• In einer neuen Instanz wiederherstellen
• In 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 sie wiederherzustellen.

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

CMEK-fähige Instanz mit erweiterten Sicherungen wiederherstellen

Wenn Sie CMEK-fähige Instanzen mit erweiterten Sicherungen verwenden, werden Ihre Sicherungen durch denselben CMEK wie die Instanz geschützt. Dies kann ein wichtiger Teil Ihres Sicherungsplans für Instanzen sein, die eine CMEK-Verschlüsselung erfordern, da Ihre CMEK-verschlüsselten Sicherungen in einem separaten Projekt aufbewahrt werden, in dem sie erfolgreich wiederhergestellt werden können, selbst wenn Ihr ursprüngliches Arbeitslastprojekt manipuliert oder gelöscht wird.

Wenn Sie eine erweiterte Sicherung einer CMEK-fähigen Instanz in einer neuen Instanz wiederherstellen, können Sie eine der folgenden Verschlüsselungsoptionen für die neue Instanz auswählen:

• Verwenden Sie denselben Cloud KMS-Schlüssel wie die ursprüngliche Instanz. Dies ist das Standardverhalten.
• Wählen Sie einen anderen Cloud KMS-Schlüssel für die Zielinstanz aus. Wenn Sie einen anderen Schlüssel auswählen möchten, legen Sie das Flag --disk-encryption-key im Wiederherstellungsbefehl fest.
• Setzen Sie die Zielinstanz auf Google-owned and Google-managed encryption keys zurück. Wenn Sie GMEK verwenden möchten, legen Sie im Wiederherstellungsbefehl das Flag --clear-disk-encryption fest.

Wiederherstellung zu einem bestimmten Zeitpunkt

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie Ihre Instanz auf einen bestimmten Stand 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 mithilfe einer Sicherung wird bei der PITR immer eine neue Instanz erstellt. Diese Art der Wiederherstellung kann nicht für eine vorhandene Instanz durchgeführt werden. Die neue Instanz übernimmt die Einstellungen der Quellinstanz, ähnlich wie beim Klonen von Instanzen.

Wenn Sie eine Cloud SQL Enterprise Plus-Instanz erstellen, ist die Wiederherstellung zu einem bestimmten Zeitpunkt standardmäßig aktiviert. Sie müssen die Funktion manuell deaktivieren, wenn Sie sie nicht aktivieren möchten.

Wenn Sie eine Cloud SQL Enterprise-Instanz in der Google Cloud Console erstellen, ist PITR standardmäßig aktiviert. Wenn Sie eine Cloud SQL for MySQL-Instanz mit aktivierter Hochverfügbarkeit erstellen, ist die Wiederherstellung zu einem bestimmten Zeitpunkt ebenfalls standardmäßig aktiviert. Wenn Sie die Instanz mit der gcloud CLI, Terraform oder der Cloud SQL Admin API erstellen, ist PITR standardmäßig deaktiviert. Wenn Sie die PITR für diese Instanzen aktivieren möchten, müssen Sie sie manuell aktivieren.

Hinweis: Um die Instanzerstellung bei aktivierter PITR zu beschleunigen, verwendet Cloud SQL für die PITR einen anfänglichen Sofort-Snapshot anstelle einer Standardsicherung. Dieser Snapshot wird später im Hintergrund in eine Standardsicherung umgewandelt, um Wiederherstellungsvorgänge zu unterstützen.

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 das binäre Logging zum Archivieren von Logs verwendet. Wenn Sie eine vorhandene Instanz mithilfe einer Sicherung wiederherstellen, werden diese Archivlogs gelöscht und sind für eine Wiederherstellung zu einem bestimmten Zeitpunkt nicht mehr verfügbar. Nur neue Logs, die nach Abschluss der Wiederherstellung generiert werden, können für die PITR verwendet werden.

Am 11. August 2023 wurde die Speicherung von Transaktionslogs für die Wiederherstellung zu einem bestimmten Zeitpunkt in Cloud Storage eingeführt. Seit dieser Einführung gelten die folgenden Bedingungen:

• Alle Cloud SQL Enterprise Plus-Instanzen speichern ihre binären 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 11. August 2023 aktiviert hatten, speichern ihre Logs weiterhin auf dem Laufwerk für PITR.

• Cloud SQL Enterprise-Version-Instanzen, die vor dem 11. August 2023 mit aktivierter Wiederherstellung zu einem bestimmten Zeitpunkt erstellt wurden, speichern ihre Protokolle für Wiederherstellung zu einem bestimmten Zeitpunkt weiterhin auf dem Laufwerk.

  Hinweis: Bei Instanzen, die vor dem 11. August 2023 erstellt wurden, wechselt Cloud SQL den Speicherort der für PITR verwendeten Transaktionslogs automatisch. Sie können die gcloud CLI oder die Cloud SQL Admin API verwenden, um zu prüfen, wo Transaktionslogs für Ihre Instanz gespeichert werden.

• Wenn Sie nach dem 11. August 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 Instanz mithilfe eines direkten Upgrades auf Cloud SQL Enterprise Plus-Version aktualisieren.

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

Wenn Ihre Instanz Cloud Storage zum Speichern von Binärlogs verwendet, werden die Logs in derselben Region wie die primäre Instanz gespeichert. Diese Logs werden für die Cloud SQL Enterprise Plus-Version bis zu 35 Tage und für die Cloud SQL Enterprise-Version bis zu 7 Tage gespeichert. Pro Instanz fallen keine zusätzlichen Kosten 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 binäre 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 von Laufwerk zu Cloud Storage wechseln. Weitere Informationen finden Sie unter Transaktionslogspeicher auf Cloud Storage umstellen.

Achtung: Das Verschieben von Transaktionslogs von einem Laufwerk zu Cloud Storage führt zu einer Ausfallzeit von mehreren Minuten und zum Verlust der vorherigen Logs für PITR. Die Ausfallzeit geschieht, weil die Instanzen neu gestartet werden müssen und die Logs gelöscht werden, wenn Sie PITR deaktivieren.

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

• Prüfen Sie die Netzwerkarchitektur der Instanz. 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.

  Achtung: Wenn Sie PITR deaktivieren und wieder aktivieren, werden alle vorhandenen Logs gelöscht und Sie können PITR vor der erneuten Aktivierung nicht ausführen. Wenn Sie die Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren oder deaktivieren möchten, müssen Sie die Datenbank neu starten.

Aufbewahrungsdauer für Logs

Cloud SQL bewahrt Transaktionslogs in Cloud Storage bis zu dem Wert auf, der in der PITR-Konfigurationseinstellung transactionLogRetentionDays festgelegt ist. Dieser kann zwischen 1 und 35 Tagen für Cloud SQL Enterprise Plus-Version und 1 bis 7 Tage für Cloud SQL Enterprise-Version 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 PITR verwendeten binären Logs in Cloud Storage speichert, behält die Instanz auch eine kleinere Anzahl von doppelten binären Logs auf dem Laufwerk, um die Replikation der Logs in Cloud Storage zu ermöglichen. Wenn Sie eine Instanz mit aktivierter PITR erstellen, speichert die Instanz ihre binären Logs für PITR standardmäßig in Cloud Storage. Cloud SQL setzt den Wert der Flags expire_logs_days und binlog_expire_logs_seconds automatisch auf den Wert, der einem Tag entspricht. Das entspricht einem Tag an Logs auf dem Laufwerk.

Für binäre PITR-Logs, die auf dem Laufwerk gespeichert sind, die zu Cloud Storage gewechselt werden oder die bereits zu Cloud Storage gewechselt wurden, speichert Cloud SQL die Logs für den Mindestwert, 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 Binärlogs auf dem Laufwerk gespeichert sind, zu Cloud Storage gewechselt werden oder bereits zu Cloud Storage gewechselt wurden. Wenn Logs auf dem Laufwerk gespeichert werden, kann sich das Ändern der Werte dieser Flags auf das Verhalten der Wiederherstellung zu einem bestimmten Zeitpunkt und auf die Anzahl der Tage auswirken, für die Logs auf dem Laufwerk gespeichert werden. Während der Speicherort des Logs auf Cloud Storage umgestellt wird, können Sie die Flag-Werte nicht ändern. Wir empfehlen außerdem, keinen der Flag-Werte auf 0 zu konfigurieren. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Hinweis: Wenn Ihre Instanz eine große Anzahl binärer Logs auf dem Laufwerk enthält und Sie Speicherplatz sparen möchten, sollten Sie den Wert der folgenden Flags langsam senken:

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

Um Leistungsprobleme zu vermeiden, können Sie beispielsweise den Wert der Flags über mehrere Tage hinweg jeden Tag um einen Tag reduzieren. Daher werden in Cloud SQL nicht alle Binärlogs gleichzeitig gelöscht.

Bei kundenverwalteten Verschlüsselungsschlüssel-Instanzen (CMEK) werden Binärlogs mit der aktuellen Version des CMEK verschlüsselt. Für eine Wiederherstellung ist die neueste Schlüsselversion für alle Tage erforderlich, die im Rahmen des Parameters retained-transaction-log-days aufbewahrt werden.

Logs und Laufwerknutzung

Logs werden regelmäßig generiert und belegen Speicherplatz. Die binären Logs werden automatisch mit der zugehörigen automatischen Sicherung gelöscht. Dies erfolgt, wenn der für transactionLogRetentionDays festgelegte Wert erreicht ist.

Wenn Sie wissen möchten, wie viel Speicherplatz die Binärlogs belegen, prüfen Sie den Messwert bytes_used_by_data_type für die Instanz. Der Wert für den Datentyp binlog gibt die Größe der Binärlogs auf dem Laufwerk zurück. Bei Instanzen, die Transaktionslogs, die für PITR auf dem Laufwerk verwendet werden, speichern, löscht Cloud SQL Daten täglich dauerhaft vom Laufwerk, um die PITR-Einstellung transactionLogRetentionDays zu erfüllen, wie unter Automatische Sicherung und Transaktionslog-Aufbewahrung beschrieben. Wenn Sie jedoch das Flag expire_logs_days oder binlog_expire_logs_seconds auf einen Wert setzen, der niedriger als die Aufbewahrungsdauer für Transaktionslogs ist, kann Cloud SQL die binären Logs früher löschen.

Wenn die Größe der binären Logs für die Instanz ein Problem darstellt:

• Prüfen Sie, ob Ihre Instanz Logs auf dem Laufwerk speichert. Sie können den Speicherort der Logs, die Cloud SQL für PITR verwendet, ohne Ausfallzeit von Laufwerk zu Cloud Storage wechseln, indem Sie die gcloud CLI oder die Cloud SQL Admin API verwenden. Wenn Sie die Cloud SQL Enterprise-Version verwenden, können Sie auch ein Upgrade auf die Cloud SQL Enterprise Plus-Version durchführen, um den Speicherort Ihrer PITR-Logs zu ändern.

• Sie können die Speichergröße der Instanz erhöhen, die erhöhte Speichernutzung der Größe des binären Logs könnte jedoch nur temporär sein.

• Wir empfehlen die Aktivierung der automatischen Speichererweiterung, um unerwartete Speicherplatzprobleme zu vermeiden.

Weitere Informationen zur Wiederherstellung zu einem bestimmten Zeitpunkt finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt.

Nachdem Sie den Speicherort der Transaktionslogs auf Cloud Storage umgestellt haben, können Sie Speicherplatz freigeben, indem Sie die Werte der Flags expire_logs_days oder binlog_expire_logs_seconds reduzieren. Informationen zum Prüfen des Status des Wechsels finden Sie unter Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden. Wenn Sie jedoch zusätzliche Logs auf dem Laufwerk verfügbar machen möchten, z. B. um die binären Logs mit dem Dienstprogramm mysqlbinlog zu durchsuchen , erhöhen Sie die Werte dieser Flags. Cloud SQL speichert Binärlogs auf dem Laufwerk für die Mindestanzahl der Aufbewahrungstage für Transaktionslogs oder die für die Flags festgelegten Werte. Weitere Informationen dazu, wie Logs für die Wiederherstellung zu einem bestimmten Zeitpunkt nach der Umstellung gespeichert werden und wie Sie Speicherplatz freigeben, finden Sie unter Logs nach der Umstellung auf Cloud Storage.

Hinweis: Bei einigen Instanzen, die zwischen Juni 2023 und August 2023 erstellt wurden, werden die Werte der Flags expire_logs_days oder binlog_expire_logs_seconds möglicherweise automatisch auf den Wert von 7 Tagen festgelegt.

Einschränkungen der Wiederherstellung zu einem bestimmten Zeitpunkt

Die folgenden Einschränkungen gelten, 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:

• 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 einen PITR-Vorgang erst ab 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.

• Wenn Sie Logs löschen und Speicherplatz wiederherstellen möchten, können Sie die PITR deaktivieren, ohne sie wieder zu aktivieren. Durch Reduzierung des verwendeten Speicherplatzes wird die Größe des für die Instanz bereitgestellten Laufwerks jedoch nicht verringert.

• Die Logs werden einmal täglich, nicht kontinuierlich gelöscht. Das Festlegen der Logaufbewahrung auf zwei Tage bedeutet, dass mindestens zwei Tage an Logs und höchstens Logs von drei Tagen aufbewahrt werden. Wir empfehlen, die Anzahl der Sicherungen auf eine mehr als die Anzahl von Tagen für die Logaufbewahrung festzulegen.

  Wenn Sie beispielsweise 7 für den Wert des Parameters transactionLogRetentionDays angeben, legen Sie für den Parameter backupRetentionSettings die Anzahl der retainedBackups auf 8 fest.

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 spätesten 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 mit PITR wiederherstellen

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

Nachdem eine Instanz gelöscht wurde, werden die PITR-Logs weiterhin gemäß den Aufbewahrungseinstellungen aufbewahrt, die für die Instanz festgelegt wurden, als sie aktiv war. Die PITR-Logs laufen nach dem Löschen der Instanz gemäß den Aufbewahrungseinstellungen rollierend ab. Der rollierende Zeitraum wird basierend auf der PITR-Aufbewahrungsdauer definiert, die vor dem Löschen für die Instanz festgelegt wurde. Wenn für Ihre Cloud SQL Enterprise Plus-Instanz beispielsweise die PITR-Aufbewahrung auf 14 Tage 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 beibehaltene PITR-Logs in Google Cloud mit den folgenden Feldern identifiziert werden:

• instance_deletion_time
• log_retention_days

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

Das PITR-Wiederherstellungsfenster ist definiert als die frühesten und spätesten Wiederherstellungszeiten, die für die Wiederherstellung Ihrer Instanz mit PITR verfügbar sind. Informationen zum Ermitteln des frühesten und spätesten Wiederherstellungszeitpunkts Ihrer gelöschten Instanz finden Sie unter Frühesten und spätesten Wiederherstellungszeitpunkt abrufen.

Informationen zum Wiederherstellen einer Instanz mithilfe von 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 eine Datenbank der gleichen Version haben wie die Instanz, von der die Sicherung erstellt wurde.

• Beim Erstellen einer neuen Instanz ist das Feature storageAutoResize standardmäßig aktiviert. Alle nachfolgend erstellten Sicherungen übernehmen dieselbe storageAutoResize-Einstellung. Das bedeutet, dass die Speicherkapazität der Instanz bei Bedarf automatisch angepasst wird, unabhängig davon, ob eine Sicherung in einer neuen oder vorhandenen Instanz wiederhergestellt wird. Bei Legacy-Instanzen ist diese Funktion nicht aktiviert. Informationen zum Prüfen Ihrer Instanzeinstellungen finden Sie unter Instanzeinstellungen aufrufen.

• 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 angibt, wann Sie den Vorgang wieder 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 nutzen einen Bucket gemeinsam, wenn sie sich in derselben Region befinden. In jedem Bucket können maximal drei Tokens für Wiederherstellungsvorgänge verwendet werden. 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:

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

• 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

• Daten aus einer Sicherung wiederherstellen
• Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) verwenden