Wiederherstellung zu einem bestimmten Zeitpunkt verwenden

Auf dieser Seite wird gezeigt, wie Sie mit der Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) Ihre primäre Cloud SQL-Instanz wiederherstellen.

Weitere Informationen zu PITR finden Sie unter PITR.

Standardmäßig ist PITR aktiviert, wenn Sie eine Cloud SQL Enterprise Plus-Instanz erstellen, unabhängig davon, ob Sie die Instanz mit der Google Cloud Console, der gcloud CLI, Terraform oder Cloud SQL Admin API verwenden.

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

Logspeicher für PITR

Cloud SQL verwendet binäre Logs für PITR.

Am 11. August 2023 haben wir das Speichern von Transaktionslogs für PITR 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-Instanzen, die vor dem 11. August 2023 mit aktivierter PITR erstellt wurden, speichern ihre Logs für PITR weiterhin auf dem Laufwerk.
  • Wenn Sie nach dem 1. April 2024 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 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.

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

Bei Instanzen, die Binärlogs nur auf dem Laufwerk speichern, können Sie die Logs auch vom Laufwerk in Cloud Storage verschieben. Dazu müssen Sie zuerst PITR deaktivieren und dann wieder aktivieren.

Aufbewahrungsdauer für Logs

Cloud SQL speichert Transaktionslogs in Cloud Storage bis zu dem Wert, 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 Aufbewahrungsdauer der Transaktionslogs finden Sie unter Aufbewahrung von Transaktionslogs festlegen.

Obwohl eine Instanz die für PITR verwendeten binären Logs in Cloud Storage speichert, speichert die Instanz auch eine kleinere Anzahl doppelter binärer Logs auf dem Laufwerk, um die Replikation der Logs in Cloud Storage zu ermöglichen. Wenn Sie eine Instanz mit aktiviertem PITR erstellen, speichert die Instanz standardmäßig ihre binären Logs für 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 eines Tages. Das entspricht einem Tag Logs auf dem Laufwerk.

Durch die Reduzierung der Werte dieser Flag-Einstellungen können Sie mit Cloud SQL Kosten für die Laufwerksnutzung sparen. 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 für die Mindestdauer der Aufbewahrung des Transaktionslogs oder die für die Flags festgelegten Werte auf dem Laufwerk.

Bei binären Logs, die für PITR verwendet werden und auf dem Laufwerk gespeichert sind, speichert Cloud SQL die Logs für den Mindestwert, der für eine der folgenden Konfigurationen festgelegt wurde:

  • Die transactionLogRetentionDays-Sicherungskonfigurationseinstellung

  • Das Flag expire_logs_days oder das Flag binlog_expire_logs_seconds

    Die Änderung der Werte dieser Flags kann sich auf das Verhalten der PITR-Wiederherstellung und darauf auswirken, wie viele Tage von Logs auf dem Laufwerk gespeichert werden. Wir raten davon ab, den Wert eines dieser Flags auf 0 zu konfigurieren. Weitere Informationen zu diesen Flags finden Sie unter Datenbank-Flags konfigurieren.

Bei vom Kunden verwalteten Verschlüsselungs-Schlüsselinstanzen (Customer-Managed Encryption Key, CMEK) werden binäre Logs mit der neuesten Version des CMEK verschlüsselt. Zum Wiederherstellen müssen alle Versionen des Schlüssels verfügbar sein, die für die Anzahl der Tage die Sie für den Parameter retained-transaction-log-days konfiguriert haben, die neuesten Versionen waren.

Logs und Laufwerknutzung

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

Prüfen Sie den bytes_used_by_data_type-Messwert der Instanz, um herauszufinden, wie viel Laufwerk von den binären Logs belegt wird. Der Wert für den Datentyp binlog gibt die Größe der Binlogs 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 das Flag expire_logs_days jedoch auf einen Wert setzen, der niedriger als die Aufbewahrungsdauer der Transaktionslogs ist, kann Cloud SQL die Binärlogs früher löschen.

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

  • Prüfen, ob die Instanz Logs auf dem Laufwerk speichert Sie können die für PITR verwendeten Logs vom Laufwerk in Cloud Storage verschieben, indem Sie PITR deaktivieren und wieder aktivieren. Dieser Vorgang führt zu einer Ausfallzeit von einigen Minuten, gibt jedoch Speicherplatz frei. Wenn Sie die Cloud SQL Enterprise-Version verwenden, können Sie auch ein Upgrade auf Cloud SQL Enterprise Plus ausfü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.

  • Wenn Sie Logs löschen und Speicherplatz zurückgewinnen möchten, können Sie PITR deaktivieren, ohne es wieder zu aktivieren. Die Größe des für die Instanz bereitgestellte Laufwerks wird durch die Verringerung des verwendeten Speicherplatzes 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, um eine Mindestanzahl von Tagen für die Logaufbewahrung zu gewährleisten.

