Usa il recupero point-in-time (PITR)

Questa pagina descrive come utilizzare il recupero point-in-time (PITR) per ripristinare l'istanza Cloud SQL principale.

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

Per impostazione predefinita, PITR è abilitato quando si crea un'istanza della versione Cloud SQL Enterprise Plus, indipendentemente dal fatto che venga creata 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 è abilitato per impostazione predefinita. In caso contrario, se crei l'istanza utilizzando 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, si applicano le seguenti condizioni:

  • Tutte le istanze della versione Cloud SQL Enterprise Plus archiviano i log binari utilizzati per il PITR in Cloud Storage. Solo le istanze della versione Cloud SQL Enterprise Plus per cui hai eseguito l'upgrade dalla versione Cloud SQL Enterprise prima del 1° aprile 2024 e per le quali PITR è abilitato prima dell'11 agosto 2023 continuano ad archiviare i log per il PITR su disco.
  • Le istanze della versione Cloud SQL Enterprise create con PITR abilitato prima dell'11 agosto 2023 continuano ad archiviare i log per PITR su disco.
  • Se dopo il 1° aprile 2024 esegui l'upgrade di un'istanza della versione Cloud SQL Enterprise che archivia i log delle transazioni per PITR su disco alla versione Cloud SQL Enterprise Plus, il processo di upgrade trasferisce la posizione di archiviazione dei log delle transazioni utilizzati per PITR in Cloud Storage per te. Per ulteriori informazioni, consulta Eseguire 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 archiviano i log utilizzati per PITR in Cloud Storage.

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

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

Registra periodo di conservazione

Cloud SQL conserva i log delle transazioni in Cloud Storage fino al valore impostato nell'impostazione di configurazione PITR transactionLogRetentionDays. 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 un valore per questo parametro non è impostato, il periodo di conservazione predefinito dei log delle transazioni è di 14 giorni per le istanze della versione Cloud SQL Enterprise Plus e di 7 giorni per le istanze della versione Cloud SQL Enterprise. Per ulteriori informazioni su come 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 per il PITR in Cloud Storage, conserva anche un numero inferiore di log binari duplicati su disco per consentire la replica dei log in Cloud Storage. Per impostazione predefinita, quando crei un'istanza con PITR abilitato, l'istanza archivia i log binari per PITR in Cloud Storage. Cloud SQL imposta inoltre automaticamente il valore dei flag expire_logs_days e binlog_expire_logs_seconds sull'equivalente di un giorno. Ciò si traduce in un giorno di log su disco.

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

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

  • L'impostazione di configurazione del backup di transactionLogRetentionDays
  • Il flag expire_logs_days o binlog_expire_logs_seconds

    La modifica dei valori di questi flag può influire sul comportamento del recupero PITR e sul numero di giorni di log archiviati sul disco. Sconsigliamo di configurare il valore di nessuno di questi flag su 0. Per ulteriori informazioni su questi flag, consulta Configurare i flag di database.

Per le istanze abilitate per la chiave di crittografia gestita dal cliente (CMEK), i log binari vengono criptati utilizzando la versione più recente di CMEK. Per eseguire un ripristino, devono essere disponibili tutte le versioni della chiave che erano le ultime per il numero di giorni configurato per il parametro retained-transaction-log-days.

Log e utilizzo del disco

I log vengono generati regolarmente e occupano spazio di archiviazione. I log binari vengono eliminati automaticamente con il backup automatico associato, che si verifica una volta raggiunto il valore impostato per transactionLogRetentionDays.

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

Se le dimensioni dei log binari causano un problema per l'istanza:

  • Verifica se l'istanza sta memorizzando i log su disco. Puoi spostare i log utilizzati per PITR dal disco a Cloud Storage disattivando e riattivando PITR. Questa operazione comporta un tempo di inattività di pochi minuti, ma libera spazio su disco. Se utilizzi Cloud SQL Enterprise Edition, puoi anche eseguire l'upgrade alla versione Cloud SQL Enterprise Plus per cambiare la località di archiviazione dei log PITR.
  • Puoi aumentare la dimensione dello spazio di archiviazione dell'istanza. Tuttavia, l'aumento delle dimensioni del log binario nell'utilizzo del disco potrebbe essere temporaneo.

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

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

  • I log vengono eliminati definitivamente una volta al giorno, non in modo continuo. Se imposti la conservazione dei log su due giorni, verranno conservati almeno due giorni di log e al massimo tre giorni di log. 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 maggiori informazioni sul PITR, consulta la pagina Recupero point-in-time (PITR).

Abilita PITR

Quando crei una nuova istanza nella console Google Cloud, Backup automatici e Abilita recupero point-in-time vengono entrambi abilitati automaticamente.

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

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 su cui vuoi abilitare il PITR e fai 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 o 1-7 per la versione 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 nella sezione backupConfiguration, abilita i backup pianificati:
    gcloud sql instances patch INSTANCE_NAME \
    --backup-start-time=HH:MM
    

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

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

    Se abiliti PITR su un'istanza principale, puoi anche configurare il numero di giorni per cui vuoi 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, vedrai binaryLogEnabled: true se la modifica è riuscita.

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 tua configurazione Terraform a un progetto Google Cloud, completa i passaggi nelle sezioni seguenti.

Prepara Cloud Shell

  1. Avvia Cloud Shell.
  2. Imposta il progetto Google Cloud predefinito a cui 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 nel file di configurazione Terraform.

Prepara la directory

