Usa il recupero point-in-time (PITR)

In questa pagina viene descritto come utilizzare il recupero point-in-time (PITR) per ripristinare dell'istanza Cloud SQL principale.

Per scoprire di più sul PITR, consulta: Recupero point-in-time (PITR).

Per impostazione predefinita, PITR è abilitato quando crei un'istanza della versione Cloud SQL Enterprise Plus, indipendentemente o meno di creare l'istanza utilizzando la console Google Cloud gcloud CLI, Terraform o l'API Cloud SQL Admin.

Se crei un'istanza della versione Cloud SQL Enterprise nella console Google Cloud, il PITR viene sono abilitate per impostazione predefinita. Altrimenti, se crei l'istanza utilizzando il comando gcloud CLI, Terraform o l'API Cloud SQL Admin, devi abilitare manualmente PITR.

Archiviazione dei log per PITR

Cloud SQL utilizza i log binari per PITR.

L'11 agosto 2023 abbiamo lanciato la memorizzazione dei log delle transazioni per PITR in Cloud Storage. Da questo lancio, le seguenti condizioni applica:

  • Tutte le istanze della versione Cloud SQL Enterprise Plus archiviano i log binari utilizzata per il PITR in Cloud Storage. Soltanto le istanze della versione Cloud SQL Enterprise Plus ha eseguito l'upgrade dalla versione Cloud SQL Enterprise prima del 1° aprile 2024 con PITR abilitato prima dell'11 agosto 2023 continueranno ad archiviare i propri log per PITR su disco.
  • Istanze della versione Cloud SQL Enterprise create con PITR abilitato prima dell'11 agosto 2023 continueranno ad archiviare i propri log per il PITR su disco.
  • Se esegui l'upgrade di un'istanza della versione Cloud SQL Enterprise dopo il 1° aprile 2024 che archivia log delle transazioni per PITR su disco alla versione Cloud SQL Enterprise Plus, quindi l'upgrade il processo cambia la posizione di archiviazione dei log delle transazioni utilizzati per il PITR in Cloud Storage per te. Per ulteriori informazioni, vedi Esegui l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade in loco.
  • Tutte le istanze della versione Cloud SQL Enterprise che crei con PITR abilitato dopo L'11 agosto 2023 archivia i log utilizzati per il PITR in Cloud Storage.

Per ulteriori informazioni su come controllare la posizione di archiviazione della transazione log utilizzati per PITR, consulta Controlla la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.

Per le istanze che archiviano i log binari solo su disco, puoi: anche spostare i log dal disco a Cloud Storage disattivando prima e riabilitando PITR.

Registra periodo di conservazione

Cloud SQL conserva i log delle transazioni in Cloud Storage per un massimo impostato nel campo transactionLogRetentionDays Impostazione di configurazione PITR. Questo valore può variare da 1 a 35 giorni per la versione Cloud SQL Enterprise Plus e da 1 a 7 giorni per la versione Cloud SQL Enterprise. Se non viene impostato un valore per questo parametro, il periodo di conservazione predefinito dei log delle transazioni è di 14 giorni per la versione Cloud SQL Enterprise Plus e 7 giorni per le istanze della versione Cloud SQL Enterprise. Per ulteriori informazioni per impostare i giorni di conservazione dei log delle transazioni consulta Impostare la conservazione dei log delle transazioni.

Sebbene un'istanza archivi i log binari utilizzati PITR in Cloud Storage, l'istanza conserva anche un numero inferiore duplicati di log binari sul disco per consentire la replica in Cloud Storage. Per impostazione predefinita, quando crei un'istanza con PITR abilitato, l'istanza archivia i propri log binari per PITR in Cloud Storage. Cloud SQL imposta anche il valore expire_logs_days e binlog_expire_logs_seconds l'equivalente di un giorno automaticamente. Ciò si traduce in un giorno di log su disco.

