Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) 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 zur PITR finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt (PITR).

Wenn Sie eine Cloud SQL Enterprise Plus-Instanz erstellen, ist PITR standardmäßig aktiviert, unabhängig von der verwendeten Methode. Wenn Sie die Funktion deaktivieren möchten, müssen Sie dies manuell tun.

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. Wenn Sie die Funktion in diesem Fall aktivieren möchten, müssen Sie dies manuell tun.

Logspeicher für PITR

Cloud SQL verwendet binäre Logs für die Wiederherstellung zu einem bestimmten Zeitpunkt.

Am 11. August 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 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 Upgrade einer Instanz auf Cloud SQL Enterprise Plus mithilfe eines direkten Upgrades ausführen.

  • 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 von Transaktionslogs prüfen, die für PITR verwendet werden.

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 ohne Ausfallzeiten vom Laufwerk zu Cloud Storage wechseln. Weitere Informationen finden Sie unter Transaktionsprotokollspeicher auf Cloud Storage umstellen.

Aufbewahrungsdauer für Logs

Cloud SQL behält Transaktionslogs in Cloud Storage bis zum 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 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, werden auch eine kleinere Anzahl von doppelten binären Logs auf dem Laufwerk gespeichert, um die Replikation der Logs in Cloud Storage zu ermöglichen. Wenn Sie eine Instanz mit aktivierter PITR erstellen, werden die binären Logs für PITR standardmäßig in Cloud Storage gespeichert. Cloud SQL legt den Wert der Flags expire_logs_days und binlog_expire_logs_seconds automatisch auf den Wert von einem Tag fest. Das entspricht einem Tag mit Protokollen auf der Festplatte.

Für binäre PITR-Logs, 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 binären Logs auf dem Laufwerk gespeichert werden, zu Cloud Storage gewechselt wird oder bereits zu Cloud Storage gewechselt wurde. Wenn Logs auf dem Laufwerk gespeichert werden, kann sich das Ändern der Werte dieser Flags auf das Verhalten der PITR-Wiederherstellung und darauf auswirken, wie viele Tage an Logs auf dem Laufwerk gespeichert werden. Während der Umstellung des Log-Speicherorts auf Cloud Storage 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.

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 Laufwerksnutzung

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 herausfinden möchten, wie viel Speicherplatz von den Binärlogs belegt wird, sehen Sie sich den Messwert bytes_used_by_data_type für die Instanz an. Der Wert für den Datentyp binlog gibt die Größe der Binärlogs auf der Festplatte 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 oder binlog_expire_logs_seconds auf einen Wert festlegen, der niedriger als die Anzahl der Tage für die Aufbewahrung von Transaktionslogs ist, kann Cloud SQL die binären Logs jedoch 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, mit der gcloud CLI oder der Cloud SQL Admin API ohne Ausfallzeiten von der Festplatte zu Cloud Storage wechseln. Wenn Sie die Cloud SQL Enterprise-Version verwenden, können Sie auch ein Upgrade auf die Cloud SQL Enterprise Plus-Version 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 auf dem Laufwerk zurückgewinnen möchten, können Sie die Wiederherstellung zu einem bestimmten Zeitpunkt deaktivieren, ohne sie wieder zu aktivieren. Durch Reduzierung des verwendeten Speicherplatzes wird die Größe des für die Instanz bereitgestellte Laufwerks 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.

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

Nachdem Sie den Speicherort von 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äre Logs auf dem Laufwerk für die Mindestanzahl der Tage für die Aufbewahrung von Transaktionslogs oder die für die Flags festgelegten Werte. Weitere Informationen dazu, wie Logs für PITR nach der Umstellung gespeichert werden und wie Sie Speicherplatz freigeben können, finden Sie unter Logs nach der Umstellung auf Cloud Storage.

PITR aktivieren

Wenn Sie in der Google Cloud -Konsole eine neue Instanz erstellen, werden sowohl Automatisierte Back-ups als auch Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren automatisch aktiviert.

Mit dem folgenden Verfahren wird die Wiederherstellung zu einem bestimmten Zeitpunkt 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 die Wiederherstellung zu einem bestimmten Zeitpunkt 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. Geben Sie im Feld Tage mit Logs die Anzahl der Tage ein, für die Logs aufbewahrt werden sollen (1–35 für die Cloud SQL Enterprise Plus-Version oder 1–7 für die Cloud SQL Enterprise-Version).
  6. 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 die Wiederherstellung zu einem bestimmten Zeitpunkt 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 eine Terraform-Ressource, um die PITR zu aktivieren. 

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"
    }
  }
}