Ogni file di configurazione Terraform deve avere la propria directory (chiamata anche modulo principale).

  1. In Cloud Shell, crea una directory e un nuovo file al suo interno. Il nome del file deve avere l'estensione .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. Questa opzione è consigliata se 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 l'opzione -upgrade:

    terraform init -upgrade

Applica le modifiche

  1. Esamina la configurazione e verifica che le risorse che Terraform creerà o aggiornerà soddisfino le tue aspettative:
    terraform plan

    Apporta le correzioni necessarie alla configurazione.

  2. Applica la configurazione Terraform eseguendo questo comando e inserendo yes al prompt:
    terraform apply

    Attendi finché in Terraform non viene visualizzato 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 che Terraform le abbia create o aggiornate.

Elimina le modifiche

Per eliminare le modifiche:

  1. Per disabilitare la protezione dall'eliminazione, imposta l'argomento deletion_protection nel file di configurazione di Terraform su false.
    deletion_protection =  "false"
  2. Applica la configurazione Terraform aggiornata eseguendo questo comando e inserendo yes al prompt:
    terraform apply
  1. Per rimuovere le risorse applicate in precedenza con la tua configurazione Terraform, esegui questo comando e inserisci 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'approccio consigliato per eseguire il PITR è usare i timestamp. Cloud SQL usa l'utilità mysqlbinlog per ripristinare le istanze 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:

  • Log binario e backup abilitati per l'istanza, con log binari continui 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 in corrispondenza e dopo questo timestamp non si riflettono 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 che vuoi recuperare 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 - Nome dell'istanza da cui stai eseguendo il ripristino.
  • NEW_INSTANCE_NAME: nome del clone.
  • TIMESTAMP: fuso orario UTC per l'istanza di origine nel formato RFC 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, vedrai binaryLogEnabled: false se la modifica è riuscita.

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 controllare dove l'istanza Cloud SQL memorizza i log delle transazioni utilizzati per PITR.

gcloud

Per determinare se l'istanza archivia i log per PITR su disco o su Cloud Storage, utilizza il seguente comando:

   gcloud sql instances describe INSTANCE_NAME
   

Sostituisci INSTANCE_NAME con il nome dell'istanza.

Nell'output del comando, il campo transactionalLogStorageState fornisce informazioni sulla posizione in cui sono archiviati i log delle transazioni per PITR per l'istanza. I possibili stati di archiviazione dei log delle transazioni sono i seguenti:

  • DISK: l'istanza archivia i log delle transazioni utilizzati 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 maggiori informazioni, consulta Eseguire l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade in loco.
  • SWITCHING_TO_CLOUD_STORAGE: l'istanza sta passando a Cloud Storage dalla località di archiviazione dei log delle transazioni PITR.
  • SWITCHED_TO_CLOUD_STORAGE: l'istanza ha completato il passaggio della posizione di archiviazione per i log delle transazioni PITR dal disco a Cloud Storage.
  • CLOUD_STORAGE: l'istanza archivia i 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 su cui 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 o 1-7 per la versione Cloud SQL Enterprise.
  6. Fai clic su Salva.

gcloud

Modifica l'istanza per impostare il numero di giorni in cui conservare i log binari.

Sostituisci quanto segue:

  • INSTANCE-NAME - Il nome dell'istanza su cui vuoi 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 è compreso 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 dimensioni di archiviazione maggiori.

  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

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

Per ulteriori informazioni su PITR utilizzando le posizioni dei log binari, consulta la documentazione di riferimento di MySQL PITR utilizzando il log binario.

Prima di iniziare

Prima di completare questa attività, devi avere:

  • Logging binario e backup abilitati per l'istanza, con log binari continui dall'ultimo backup prima dell'evento da cui vuoi eseguire il ripristino. Per saperne di più, consulta Abilitare il logging binario.

  • I log binari devono essere disponibili sul disco per poter sfogliare gli eventi. Per controllare la durata della conservazione dei log binari sul disco, consulta Periodo di conservazione dei log. Non puoi sfogliare i log binari archiviati in Cloud Storage con l'utilità mysqlbinlog.

  • Un nome file di log binario e la posizione dell'evento da cui vuoi recuperare (quest'evento e tutti gli eventi successivi non sono riflessi nella nuova istanza). Per saperne di più, consulta Identificare la posizione del log binario.

    Dopo aver identificato il nome file e la posizione del log binario, esegui il PITR utilizzando le posizioni degli eventi dei 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 le 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 regolare il numero di righe da mostrare, ma non mostrare tutti gli eventi nel file finché non conosci le dimensioni del file. La visualizzazione di 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 visualizzata come punto di partenza per cercare il gruppo di eventi successivo:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
    
  5. Quando trovi l'evento che contrassegna il momento in cui vuoi eseguire il ripristino, registra 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 il 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, dovresti usare "865" in "mysql-bin.000011" come posizione di ripristino. L'istruzione DROP TABLE e tutte le operazioni successive non vengono riflesse nella nuova istanza.

Eseguire il PITR utilizzando le posizioni degli eventi di log binari

gcloud

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

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

    Sostituisci quanto segue:

    • SOURCE_INSTANCE_NAME: nome dell'istanza da cui stai eseguendo il ripristino.
    • 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 fino 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 essere 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 verificare lo stato dell'operazione di ripristino.
    gcloud sql operations describe OPERATION_ID

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

REST v1

Crea la nuova istanza utilizzando il nome file e la posizione di ripristino del log binario 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 la posizione di ripristino 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:

Risolvere i 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

OR

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.

OR

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 momento in cui i backup o in cui non è stato possibile trovare le coordinate binlog.

Passaggi successivi