Weitere Informationen zu PITR finden Sie unter PITR.

PITR aktivieren

Wenn Sie in der Google Cloud Console eine neue Instanz erstellen, sind die Optionen Automatische Sicherungen und Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren automatisch aktiviert.

Mit dem folgenden Verfahren wird PITR für eine vorhandene primäre Instanz aktiviert.

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Rufen Sie das Dreipunkt-Menü Dreipunkt-Symbol der Instanz auf, für die Sie PITR aktivieren möchten, und klicken Sie auf Bearbeiten.
  3. Maximieren Sie unter Instanz anpassen den Abschnitt Datenschutz.
  4. Klicken Sie auf das Kästchen Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren.
  5. Maximieren Sie Erweiterte Optionen.
  6. Geben Sie die Anzahl der Tage ein (von 1 bis 35 für die Cloud SQL Enterprise Plus-Version oder 1 bis 7 für die Cloud SQL Enterprise-Version).
  7. Klicken Sie auf Speichern.

gcloud

  1. Rufen Sie die Instanzübersicht auf: 
    gcloud sql instances describe INSTANCE_NAME
  2. Wenn im Abschnitt backupConfiguration enabled: false angezeigt wird, aktivieren Sie geplante Sicherungen:
    gcloud sql instances patch INSTANCE_NAME \
--backup-start-time=HH:MM

    Dabei geben Sie den Parameter backup-start-time im 24-Stunden-Zeitformat und in der Zeitzone UTC±00 an.

  3. PITR aktivieren: 
    gcloud sql instances patch INSTANCE_NAME \
--enable-bin-log

    Wenn Sie PITR auf einer primären Instanz aktivieren, können Sie auch die Anzahl der Tage konfigurieren, für die Sie Transaktionslogs aufbewahren möchten. Fügen Sie dazu den folgenden Parameter hinzu:

    --retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
  4. Bestätigen Sie die Änderung: 
    gcloud sql instances describe INSTANCE_NAME

    Im Abschnitt backupConfiguration wird binaryLogEnabled: true angezeigt, ob die Änderung erfolgreich war.

Terraform