Ä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 Standardprojekt Google Cloud 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 für eine nicht verfügbare Instanz ausführen

Console

Sie können aus folgenden Gründen eine nicht verfügbare Instanz in einer anderen Zone wiederherstellen:

  • Auf die Zone, in der die Instanz konfiguriert ist, kann nicht zugegriffen werden. Diese Instanz hat den Status FAILED.
  • Die Instanz wird gerade gewartet. Diese Instanz hat den Status MAINTENANCE.

Führen Sie die folgenden Schritte aus, um eine nicht verfügbare Instanz wiederherzustellen:

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

    Cloud SQL-Instanzen aufrufen

  2. Suchen Sie die Zeile der zu klonenden Instanz.
  3. Klicken Sie in der Spalte Aktionen auf das Menü Weitere Aktionen.
  4. Klicken Sie auf Klon erstellen.
  5. Führen Sie auf der Seite Klon erstellen die folgenden Aktionen aus:
    1. Aktualisieren Sie bei Bedarf im Feld Instanz-ID die Instanz-ID.
    2. Klicken Sie auf Von einem früheren Zeitpunkt klonen.
    3. Wählen Sie im Feld Zeitpunkt ein Datum und eine Uhrzeit aus, von der Sie Daten klonen möchten. Dadurch wird der Status der Instanz gemäß diesem Zeitpunkt wiederhergestellt.
    4. Klicken Sie auf Klon erstellen.

    6. Während der Initialisierung des Klons werden Sie zur Seite mit der Instanzliste zurückgeleitet.

gcloud

Möglicherweise möchten Sie eine nicht verfügbare Instanz in einer anderen Zone wiederherstellen, da auf die Zone, in der die Instanz konfiguriert ist, nicht zugegriffen werden kann.

gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \
--point-in-time DATE_AND_TIME_STAMP \
--preferred-zone ZONE_NAME \
--preferred-secondary-zone SECONDARY_ZONE_NAME

Das Nutzer- oder Dienstkonto, mit dem der Befehl gcloud sql instances clone ausgeführt wird, muss die Berechtigung cloudsql.instances.clone haben. Weitere Informationen zu den erforderlichen Berechtigungen zum Ausführen von gcloud CLI-Befehlen finden Sie unter Cloud SQL-Berechtigungen.

REST Version 1

Möglicherweise möchten Sie eine nicht verfügbare Instanz in einer anderen Zone wiederherstellen, da die Zone, in der die Instanz konfiguriert ist, nicht zugänglich ist.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die Projekt-ID
  • SOURCE_INSTANCE_ID: die ID der Quellinstanz
  • TARGET_INSTANCE_ID: die ID der Zielinstanz

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone

JSON-Text anfordern:

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

Das Nutzer- oder Dienstkonto, das die API-Methode instances.clone verwendet, muss die Berechtigung cloudsql.instances.clone haben. Weitere Informationen zu den erforderlichen Berechtigungen für API-Methoden finden Sie unter Cloud SQL-Berechtigungen.

REST v1beta4

Möglicherweise möchten Sie eine nicht verfügbare Instanz in einer anderen Zone wiederherstellen, da die Zone, in der die Instanz konfiguriert ist, nicht zugänglich ist.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die Projekt-ID
  • SOURCE_INSTANCE_ID: die ID der Quellinstanz
  • TARGET_INSTANCE_ID: die ID der Zielinstanz

HTTP-Methode und URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone

JSON-Text anfordern:

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

Das Nutzer- oder Dienstkonto, das die API-Methode instances.clone verwendet, muss die Berechtigung cloudsql.instances.clone haben. Weitere Informationen zu den erforderlichen Berechtigungen für API-Methoden finden Sie unter Cloud SQL-Berechtigungen.

Wenn Sie versuchen, einen PITR-Klon zu einem Zeitpunkt nach dem letzten wiederherstellbaren Zeitpunkt zu erstellen, wird die folgende Fehlermeldung angezeigt:

The timestamp for point-in-time recovery is after the latest recovery time of
Timestamp of latest recovery time. Clone the instance with a time
that's earlier than this recovery time.

Neuesten Wiederherstellungszeitpunkt abrufen

