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

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 jedoch 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 die Point-in-Time-Wiederherstellung.

Am 11. August 2023 haben wir die Speicherung von Transaktionslogs für die Point-in-Time-Recovery 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 die 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 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 nur binäre Logs 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, ohne dass es zu einer Ausfallzeit kommt. Weitere Informationen finden Sie unter Speicherort für Transaktionsprotokolle zu Cloud Storage wechseln.

Aufbewahrungsdauer für Protokolle

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

Eine Instanz speichert die für PITR verwendeten binären Logs zwar in Cloud Storage, behält aber auch eine kleinere Anzahl von duplizierten 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 standardmäßig ihre binären Logs für PITR in Cloud Storage. Außerdem wird der Wert der Flags expire_logs_days und binlog_expire_logs_seconds automatisch auf einen Tag festgelegt. Das entspricht einem Tag an Protokollen auf dem Laufwerk.

Bei binären PITR-Logs, die auf dem Laufwerk gespeichert sind, auf Cloud Storage umgestellt werden oder bereits auf Cloud Storage umgestellt 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 setzt keine Werte für diese Flags, wenn die binären Logs auf dem Laufwerk gespeichert werden, zu Cloud Storage migriert werden oder bereits zu Cloud Storage migriert wurden. Wenn Protokolle auf dem Laufwerk gespeichert werden, kann sich die Änderung der Werte dieser Flags auf das Verhalten der PITR-Wiederherstellung und darauf auswirken, wie viele Tage an Protokollen auf dem Laufwerk gespeichert werden. Sie können diese Werte nicht ändern, während der Speicherort für den Protokollspeicher auf Cloud Storage umgestellt wird. Wir empfehlen auch nicht, 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.

Protokolle 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 in der Regel, wenn der für transactionLogRetentionDays festgelegte Wert erreicht ist.

Wenn Sie wissen möchten, wie viel Speicherplatz von den Binärprotokollen 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 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 oder binlog_expire_logs_seconds jedoch auf einen Wert festlegen, der unter der Aufbewahrungsdauer des Transaktionslogs liegt, 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 Protokolle auf dem Laufwerk speichert. Mit der gcloud CLI oder der Cloud SQL Admin API können Sie den Speicherort der für PITR verwendeten Logs ohne Ausfallzeit vom Laufwerk 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 Protokolle löschen und Speicherplatz auf dem Laufwerk wiederherstellen möchten, können Sie PITR deaktivieren, ohne es 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 als Wert für den Parameter 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 der Transaktionsprotokolle 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 Schalters finden Sie unter Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden. Wenn Sie zusätzliche Protokolle auf dem Laufwerk verfügbar machen möchten, z. B. um die binären Protokolle 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 kürzeste Aufbewahrungsdauer der Transaktionslogs oder für die für die Flags festgelegten Werte. Weitere Informationen dazu, wie Protokolle für die Wiederherstellung zu einem bestimmten Zeitpunkt nach der Umstellung gespeichert werden und wie Sie Speicherplatz freigeben, finden Sie unter Protokolle nach der Umstellung auf Cloud Storage.

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 auf einer vorhandenen primären 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 für Protokolle die Anzahl der Tage ein, für die Protokolle aufbewahrt werden sollen. Geben Sie dazu eine Zahl zwischen 1 und 35 für die Cloud SQL Enterprise Plus-Version oder zwischen 1 und 7 für die Cloud SQL Enterprise-Version ein.
  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 Wiederherstellung zu einem bestimmten Zeitpunkt 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"
    }
  }
  # 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

Für die PITR wird die Verwendung eines Zeitstempels empfohlen. In Cloud SQL wird das Dienstprogramm mysqlbinlog verwendet, 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, 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 die Uhrzeit für die Wiederherstellung auf einen bestimmten Zeitpunkt ein.
  6. Klicken Sie auf Klon erstellen.

gcloud

Erstellen Sie einen Klon mithilfe der PITR.

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

Mit dem folgenden Befehl können Sie feststellen, ob Ihre Instanz Protokolle 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.

Sie können auch den Speicherort der Transaktionsprotokolle für mehrere Instanzen im selben Projekt 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 Befehlsausgabe enthält das Feld transactionalLogStorageState oder die Spalte TRANSACTIONAL_LOG_STORAGE_STATE Informationen dazu, wo die Transaktionsprotokolle für die PITR-Wiederherstellung für die Instanz gespeichert werden. Mögliche Speicherstatus für Transaktionsprotokolle:

  • DISK: Die Instanz speichert die für die PITR verwendeten Transaktionslogs auf dem Laufwerk. Wenn Sie eine Cloud SQL Enterprise-Instanz auf die Cloud SQL Enterprise Plus-Version umstellen, wird der Speicherort der Protokolle während des Upgrades automatisch auf Cloud Storage umgestellt. Weitere Informationen finden Sie unter Instanz mithilfe eines direkten Upgrades auf Cloud SQL Cloud SQL Enterprise Plus aktualisieren. 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 Speicherort für Transaktionsprotokolle zu Cloud Storage wechseln.
  • SWITCHING_TO_CLOUD_STORAGE: In der Instanz wird der Speicherort für die PITR-Transaktionsprotokolle auf Cloud Storage umgestellt.
  • SWITCHED_TO_CLOUD_STORAGE: Der Speicherort der PITR-Transaktionsprotokolle wurde von der Festplatte zu Cloud Storage geändert.
  • CLOUD_STORAGE: Die Instanz speichert die für die PITR verwendeten Transaktionslogs in Cloud Storage.