Riducendo i valori delle impostazioni di questi flag, Cloud SQL ti aiuta a risparmiare sull'utilizzo del disco costi aggiuntivi. Tuttavia, se vuoi che ulteriori log siano disponibili su disco, ad esempio per sfogliare i log binari con l'utilità mysqlbinlog: e aumenta i valori di questi flag. Cloud SQL conserva log binari su disco per il minimo di log delle transazioni giorni di conservazione o i valori impostati per i flag.

Per i log binari utilizzati per il PITR che vengono archiviati su disco, Cloud SQL conserva i log per il valore minimo impostato per uno dei le seguenti configurazioni:

  • L'impostazione di configurazione del backup di transactionLogRetentionDays
  • L'expire_logs_days o la bandiera binlog_expire_logs_seconds

    La modifica dei valori di questi flag può influenzare il comportamento del PITR il ripristino e il numero di giorni di log archiviati su disco. Non ti consigliamo di configurare il valore di uno di questi flag su 0. Per ulteriori informazioni vedi Configurare i flag di database.

Per istanze abilitate per chiave di crittografia gestita dal cliente (CMEK) i log binari vengono criptati utilizzando l'ultima versione tramite CMEK. Per eseguire un ripristino, tutte le versioni della chiave che erano le ultime per il numero di giorni in cui hai configurato Il parametro retained-transaction-log-days deve essere disponibile.

Log e utilizzo del disco

I log vengono generati regolarmente e occupano spazio di archiviazione. Il file binario di log vengono automaticamente eliminati insieme al backup automatico associato. avviene dopo il valore impostato transactionLogRetentionDays viene rispettata.

Per scoprire quanto disco viene utilizzato dai log binari, controlla bytes_used_by_data_type per l'istanza. Il valore del tipo di dati binlog restituisce il valore la dimensione dei binlog sul disco. Per le istanze che archiviano i log delle transazioni utilizzata per il PITR su disco, Cloud SQL elimina ogni giorno i dati dal disco per soddisfare le transactionLogRetentionDays impostazione PITR, come descritto in Backup automatico e conservazione dei log delle transazioni. Tuttavia, se imposti il flag expire_logs_days inferiore ai giorni di conservazione dei log delle transazioni Cloud SQL può eliminare definitivamente i log binari prima.

Se le dimensioni dei log binari sono la causa di un problema per la tua istanza:

  • Verifica se l'istanza sta memorizzando i log su disco. Puoi spostare i log utilizzati per il PITR dal disco a Cloud Storage disattivazione e riattivazione PITR Questa operazione comporta un tempo di inattività di alcuni minuti ma libera spazio su disco. Se utilizzi Cloud SQL Enterprise Edition, puoi Inoltre, esegui l'upgrade alla versione Cloud SQL Enterprise Plus per cambiare lo spazio di archiviazione dei log PITR.
  • Puoi aumentare la dimensione dello spazio di archiviazione dell'istanza. Tuttavia, il file binario dell'utilizzo del disco potrebbe essere temporaneo.

  • Ti consigliamo di attivare aumento automatico dello spazio di archiviazione per evitare problemi di archiviazione imprevisti.

  • Se vuoi eliminare i log e recuperare spazio di archiviazione, puoi disattivare PITR senza riattivarlo. Tuttavia, la riduzione dello spazio di archiviazione utilizzato non riduce le dimensioni del disco di cui è stato eseguito il provisioning per l'istanza.

  • I log vengono eliminati definitivamente una volta al giorno, non in modo continuo. Imposta la conservazione dei log su due giorni significa che almeno due giorni di log e al massimo tre giorni di log vengono vengono mantenuti. Ti consigliamo di impostare il numero di backup su uno in più rispetto ai giorni di conservazione dei log.

    Ad esempio, se specifichi 7 per il valore del parametro transactionLogRetentionDays, imposta il numero di retainedBackups su 8 per il parametro backupRetentionSettings.

Per ulteriori informazioni sul PITR, consulta Recupero point-in-time (PITR).

Abilita PITR

Quando crei una nuova istanza nella console Google Cloud, vengono utilizzati entrambi i backup e Abilita il recupero point-in-time vengono in un bucket con il controllo delle versioni attivo.