Verwenden Sie zum Aktivieren von PITR eine Terraform-Ressource. 

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance-pitr"
  region           = "asia-northeast1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-f1-micro"
    backup_configuration {
      enabled                        = true
      binary_log_enabled             = true
      start_time                     = "20:55"
      transaction_log_retention_days = "3"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Änderungen anwenden

Führen Sie die Schritte in den folgenden Abschnitten aus, um Ihre Terraform-Konfiguration auf ein Google Cloud-Projekt anzuwenden.

Cloud Shell vorbereiten

  1. Rufen Sie Cloud Shell auf.

  2. Legen Sie das Google Cloud-Standardprojekt fest, auf das Sie Ihre Terraform-Konfigurationen anwenden möchten.

    Sie müssen diesen Befehl nur einmal pro Projekt und in jedem beliebigen Verzeichnis ausführen.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Umgebungsvariablen werden überschrieben, wenn Sie in der Terraform-Konfigurationsdatei explizite Werte festlegen.

Verzeichnis vorbereiten

Jede Terraform-Konfigurationsdatei muss ein eigenes Verzeichnis haben (auch als Stammmodul bezeichnet).

  1. Erstellen Sie in Cloud Shell ein Verzeichnis und eine neue Datei in diesem Verzeichnis. Der Dateiname muss die Erweiterung .tf haben, z. B. main.tf. In dieser Anleitung wird die Datei als main.tf bezeichnet. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Wenn Sie einer Anleitung folgen, können Sie den Beispielcode in jedem Abschnitt oder Schritt kopieren.

    Kopieren Sie den Beispielcode in das neu erstellte main.tf.

    Kopieren Sie optional den Code aus GitHub. Dies wird empfohlen, wenn das Terraform-Snippet Teil einer End-to-End-Lösung ist.

  3. Prüfen und ändern Sie die Beispielparameter, die auf Ihre Umgebung angewendet werden sollen.
  4. Speichern Sie die Änderungen.
  5. Initialisieren Sie Terraform. Dies ist nur einmal für jedes Verzeichnis erforderlich. 
    terraform init

    Fügen Sie optional die Option -upgrade ein, um die neueste Google-Anbieterversion zu verwenden: 

    terraform init -upgrade

Änderungen anwenden

  1. Prüfen Sie die Konfiguration und prüfen Sie, ob die Ressourcen, die Terraform erstellen oder aktualisieren wird, Ihren Erwartungen entsprechen: 
    terraform plan

    Korrigieren Sie die Konfiguration nach Bedarf.

  2. Wenden Sie die Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie yes an der Eingabeaufforderung ein: 
    terraform apply

    Warten Sie, bis Terraform die Meldung „Apply complete“ anzeigt.

  3. Öffnen Sie Ihr Google Cloud-Projekt, um die Ergebnisse aufzurufen. Rufen Sie in der Google Cloud Console Ihre Ressourcen in der Benutzeroberfläche auf, um sicherzustellen, dass Terraform sie erstellt oder aktualisiert hat.

Änderungen löschen

So löschen Sie das Projekt:

  1. Um den Löschschutz zu deaktivieren, setzen Sie in der Terraform-Konfigurationsdatei das Argument deletion_protection auf false. 
    deletion_protection =  "false"
  2. Wenden Sie die aktualisierte Terraform-Konfiguration an. Führen Sie dazu den folgenden Befehl aus und geben Sie yes an der Eingabeaufforderung ein: 
    terraform apply

  1. Entfernen Sie Ressourcen, die zuvor mit Ihrer Terraform-Konfiguration angewendet wurden, indem Sie den folgenden Befehl ausführen und yes an der Eingabeaufforderung eingeben:

    terraform destroy

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
  • INSTANCE_NAME: der Name der primären Instanz oder der Lesereplikatinstanz, die Sie für Hochverfügbarkeit konfigurieren
  • START_TIME: die Uhrzeit (in Stunden und Minuten)

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

JSON-Text anfordern:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das die Instanz enthält
  • INSTANCE_NAME: der Name der primären Instanz oder der Lesereplikatinstanz, die Sie für Hochverfügbarkeit konfigurieren
  • START_TIME: die Uhrzeit (in Stunden und Minuten)

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

JSON-Text anfordern:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

PITR mit einem Zeitstempel ausführen

Die Verwendung eines Zeitstempels wird zum Ausführen von PITR empfohlen. Cloud SQL verwendet das Dienstprogramm mysqlbinlog, um Instanzen bis zu einem bestimmten Zeitpunkt wiederherzustellen. Weitere Informationen zum Dienstprogramm mysqlbinlog finden Sie in der MySQL-Referenzdokumentation.

Für die folgende Aufgabe benötigen Sie Folgendes:

  • Binäres Logging und Sicherungen für die Instanz sind aktiviert und fortlaufende binäre Logs seit der letzten Sicherung vor dem Ereignis, das Sie wiederherstellen möchten, sind vorhanden. Weitere Informationen erhalten Sie unter Binäres Logging aktivieren.
  • Ein Zeitstempel zum Definieren des Wiederherstellungspunkts. Die Ereignisse, die an und nach diesem Zeitstempel auftreten, werden in der neuen Instanz nicht angezeigt.

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Rufen Sie das Dreipunkt-Menü Dreipunkt-Symbol der Instanz auf, die Sie wiederherstellen möchten, und klicken Sie auf Klon erstellen.
  3. Aktualisieren Sie optional auf der Seite Klon erstellen die ID des neuen Klons.
  4. Wählen Sie Von einem früheren Zeitpunkt klonen aus.
  5. Geben Sie eine PITR-Zeit ein.
  6. Klicken Sie auf Klon erstellen.

gcloud

Erstellen Sie mit PITR einen Klon.

Ersetzen Sie Folgendes:

  • SOURCE_INSTANCE_NAME: der Name der Instanz, von der aus Sie wiederherstellen möchten.
  • NEW_INSTANCE_NAME: der Name für den Klon.
  • TIMESTAMP: die UTC-Zeitzone für die Quellinstanz im Format RFC 3339. Beispiel: 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time 'TIMESTAMP'

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • target-instance-id: die ID der Zielinstanz
  • source-instance-id: die ID der Quellinstanz
  • restore-timestamp der Zeitpunkt, zu dem wiederhergestellt werden soll

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

JSON-Text anfordern:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • target-instance-id: die ID der Zielinstanz
  • source-instance-id: die ID der Quellinstanz
  • restore-timestamp der Zeitpunkt, zu dem wiederhergestellt werden soll

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

JSON-Text anfordern:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

PITR deaktivieren

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Rufen Sie das Dreipunkt-Menü Dreipunkt-Symbol der Instanz auf, die Sie deaktivieren möchten, und wählen Sie Bearbeiten aus.
  3. Maximieren Sie unter Instanz anpassen den Abschnitt Datenschutz.
  4. Entfernen Sie das Häkchen von der Option Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren.
  5. Klicken Sie auf Speichern.
  6. Auf der Seite Übersicht für die Instanz wird unter Konfiguration die PITR-Einstellung als deaktiviert aufgeführt.

gcloud

  1. Deaktivieren Sie die Wiederherstellung zu einem bestimmten Zeitpunkt: 
    gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log
  2. Bestätigen Sie die Änderung: 
    gcloud sql instances describe INSTANCE_NAME

    Im Abschnitt backupConfiguration wird binaryLogEnabled: false angezeigt, ob die Änderung erfolgreich war.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • instance-id: die Instanz-ID

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

JSON-Text anfordern:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • instance-id: die Instanz-ID

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

JSON-Text anfordern:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden

Sie können prüfen, wo Ihre Cloud SQL-Instanz die für PITR verwendeten Transaktionslogs speichert.

gcloud

Verwenden Sie den folgenden Befehl, um festzustellen, ob Ihre Instanz Logs für PITR auf dem Laufwerk oder in Cloud Storage speichert:

   gcloud sql instances describe INSTANCE_NAME

Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz.

In der Ausgabe des Befehls enthält das Feld transactionalLogStorageState Informationen dazu, wo die Transaktionslogs für PITR für die Instanz gespeichert sind. Mögliche Speicherstatus für Transaktionslogs sind:

  • DISK: Die Instanz speichert die für PITR verwendeten Transaktionslogs auf dem Laufwerk. Wenn Sie ein Upgrade einer Cloud SQL Enterprise-Instanz auf die Cloud SQL Enterprise Plus-Version durchführen, wird beim Upgrade auch der Logspeicherort auf Cloud Storage umgestellt. Weitere Informationen finden Sie unter Instanz mithilfe eines direkten Upgrades auf Cloud SQL Enterprise Plus aktualisieren.
  • SWITCHING_TO_CLOUD_STORAGE: Die Instanz ändert den Speicherort für die PITR-Transaktionslogs zu Cloud Storage.
  • SWITCHED_TO_CLOUD_STORAGE: Die Instanz hat den Speicherort für PITR-Transaktionslogs vom Laufwerk zu Cloud Storage geändert.
  • CLOUD_STORAGE: Die Instanz speichert die für PITR verwendeten Transaktionslogs in Cloud Storage.

Aufbewahrung von Transaktionslogs festlegen

So legen Sie die Anzahl der Tage fest, für die binäre Logs aufbewahrt werden sollen:

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.

    Cloud SQL-Instanzen aufrufen

  2. Rufen Sie das Dreipunkt-Menü Dreipunkt-Symbol der Instanz auf, für die Sie das Transaktionslog festlegen möchten, und wählen Sie Bearbeiten aus.
  3. Maximieren Sie unter Instanz anpassen den Abschnitt Datenschutz.
  4. Maximieren Sie im Abschnitt Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren die Option Erweiterte Optionen.
  5. Geben Sie die Anzahl der Tage ein (von 1 bis 35 für die Cloud SQL Enterprise Plus-Version oder 1 bis 7 für die Cloud SQL Enterprise-Version).
  6. Klicken Sie auf Speichern.

gcloud

Legen Sie die Anzahl der Tage für die Aufbewahrung von binären Logs für die Instanz fest.

Ersetzen Sie Folgendes:

  • INSTANCE-NAME: der Name der Instanz, für die Sie das Transaktionslog festlegen möchten.
  • DAYS-TO-RETAIN: die Anzahl der Tage, für die Transaktionslogs beibehalten werden sollen. Bei Cloud SQL Enterprise Plus liegt der gültige Bereich zwischen 1 und 35 Tagen, wobei der Standardwert 14 Tage beträgt. Bei Cloud SQL Enterprise liegt der gültige Bereich zwischen 1 und 7 Tagen, wobei der Standardwert 7 Tage beträgt. Wenn kein Wert angegeben ist, wird der Standardwert verwendet. Nur gültig, wenn PITR aktiviert ist. Wenn Sie Transaktionslogs länger speichern möchten, ist mehr Speicherplatz erforderlich. 

  gcloud sql instances patch INSTANCE-NAME \
    --retained-transaction-log-days=DAYS-TO-RETAIN

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • days-to-retain: Die Anzahl der Tage, die Transaktionslogs aufbewahrt werden sollen (von eins bis sieben)
  • project-id: die Projekt-ID
  • instance-id: die Instanz-ID

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

JSON-Text anfordern:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • days-to-retain: Die Anzahl der Tage, die Transaktionslogs aufbewahrt werden sollen (von eins bis sieben)
  • project-id: die Projekt-ID
  • instance-id: die Instanz-ID

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

JSON-Text anfordern:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

PITR mit binären Logpositionen ausführen

Wir empfehlen die Ausführung von PITR mit Zeitstempeln, wie unter PITR mit einem Zeitstempel ausführen beschrieben. Sie können PITR aber auch ausführen, indem Sie eine bestimmte binäre Logposition in einer binären Logdatei angeben.

Weitere Informationen zu PITR mithilfe von binären Logpositionen finden Sie in der MySQL-Referenz unter PITR mit dem binären Log.

Hinweise

Bevor Sie diese Aufgabe ausführen, muss Folgendes vorliegen:

  • Binäres Logging und Sicherungen für die Instanz sind aktiviert und fortlaufende binäre Logs seit der letzten Sicherung vor dem Ereignis, das Sie wiederherstellen möchten, sind vorhanden. Weitere Informationen erhalten Sie unter Binäres Logging aktivieren.

  • Die binären Logs müssen auf dem Laufwerk verfügbar sein, damit Sie sie nach Ereignissen durchsuchen können. Informationen zum Prüfen der Aufbewahrungsdauer Ihrer binären Logs auf dem Laufwerk finden Sie unter Logaufbewahrungsdauer. Sie können mit dem Dienstprogramm mysqlbinlog nicht in binären Logs suchen, die in Cloud Storage gespeichert sind.

  • Der Dateiname des binären Logs und die Position des Ereignisses, von der Sie wiederherstellen möchten (das betreffende Ereignis und alle darauffolgenden Ereignisse sind in der neuen Instanz nicht mehr vorhanden). Weitere Informationen finden Sie unter Position des binären Logs ermitteln.

    Nachdem Sie den Dateinamen des binären Logs und die Position ermittelt haben, führen Sie die PITR mit Positionen binärer Logereignisse aus.

Wiederherstellungsposition ermitteln

  1. Stellen Sie über den MySQL-Client eine Verbindung zu der Instanz her, für die Sie wiederherstellen möchten.

    Verwenden Sie dazu Cloud Shell oder Ihren lokalen Client-Computer. Weitere Informationen finden Sie unter Verbindungsoptionen für externe Anwendungen.

  2. Rufen Sie die binären Log-Dateien für die Instanz auf:

    SHOW BINARY LOGS;

  3. Rufen Sie die ersten 100 Ereignisse in der aktuellen binären Logdatei auf:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;

    Die Anzahl der angezeigten Zeilen kann angepasst werden. Vermeiden Sie es jedoch, sich alle Ereignisse anzeigen zu lassen, wenn Sie die Größe der Datei nicht kennen. Das Aufrufen einer großen Anzahl von Ereignissen kann die Leistung des Systems beeinträchtigen.

  4. Wenn das gewünschte Ereignis nicht enthalten ist, verwenden Sie die zuletzt angezeigte Position als Ausgangspunkt für die Suche nach dem nächsten Ereignissatz:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;

  5. Wenn Sie das Ereignis gefunden haben, das den Zeitpunkt definiert, für den Sie die Wiederherstellung vornehmen möchten, notieren Sie sich die Position (Pos) und den Dateinamen des binären Logs.

    Der Dateiname des binären Logs und die Position werden als Werte für die PITR verwendet.

Das folgende Beispiel zeigt die Ausgabe des Befehls SHOW BINLOG EVENTS:

+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| mysql-bin.000011 |   4 | Format_desc |  88955285 |         120 | Server ver: 5.6.30-log, Binlog ver: 4               |
| mysql-bin.000011 | 120 | Query       |  88955285 |         211 | create database db1                                 |
| mysql-bin.000011 | 211 | Query       |  88955285 |         310 | use `db1`; CREATE TABLE t (c CHAR(20))              |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |
| mysql-bin.000011 | 381 | Table_map   |  88955285 |         426 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |

| mysql-bin.000011 | 426 | Write_rows  |  88955285 |         464 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 464 | Xid         |  88955285 |         495 | COMMIT /* xid=56 */                                 |
| mysql-bin.000011 | 495 | Query       |  88955285 |         566 | BEGIN                                               |
| mysql-bin.000011 | 566 | Table_map   |  88955285 |         611 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 611 | Write_rows  |  88955285 |         649 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 649 | Xid         |  88955285 |         680 | COMMIT /* xid=57 */                                 |
| mysql-bin.000011 | 680 | Query       |  88955285 |         751 | BEGIN                                               |
| mysql-bin.000011 | 751 | Table_map   |  88955285 |         796 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 796 | Write_rows  |  88955285 |         834 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 834 | Xid         |  88955285 |         865 | COMMIT /* xid=58 */                                 |
| mysql-bin.000011 | 865 | Query       |  88955285 |         977 | use `db1`; DROP TABLE `t` /* generated by server */ |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
16 rows in set (0.04 sec)

Um die Wiederherstellung bis zu der Anweisung DROP TABLE durchzuführen, die in der Beispielausgabe in Fettschrift hervorgehoben ist, verwenden Sie "865" in "mysql-bin.000011" als Wiederherstellungsposition. Die Anweisung DROP TABLE und alle darauffolgenden Vorgänge werden in der neuen Instanz nicht berücksichtigt.

PITR mit Positionen binärer Logereignisse ausführen

gcloud

Verwenden Sie den Befehl gcloud sql instances clone mit den Flags --bin-log-file-name und --bin-log-position.

  1. Erstellen Sie die neue Instanz mit dem Dateinamen des binären Logs und der Wiederherstellungsposition.

    Ersetzen Sie Folgendes:

    • SOURCE_INSTANCE_NAME: der Name der Instanz, von der Sie wiederherstellen möchten.
    • NEW_INSTANCE_NAME: der Name für den Klon.
    • BINLOG_FILE_NAME: der Name für das binäre Log, z. B. mysql-bin.187288.
    • POSITION: die Position im binären Log, bis zu der wiederhergestellt werden soll, z. B. 50001356.
    gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--bin-log-file-name="BINLOG_FILE_NAME" \
--bin-log-position=POSITION

    Ein gcloud sql instances clone-Befehl kann beispielsweise so aussehen:

    gcloud sql instances clone instance1 \
instance1-clone \
--bin-log-file-name=mysql-bin.0000031 \
--bin-log-position=107 \
  2. Prüfen Sie mit der vom Befehl clone zurückgegebenen Vorgangs-ID den Status des Wiederherstellungsvorgangs.
    gcloud sql operations describe OPERATION_ID

    Wird der Vorgang ausgeführt, wird der Status RUNNING zurückgegeben. Wenn der Vorgang beendet ist, wird der Status DONE zurückgegeben.

REST Version 1

Erstellen Sie die neue Instanz und verwenden Sie dazu den von Ihnen angegebenen Dateinamen des binären Logs und die festgelegte Wiederherstellungsposition.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • target-instance-id: die ID der Zielinstanz
  • source-instance-id: die ID der Quellinstanz
  • binary-log-file-name: der Name der binären Logdatei
  • binary-log-position: die Position in der binären Logdatei

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

JSON-Text anfordern:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

REST v1beta4

Erstellen Sie die neue Instanz und verwenden Sie dazu den von Ihnen angegebenen Dateinamen des binären Logs und die von Ihnen festgelegte Wiederherstellungsposition.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • project-id: die Projekt-ID
  • target-instance-id: die ID der Zielinstanz
  • source-instance-id: die ID der Quellinstanz
  • binary-log-file-name: der Name der binären Logdatei
  • binary-log-position: die Position in der binären Logdatei

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

JSON-Text anfordern:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten in etwa folgende JSON-Antwort erhalten:

Fehlerbehebung

Problem Fehlerbehebung

argument --point-in-time: Failed to parse date/time:
Unknown string format: 2021-0928T30:54:03.094;
received: 2021-0928T30:54:03.094Z

ODER

Invalid value at 'body.clone_context.point_in_time'
(type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime',
Invalid time format: Failed to parse input,

 Der von Ihnen angegebene Zeitstempel ist ungültig.

HTTP Error 400: Successful backup required for carrying out the operation was not found.

ODER

Successful backup required for carrying out the operation was not found. or Time where no backups can be found.

 Der angegebene Zeitstempel gilt für einen Zeitpunkt, an dem keine Sicherungen oder binlog-Koordinaten gefunden wurden.

Nächste Schritte