Speicherort für Transaktionsprotokolle zu Cloud Storage wechseln

Wenn Ihre Instanz die für PITR verwendeten Transaktionslogs auf dem Laufwerk speichert, können Sie den Speicherort ohne Ausfallzeit auf Cloud Storage umstellen. Der Wechsel des Speicherorts dauert ungefähr so lange wie die Aufbewahrungsdauer des Transaktionslogs (in Tagen). Sobald Sie die Umstellung starten, werden Transaktionsprotokolle in Cloud Storage erstellt. Während des Vorgangs können Sie den Status des gesamten Prozesses mit dem Befehl in Speicherort von Transaktionslogs prüfen, die für PITR verwendet werden prüfen.

Nach Abschluss des gesamten Wechsels zu Cloud Storage verwendet Cloud SQL Transaktionslogs aus Cloud Storage für die Wiederherstellung zu einem bestimmten Zeitpunkt.

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 Replikationsinstanz 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 bei der Umstellung auf 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 Replikationsinstanz 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 Replikationsinstanz 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 des Transaktionslogs nach der Umstellung

Nachdem der Wechsel zu Cloud Storage für eine Instanz abgeschlossen ist, speichert Cloud SQL weiterhin Kopien binärer Logs zu Replikationszwecken auf dem Laufwerk. Das Speichern binärer Logs auf einem Laufwerk kann nützlich sein, wenn Sie binäre Logs mit dem Dienstprogramm mysqlbinlog durchsuchen möchten.

Wenn Sie die Flags expire_logs_days oder binlog_expire_logs_seconds vor der Umstellung 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 Umstellungsvorgangs den Wert der 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 Laufwerknutzung finden Sie unter Protokolle und Laufwerknutzung.

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 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. Das ist nur gültig, wenn die PITR-Funktion 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. Das ist nur gültig, wenn die PITR-Funktion 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. Das ist nur gültig, wenn die PITR-Funktion 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:

PITR mithilfe von binären Logpositionen ausführen

Wir empfehlen die Anwendung der Wiederherstellung zu einem bestimmten Zeitpunkt wie im Artikel Wiederherstellung zu einem bestimmten Zeitpunkt mit einem Zeitstempel ausführen beschrieben. Sie können aber die Wiederherstellung zu einem bestimmten Zeitpunkt auch ausführen, indem Sie eine bestimmte binäre Logposition in einer binären Logdatei angeben.

Weitere Informationen zur PITR mit 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ärprotokolle müssen auf dem Laufwerk verfügbar sein, damit Sie sie nach Ereignissen durchsuchen können. Informationen zur Aufbewahrungsdauer Ihrer binären Logs auf dem Laufwerk finden Sie unter Aufbewahrungsdauer von Logs. Sie können mit dem Dienstprogramm mysqlbinlog keine binären Logs durchsuchen, 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, 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.

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.

Probleme beim Wechsel zu Cloud Storage beheben

In der folgenden Tabelle sind mögliche Fehler aufgeführt, die mit dem Code INVALID REQUEST zurückgegeben werden können, wenn Sie den Speicherort der Transaktionsprotokolle vom Laufwerk zu 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. Führen Sie den Befehl gcloud aus oder senden Sie die API-Anfrage an eine Cloud SQL for MySQL- oder Cloud SQL for PostgreSQL-Instanz. Der Speicherort für Transaktionsprotokolle kann bei Cloud SQL for SQL Server nicht mit der gcloud CLI oder der Cloud SQL Admin API geändert werden.
MySQL transactional logging is not enabled on this instance. MySQL verwendet das binäre Logging als Transaktionsprotokolle für die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time-Recovery, PITR). Für die Unterstützung der PITR-Funktion müssen Sie in MySQL das binäre Logging für die 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, beim Ausführen des Befehls oder Senden der API-Anfrage eine Hauptinstanz anzugeben.
This instance is already storing transaction logs used for PITR in Cloud Storage Um den Speicherort der Transaktionsprotokolle zu prüfen, führen Sie den Befehl aus, der unter Speicherort der für PITR verwendeten Transaktionslogs prüfen beschrieben wird.
The instance is already switching transaction logs used for PITR from disk to Cloud Storage.

Warten Sie, bis der Vorgang abgeschlossen ist.

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

Nächste Schritte