La seguente procedura abilita il PITR su un modello esistente dell'istanza principale.

Console

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Apri il menu Altre azioni Icona Altre azioni. per l'istanza attivare il PITR e fare clic su Modifica.
  3. In Personalizza la tua istanza, espandi la Sezione Protezione dei dati.
  4. Seleziona la casella di controllo Abilita recupero point-in-time.
  5. Nel campo Giorni di log, inserisci il numero di giorni in cui conservare i log, compreso tra 1 e 35 per la versione Cloud SQL Enterprise Plus oppure 1-7 per Cloud SQL Enterprise.
  6. Fai clic su Salva.

gcloud

  1. Visualizza la panoramica dell'istanza:
    gcloud sql instances describe INSTANCE_NAME
    
  2. Se vedi enabled: false nel Sezione backupConfiguration, abilita i backup pianificati:
    gcloud sql instances patch INSTANCE_NAME \
    --backup-start-time=HH:MM
    

    Specifica il parametro backup-start-time utilizzando l'opzione 24 ore nel fuso orario UTC±00.

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

    Se attivi PITR su una principale, puoi anche configurare il numero di giorni per cui per conservare i log delle transazioni aggiungendo il seguente parametro:

    --retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
    
  4. Conferma la modifica:
    gcloud sql instances describe INSTANCE_NAME

    Nella sezione backupConfiguration, puoi vedere binaryLogEnabled: true se la modifica è andata a buon fine.

Terraform

Per abilitare PITR, utilizza una risorsa Terraform.

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
}

Applica le modifiche

Per applicare la configurazione Terraform a un progetto Google Cloud, completa i passaggi nella le sezioni seguenti.

Prepara Cloud Shell

  1. Avvia Cloud Shell.
  2. Imposta il progetto Google Cloud predefinito dove vuoi applicare le configurazioni Terraform.

    Devi eseguire questo comando una sola volta per progetto e puoi eseguirlo in qualsiasi directory.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Le variabili di ambiente vengono sostituite se imposti valori espliciti in Terraform di configurazione del deployment.

Prepara la directory

Ogni file di configurazione Terraform deve avere una directory (inoltre chiamato modulo principale).

  1. In Cloud Shell, crea una directory e un nuovo all'interno di quella directory. Il nome file deve contenere i caratteri .tf, ad esempio main.tf. In questo tutorial, il file è denominato main.tf.
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf
  2. Se stai seguendo un tutorial, puoi copiare il codice campione in ogni sezione o passaggio.

    Copia il codice campione nel nuovo oggetto main.tf.

    Facoltativamente, copia il codice da GitHub. Opzione consigliata quando lo snippet Terraform fa parte di una soluzione end-to-end.

  3. Esamina e modifica i parametri di esempio da applicare al tuo ambiente.
  4. Salva le modifiche.
  5. Inizializza Terraform. Devi eseguire questa operazione una sola volta per directory.
    terraform init

    Facoltativamente, per utilizzare la versione più recente del provider Google, includi -upgrade :

    terraform init -upgrade

Applica le modifiche

  1. Rivedi la configurazione e verifica che le risorse che Terraform creerà o che l'aggiornamento soddisfi le tue aspettative:
    terraform plan

    Apporta le correzioni necessarie alla configurazione.

  2. Applica la configurazione Terraform eseguendo questo comando e inserendo yes alla richiesta:
    terraform apply

    Attendi finché Terraform non visualizzi il messaggio "Applicazione completata!". .

  3. Apri il progetto Google Cloud per visualizzare i risultati. Nella console Google Cloud, vai alle risorse nella UI per assicurarti create o aggiornate da Terraform.

Elimina le modifiche

Per eliminare le modifiche:

  1. Per disabilitare la protezione dall'eliminazione, nel file di configurazione Terraform imposta la classe Argomento deletion_protection per false.
    deletion_protection =  "false"
  2. Applica la configurazione Terraform aggiornata eseguendo il comando seguente inserendo yes alla richiesta:
    terraform apply
  1. Rimuovi le risorse applicate in precedenza con la tua configurazione Terraform eseguendo questo comando e inserendo yes al prompt:

    terraform destroy