Für eine verfügbare Instanz können Sie die Wiederherstellung zu einem bestimmten Zeitpunkt bis zum neuesten Zeitpunkt durchführen. Wenn die Instanz nicht verfügbar ist und die Instanzlogs in Cloud Storage gespeichert sind, können Sie die neueste Wiederherstellungszeit abrufen und die Wiederherstellung zu einem bestimmten Zeitpunkt gemäß jenem Zeitstand ausführen. In beiden Fällen 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.

gcloud

Rufen Sie den neuesten Zeitpunkt ab, gemäß dem Sie eine nicht verfügbare Cloud SQL-Instanz wiederherstellen können.

Ersetzen Sie INSTANCE_NAME durch den Namen der abgefragten Instanz.

gcloud sql instances get-latest-recovery-time INSTANCE_NAME

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die Projekt-ID
  • INSTANCE_NAME: der Name der Instanz, für die Sie den neuesten Wiederherstellungszeitpunkt abfragen

HTTP-Methode und URL:

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

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

{
  "kind": "sql#getLatestRecoveryTime",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: die Projekt-ID
  • INSTANCE_NAME: der Name der Instanz, für die Sie den neuesten Wiederherstellungszeitpunkt abfragen

HTTP-Methode und URL:

GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime

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

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

{
  "kind": "sql#getLatestRecoveryTime",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

PITR anhand eines Zeitstempels durchführen

Die Verwendung eines Zeitstempels ist die empfohlene Methode für die Durchführung einer PITR. Cloud SQL verwendet das Dienstprogramm mysqlbinlog, um Instanzen bis zu einem bestimmten Zeitpunkt wiederherzustellen. Weitere Informationen zum mysqlbinlog-Dienstprogramm 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, der den Wiederherstellungspunkt definiert. Ereignisse, die zu diesem Zeitstempel und danach auftreten, werden in der neuen Instanz nicht berücksichtigt.

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. Optional können Sie auf der Seite Klon erstellen die ID des neuen Klon aktualisieren.
  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 einen Klon mithilfe der Wiederherstellung zu einem bestimmten Zeitpunkt.

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.

gcloud

  1. Wiederherstellung zu einem bestimmten Zeitpunkt deaktivieren: 
    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 der für PITR verwendeten Transaktionslogs prüfen

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

gcloud

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

   gcloud sql instances describe INSTANCE_NAME

Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz.

Bei mehreren Instanzen im selben Projekt können Sie auch den Speicherort der Transaktionsprotokolle prüfen. Verwenden Sie den folgenden Befehl, um den Speicherort für mehrere Instanzen zu ermitteln:

   gcloud sql instances list --show-transactional-log-storage-state

Beispielantwort:

NAME  DATABASE_VERSION LOCATION       TRANSACTIONAL_LOG_STORAGE_STATE
my_01 MYSQL_8_0        us-central-1     DISK
my_02 MYSQL_8_0        us-central-1     CLOUD_STORAGE
...

In der Ausgabe des Befehls enthält das Feld transactionalLogStorageState oder die Spalte TRANSACTIONAL_LOG_STORAGE_STATE Informationen dazu, wo die Transaktionslogs für PITR für die Instanz gespeichert werden. Folgende Speicherstatus für das Transaktionsprotokoll sind möglich:

  • DISK: Die Instanz speichert die für PITR verwendeten Transaktionslogs auf der Festplatte. Wenn Sie eine Cloud SQL Enterprise-Instanz auf Cloud SQL Enterprise Plus aktualisieren, wird der Speicherort der Logs automatisch auf Cloud Storage umgestellt. Weitere Informationen finden Sie unter Upgrade einer Instanz auf Cloud SQL Enterprise Plus mithilfe eines direkten Upgrades ausführen. Sie können den Speicherort auch mit der gcloud CLI oder der Cloud SQL Admin API ändern, ohne die Version Ihrer Instanz zu aktualisieren und ohne Ausfallzeiten. Weitere Informationen finden Sie unter Transaktionsprotokollspeicher auf Cloud Storage umstellen.
  • SWITCHING_TO_CLOUD_STORAGE: Die Instanz wechselt den Speicherort für die PITR-Transaktionslogs zu Cloud Storage.
  • SWITCHED_TO_CLOUD_STORAGE: Die Instanz hat den Wechsel des Speicherorts für PITR-Transaktionslogs von der Festplatte zu Cloud Storage abgeschlossen.
  • CLOUD_STORAGE: Die Instanz speichert die für PITR verwendeten Transaktionslogs in Cloud Storage.

Transaktionslog-Speicher auf Cloud Storage umstellen

Wenn Ihre Instanz die für PITR verwendeten Transaktionslogs auf der Festplatte speichert, können Sie den Speicherort ohne Ausfallzeiten auf Cloud Storage umstellen. Der gesamte Vorgang zum Ändern des Speicherorts dauert ungefähr so lange wie der Aufbewahrungszeitraum für das Transaktionslog (in Tagen). Sobald Sie die Umstellung starten, werden Transaktionslogs in Cloud Storage erfasst. Während des Vorgangs können Sie den Status des Gesamtprozesses mit dem Befehl unter Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden prüfen.

Nach Abschluss des gesamten Vorgangs der Umstellung auf Cloud Storage verwendet Cloud SQL Transaktionslogs aus Cloud Storage für PITR.

gcloud

Verwenden Sie den folgenden Befehl, um den Speicherort zu Cloud Storage zu wechseln:

   gcloud sql instances patch INSTANCE_NAME \
      --switch-transaction-logs-to-cloud-storage

Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz. Die Instanz muss eine primäre Instanz und keine Replikatinstanz sein. Die Antwort ähnelt dem folgenden Beispiel.

The following message is used for the patch API method.
{"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"}

Patching Cloud SQL instance...done.
Updated
[https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].

Wenn der Befehl einen Fehler zurückgibt, finden Sie unter Fehlerbehebung beim Wechsel zu Cloud Storage mögliche nächste Schritte.

REST Version 1

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Projekt-ID.
  • INSTANCE_ID: Instanz-ID. Die Instanz muss eine primäre Instanz und keine Replikatinstanz sein.

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

Wenn die Anfrage einen Fehler zurückgibt, finden Sie unter Fehlerbehebung beim Wechsel zu Cloud Storage mögliche nächste Schritte.

REST v1beta4

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Projekt-ID.
  • INSTANCE_ID: Instanz-ID. Die Instanz muss eine primäre Instanz und keine Replikatinstanz sein.

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

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

Sie sollten in etwa folgende JSON-Antwort erhalten:

Wenn die Anfrage einen Fehler zurückgibt, finden Sie unter Fehlerbehebung beim Wechsel zu Cloud Storage mögliche nächste Schritte.

Speicherung und Konfiguration von Transaktionslogs nach dem Wechsel

Zu Replikationszwecken speichert Cloud SQL weiterhin Kopien binärer Logs auf dem Laufwerk.

Wenn Sie binäre Logs mit dem Dienstprogramm mysqlbinlog durchsuchen möchten, ist das Speichern binärer Logs auf einem Laufwerk nützlich.

Wenn Sie die Flags expire_logs_days oder binlog_expire_logs_seconds vor dem Wechsel auf Ihrer Instanz konfiguriert haben, bleiben die konfigurierten Werte erhalten.

Da die binären Logs, die zum Ausführen von PITR verwendet werden, nach der Umstellung jetzt in Cloud Storage gespeichert werden, müssen die Werte der Flags die Aufbewahrung von Transaktionslogs auf dem erwarteten Laufwerk widerspiegeln. Cloud SQL speichert Logs auf dem Laufwerk nur für einen der folgenden Mindestwert:

  • die PITR-Konfigurationseinstellung transactionLogRetentionDays vor der Umstellung. Der Standardwert für diese Einstellung ist 7 Tage.
  • die Flags expire_logs_days oder binlog_expire_logs_seconds, die Sie für Ihre Instanz manuell festgelegt haben.

Wenn Sie Speicherplatz sparen möchten, konfigurieren Sie nach Abschluss des Wechsels den Wert des Flags expire_logs_days oder binlog_expire_logs_seconds auf 1 Tag, damit Sie die zugewiesene Laufwerkgröße und Laufwerksspeicherkosten reduzieren können. Weitere Informationen zum Speichern von Transaktionslogs und PITR finden Sie unter Logspeicher für PITR.

Weitere Informationen zum Prüfen der Festplattennutzung finden Sie unter Logs und Festplattennutzung.

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 Sie keinen Wert angeben, verwendet Cloud SQL den Standardwert. Dies ist nur gültig, wenn die Wiederherstellung zu einem bestimmten Zeitpunkt 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:

  • PROJECT_ID: Projekt-ID.
  • INSTANCE_ID: Instanz-ID.

  • DAYS_TO_RETAIN: die Anzahl der Tage, für die Transaktionslogs aufbewahrt 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. Dies ist nur gültig, wenn die Wiederherstellung zu einem bestimmten Zeitpunkt aktiviert ist. Wenn Sie Transaktionslogs länger speichern möchten, ist mehr Speicherplatz erforderlich.

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:

  • PROJECT_ID: Projekt-ID.
  • INSTANCE_ID: Instanz-ID.

  • DAYS_TO_RETAIN: die Anzahl der Tage, für die Transaktionslogs aufbewahrt 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. Dies ist nur gültig, wenn die Wiederherstellung zu einem bestimmten Zeitpunkt aktiviert ist. Wenn Sie Transaktionslogs länger speichern möchten, ist mehr Speicherplatz erforderlich.

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:

Wiederherstellung zu einem bestimmten Zeitpunkt mit binären Logpositionen ausführen

Wir empfehlen, die Wiederherstellung zu einem bestimmten Zeitpunkt mithilfe von Zeitstempeln durchzuführen, wie unter Wiederherstellung zu einem bestimmten Zeitpunkt mithilfe eines Zeitstempels durchführen beschrieben. Sie können die Wiederherstellung zu einem bestimmten Zeitpunkt aber auch ausführen, indem Sie eine bestimmte binäre Logposition oder Ereignisposition in einer binären Logdatei angeben.

Weitere Informationen zur Wiederherstellung zu einem bestimmten Zeitpunkt mithilfe von binären Logpositionen finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt 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ärprotokolle müssen auf der Festplatte verfügbar sein, damit Sie sie nach Ereignissen durchsuchen können. Informationen zur Aufbewahrungsdauer Ihrer binären Logs auf der Festplatte finden Sie unter Aufbewahrungsdauer von Logs. Sie können binäre Logs, die in Cloud Storage gespeichert sind, nicht mit dem Dienstprogramm mysqlbinlog durchsuchen.

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

    Wenn Sie den Dateinamen des binären Logs und die Position ermittelt haben, können Sie die Wiederherstellung zu einem bestimmten Zeitpunkt mithilfe von Positionen binärer Logereignisse ausführen.

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.

Hier ein Beispiel für 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 zur Anweisung DROP TABLE durchzuführen, die im vorherigen Beispiel in Fettschrift hervorgehoben ist, verwenden Sie 865 in mysql-bin.000011 als Wiederherstellungsposition. Die DROP TABLE-Anweisung und alle darauffolgenden Vorgänge werden in der neuen Instanz nicht berücksichtigt.

Wiederherstellung zu einem bestimmten Zeitpunkt 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.

Probleme beim Wechsel zu Cloud Storage beheben

In der folgenden Tabelle sind mögliche Fehler aufgeführt, die mit dem INVALID REQUEST-Code zurückgegeben werden können, wenn Sie den Speicherort der Transaktionsprotokolle von der Festplatte in Cloud Storage ändern.

Problem Fehlerbehebung
Switching the storage location of the transaction logs used for PITR is not supported for instances with database type %s. Achten Sie darauf, dass Sie den gcloud CLI-Befehl ausführen oder die API-Anfrage für eine Cloud SQL for MySQL- oder Cloud SQL for PostgreSQL-Instanz stellen. Das Ändern des Speicherorts für Transaktionslogs mit der gcloud CLI oder der Cloud SQL Admin API wird für Cloud SQL for SQL Server nicht unterstützt.
MySQL transactional logging is not enabled on this instance. MySQL verwendet das binäre Logging als Transaktionslogs für die Wiederherstellung zu einem bestimmten Zeitpunkt. Damit PITR unterstützt wird, müssen Sie das binäre Logging für die MySQL-Instanz aktivieren. Weitere Informationen zum Aktivieren des binären Loggings finden Sie unter PITR aktivieren.
This command is not supported on replica instances. Run the command on the primary instance instead. Achten Sie darauf, dass Sie beim Ausführen des Befehls oder beim Senden der API-Anfrage eine primäre Instanz angeben.
This instance is already storing transaction logs used for PITR in Cloud Storage Führen Sie den Befehl unter Speicherort der für PITR verwendeten Transaktionslogs prüfen aus, um den Speicherort der Transaktionslogs zu prüfen.
The instance is already switching transaction logs used for PITR from disk to Cloud Storage.

Warten Sie, bis der Wechselvorgang abgeschlossen ist.

Führen Sie den Befehl unter Speicherort der für PITR verwendeten Transaktionslogs prüfen aus, um den Status des Vorgangs und den Speicherort der Transaktionslogs zu prüfen.

Nächste Schritte