REST v1

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud che contiene l'istanza
  • INSTANCE_NAME: il nome dell'istanza principale o di replica di lettura che stai configurando per l'alta disponibilità
  • START_TIME: l'ora (in ore e minuti)

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud che contiene l'istanza
  • INSTANCE_NAME: il nome dell'istanza principale o di replica di lettura che stai configurando per l'alta disponibilità
  • START_TIME: l'ora (in ore e minuti)

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Esegui il PITR in base a un timestamp con uso

L'utilizzo dei timestamp è l'approccio consigliato per eseguire PITR Cloud SQL utilizza l'utilità mysqlbinlog per il ripristino fino a un momento specifico. Per saperne di più sull'utilità mysqlbinlog, consulta la documentazione di riferimento MySQL.

Per completare la seguente attività, devi disporre di quanto segue:

  • Logging binario e backup abilitati per l'istanza, con programma binario continuo log dall'ultimo backup prima dell'evento da cui vuoi recuperare. Per saperne di più, consulta Abilitare il logging binario.
  • Un timestamp per definire il punto di ripristino. Gli eventi che si verificano durante e dopo questo timestamp non si riflette nella nuova istanza.

Console

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Apri il menu Altre azioni Icona Altre azioni. per l'istanza da ripristinare e fai clic su Crea clone.
  3. Se vuoi, nella pagina Crea un clone, aggiorna l'ID del nuovo clone.
  4. Seleziona Clona da un momento precedente.
  5. Inserisci un'ora PITR.
  6. Fai clic su Crea clone.

gcloud

Crea un clone utilizzando PITR.

Sostituisci quanto segue:

  • SOURCE_INSTANCE_NAME - Il nome dell'istanza che stai ripristino da.
  • NEW_INSTANCE_NAME: nome del clone.
  • TIMESTAMP: fuso orario UTC dell'istanza di origine in RFC formato 3339. Ad esempio 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time 'TIMESTAMP'

REST v1

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • target-instance-id: l'ID istanza di destinazione
  • source-instance-id: l'ID dell'istanza di origine
  • restore-timestamp Il momento in cui eseguire il ripristino fino a

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • target-instance-id: l'ID istanza di destinazione
  • source-instance-id: l'ID dell'istanza di origine
  • restore-timestamp Il momento in cui eseguire il ripristino fino a

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Disattiva PITR

Console

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Apri il menu Altre azioni Icona Altre azioni. per l'istanza da disattivare e seleziona Modifica.
  3. In Personalizza la tua istanza, espandi la sezione Protezione dei dati .
  4. Deseleziona l'opzione Abilita recupero point-in-time.
  5. Fai clic su Salva.

gcloud

  1. Disattiva il recupero point-in-time:
    gcloud sql instances patch INSTANCE_NAME \
    --no-enable-bin-log
  2. Conferma la modifica:
    gcloud sql instances describe INSTANCE_NAME
    

    Nella sezione backupConfiguration, puoi vedere binaryLogEnabled: false se la modifica è andata a buon fine.

REST v1

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • instance-id: l'ID istanza

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • instance-id: l'ID istanza

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Controlla la posizione di archiviazione dei log delle transazioni utilizzati per il PITR

Puoi verificare dove l'istanza Cloud SQL archivia la transazione log utilizzati per PITR.

gcloud

per determinare se la tua istanza archivia i log per PITR disco o Cloud Storage, utilizza il comando seguente:

   gcloud sql instances describe INSTANCE_NAME
   

Sostituisci INSTANCE_NAME con il nome dell'istanza.

Nell'output del comando, il campo transactionalLogStorageState fornisce informazioni sul punto in cui viene eseguita la transazione i log per PITR vengono archiviati per l'istanza. Il log delle possibili transazioni sono i seguenti:

  • DISK: l'istanza archivia i log delle transazioni utilizzata per il PITR su disco. Se esegui l'upgrade di un'istanza dalla versione Cloud SQL Enterprise a Cloud SQL Enterprise Plus, il processo di upgrade cambia anche la posizione di archiviazione dei log in Cloud Storage. Per ulteriori informazioni, vedi Esegui l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade in loco.
  • SWITCHING_TO_CLOUD_STORAGE: l'istanza è la posizione di archiviazione dei log delle transazioni PITR in Cloud Storage.
  • SWITCHED_TO_CLOUD_STORAGE: l'istanza ha ha completato la posizione di archiviazione per i log delle transazioni PITR dal disco a Cloud Storage.
  • CLOUD_STORAGE: l'istanza archivia log delle transazioni utilizzati per il PITR in Cloud Storage.

Imposta la conservazione dei log delle transazioni

Per impostare il numero di giorni in cui conservare i log binari:

Console

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Apri il menu Altre azioni Icona Altre azioni. per l'istanza vuoi impostare il log delle transazioni e seleziona Modifica.
  3. In Personalizza la tua istanza, espandi la sezione Protezione dei dati .
  4. Nella sezione Abilita recupero point-in-time, espandi Opzioni avanzate.
  5. Inserisci il numero di giorni in cui conservare i log, compreso tra 1 e 35 per la versione Cloud SQL Enterprise Plus oppure 1-7 per Cloud SQL Enterprise.
  6. Fai clic su Salva.

gcloud

Modifica l'istanza per impostare il numero di giorni da conservare log binari.

Sostituisci quanto segue:

  • INSTANCE-NAME: il nome dell'istanza che vuoi e impostare il log delle transazioni.
  • DAYS-TO-RETAIN: il numero di giorni di log delle transazioni da conservare. Per la versione Cloud SQL Enterprise Plus, l'intervallo valido è compreso tra 1 e 35 giorni, con un valore predefinito di 14 giorni. Per la versione Cloud SQL Enterprise, l'intervallo valido è tra 1 e 7 giorni, con un valore predefinito di 7 giorni. Se non viene specificato alcun valore, viene utilizzato il valore predefinito. Valido solo quando il PITR è abilitato. Conservare un numero maggiore di giorni di log delle transazioni richiede uno spazio di archiviazione maggiore dimensioni.

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

REST v1

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • days-to-retain: il numero di giorni in cui i log delle transazioni devono essere conservati, compreso tra 1 e 7
  • project-id: l'ID progetto
  • instance-id: l'ID istanza

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • days-to-retain: il numero di giorni in cui i log delle transazioni devono essere conservati, compreso tra 1 e 7
  • project-id: l'ID progetto
  • instance-id: l'ID istanza

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Eseguire il PITR utilizzando le posizioni dei log binari

Consigliamo di eseguire il PITR utilizzando i timestamp descritto in Eseguire il PITR utilizzando un timestamp, puoi anche fornendo una posizione specifica di log binario in un file di log binario.

Per ulteriori informazioni sul PITR che utilizza le posizioni dei log binari, consulta la sezione di riferimento di MySQL, PITR con il log binario.

Prima di iniziare

Prima di completare questa attività, devi avere:

  • Logging binario e backup abilitati per l'istanza, con programma binario continuo log dall'ultimo backup precedente all'evento da cui vuoi eseguire il recupero. Per saperne di più, consulta Abilitare il logging binario.

  • I log binari devono essere disponibili su disco per poter sfogliarli per trovare eventi. Per controllare la durata della conservazione dei log binari disco, consulta Periodo di conservazione dei log. Non puoi sfogliare i log binari archiviati in Cloud Storage con Utilità mysqlbinlog.

  • Il nome file di un log binario e la posizione dell'evento a cui da (quell'evento e tutti gli eventi accaduti dopo che non saranno visibili nella nuova istanza). Per saperne di più, consulta Identificare la posizione del log binario.

    Dopo aver identificato il nome e la posizione del log binario, esegui il PITR utilizzando le posizioni degli eventi di log binari.

Identifica la posizione di recupero

  1. Utilizza il client MySQL per connetterti all'istanza su cui vuoi eseguire il ripristino.

    Per farlo, utilizza Cloud Shell o il tuo computer client locale. Per ulteriori informazioni, vedi Opzioni di connessione per applicazioni esterne.

  2. Mostra i file di log binari per l'istanza:

    SHOW BINARY LOGS;
    
  3. Visualizza i primi 100 eventi nel file di log binario più recente:

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

    Puoi modificare il numero di righe da mostrare, ma non mostrarle tutte gli eventi nel file fino a quando non ne conosci le dimensioni. La visualizzazione di un un numero elevato di eventi può influire sulle prestazioni del sistema.

  4. Se l'evento che stai cercando non viene visualizzato, utilizza l'ultima posizione visualizzato come punto di partenza per cercare la serie successiva di eventi:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
    
  5. Quando trovi l'evento che segna il momento specifico da ripristinare. registrare la posizione (indicata come Pos) e il nome del file di log binario.

    Il nome del file e la posizione del log binario sono i valori che utilizzi per PITR

Di seguito è riportato un output di esempio del comando 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)

Per ripristinare l'istruzione DROP TABLE, in grassetto sopra, devi utilizza "865" in "mysql-bin.000011" come il posizione di recupero. L'istruzione DROP TABLE e tutte le operazioni successive non lo saranno nella nuova istanza.

Eseguire il PITR utilizzando le posizioni degli eventi di log binari

gcloud

Utilizza la gcloud sql instances clone con --bin-log-file-name e --bin-log-position e i flag facoltativi.

  1. Crea la nuova istanza utilizzando il nome file e il ripristino del log binario posizione.

    Sostituisci quanto segue:

    • SOURCE_INSTANCE_NAME: nome dell'istanza che stai ripristino da.
    • NEW_INSTANCE_NAME: nome del clone.
    • BINLOG_FILE_NAME: nome del log binario, ad esempio mysql-bin.187288.
    • POSITION: la posizione nel log binario da ripristinare a, ad esempio 50001356.
    gcloud sql instances clone SOURCE_INSTANCE_NAME \
    NEW_INSTANCE_NAME \
    --bin-log-file-name="BINLOG_FILE_NAME" \
    --bin-log-position=POSITION

    Ad esempio, un comando gcloud sql instances clone potrebbe guardare simile al seguente:

    gcloud sql instances clone instance1 \
    instance1-clone \
    --bin-log-file-name=mysql-bin.0000031 \
    --bin-log-position=107 \
  2. Utilizza l'ID operazione restituito dal comando clone per controlla lo stato dell'operazione di ripristino.
    gcloud sql operations describe OPERATION_ID

    Quando l'operazione è in corso, lo stato RUNNING è restituito. Al termine dell'operazione, lo stato DONE viene restituito.

REST v1

Crea la nuova istanza utilizzando il nome file e il ripristino del log binario posizione che hai identificato:

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • target-instance-id: l'ID istanza di destinazione
  • source-instance-id: l'ID dell'istanza di origine
  • binary-log-file-name Il nome del file di log binario.
  • binary-log-position La posizione all'interno del file di log binario

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Crea la nuova istanza utilizzando il nome del file di log binario e posizione di recupero che hai identificato:

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • project-id: l'ID progetto
  • target-instance-id: l'ID istanza di destinazione
  • source-instance-id: l'ID dell'istanza di origine
  • binary-log-file-name Il nome del file di log binario.
  • binary-log-position La posizione all'interno del file di log binario

Metodo HTTP e URL:

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

Corpo JSON della richiesta:

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

Per inviare la richiesta, espandi una delle seguenti opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Risoluzione dei problemi

Problema Risoluzione dei problemi

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

OPPURE

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

Il timestamp fornito non è valido.

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

OPPURE

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

Il timestamp che hai fornito è relativo a un orario in cui i backup o Impossibile trovare le coordinate binlog.

Passaggi successivi