Utilizzare 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, la copia incrementale del piano di recupero è abilitata quando crei un'istanza della versione Enterprise Plus di Cloud SQL, indipendentemente dal fatto che l'istanza venga creata utilizzando la console Google Cloud, gcloud CLI, Terraform o l'API Cloud SQL Admin.

Se crei un'istanza Cloud SQL Enterprise nella console Google Cloud, il PITR è attivo 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 l'archiviazione dei log delle transazioni per il PITR in Cloud Storage. Da questo lancio, si applicano le seguenti condizioni:

  • Tutte le istanze Cloud SQL nella versione Enterprise Plus archiviano i log binari utilizzati 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.

  • Le istanze Cloud SQL Enterprise Edition create con il PITR abilitato prima dell'11 agosto 2023 continueranno a memorizzare i log per il PITR sul 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 cambiare la posizione di archiviazione dei log delle transazioni utilizzati per la PITR da disco a Cloud Storage utilizzando l'interfaccia a riga di comando gcloud o l'API Cloud SQL Admin senza alcun tempo di riposo. Per ulteriori informazioni, consulta Passare lo spazio di archiviazione dei log delle transazioni a Cloud Storage.

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 non è impostato un valore per questo parametro, 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 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 automaticamente anche il valore dei flag expire_logs_days e binlog_expire_logs_seconds sull'equivalente di un giorno. Ciò corrisponde a un giorno di log sul disco.

Per i log binari PITR archiviati su disco, passano a Cloud Storage o che sono già state trasferite a Cloud Storage, Cloud SQL conserva i log per il valore minimo impostato per uno dei seguenti le seguenti configurazioni:

  • L'impostazione di configurazione del backup transactionLogRetentionDays

  • Il flag expire_logs_days o binlog_expire_logs_seconds

    Cloud SQL non imposta alcun valore per questi flag se i log binari sono archiviati su disco, se è in corso il passaggio a Cloud Storage o se è già stato eseguito il passaggio a Cloud Storage. Quando i log vengono archiviati sul disco, la modifica dei valori questi flag possono influenzare il comportamento del recupero PITR e il numero di giorni di log sono archiviati su disco. Non puoi modificare questi valori durante l'archiviazione dei log è in corso il passaggio a Cloud Storage. Inoltre, non consigliamo 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 con chiave di crittografia gestita dal cliente (CMEK), i log binari vengono criptati utilizzando la versione più recente della 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 utilizzano spazio di archiviazione. I log di tipo binario vengono eliminati automaticamente con il backup automatico associato, cosa che avviene quando viene raggiunto il valore impostato per transactionLogRetentionDays.

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 la dimensione dei binlog sul disco. Per le istanze che archiviano i log delle transazioni utilizzati per il PITR su disco, Cloud SQL esegue quotidianamente la pulizia dei dati dal disco per soddisfare l'impostazione transactionLogRetentionDays PITR, come descritto in Conservazione dei log delle transazioni e dei backup automatici. Tuttavia, se imposti il flag expire_logs_days o binlog_expire_logs_seconds su un valore inferiore ai giorni di conservazione dei log delle transazioni, Cloud SQL può eliminare 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 cambiare la posizione di archiviazione dei log utilizzati per il PITR dal disco a Cloud Storage senza tempi di inattività utilizzando gcloud CLI o l'API Cloud SQL Admin. 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, l'aumento della dimensione del log binario nell'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 sul disco, puoi disattivare la RPI senza riattivarla. Tuttavia, la riduzione dello spazio di archiviazione utilizzato non riduce le dimensioni del disco provisioned per l'istanza.

  • I log vengono eliminati una volta al giorno, non continuamente. Se imposti la conservazione dei log su due giorni, vengono 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 ulteriori informazioni sul PITR, consulta Recupero point-in-time (PITR).

Dopo aver completato il passaggio della posizione di archiviazione dei log delle transazioni a Cloud Storage, puoi liberare spazio su disco riducendo i valori dei flag expire_logs_days o binlog_expire_logs_seconds. Per controllare lo stato del passaggio, consulta Verificare la posizione di archiviazione dei log delle transazioni utilizzati per la copia incrementale a livello di blocco. Se vuoi rendere disponibili log aggiuntivi su disco, ad esempio per sfogliare i log binari l'utilità mysqlbinlog: e aumentare i valori di questi flag. Cloud SQL conserva i log binari su disco per il numero minimo di giorni di conservazione del log delle transazioni o per i valori impostati per i flag. Per ulteriori informazioni su come vengono archiviati i log per il PITR dopo il passaggio e su come liberare spazio su disco, consulta Log dopo il passaggio a Cloud Storage.

Attivare PITR

Quando crei una nuova istanza nella console Google Cloud, vengono attivati automaticamente sia Backup automatici sia Attiva il recupero point-in-time.

La procedura riportata di seguito consente di attivare il 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 attivare la copia incrementale in tempo reale 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 per conservare i log, da 1 a 35 per la versione Cloud SQL Enterprise Plus o da 1 a 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 nella sezione backupConfiguration viene visualizzato enabled: false, attiva 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, vedrai binaryLogEnabled: true se la modifica è andata a buon fine.

Terraform

Per attivare la 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 in un progetto Google Cloud, completa i passaggi nelle seguenti sezioni.

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 dedicata (inoltre chiamato modulo principale).

  1. In Cloud Shell, crea una directory e un nuovo all'interno di quella directory. Il nome 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 di esempio in ogni sezione o passaggio.

    Copia il codice campione nel nuovo oggetto main.tf.

    Facoltativamente, copia il codice da GitHub. Questa 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

    Se vuoi, per utilizzare la versione più recente del provider Google, includi l'opzione -upgrade: 

    terraform init -upgrade

Applica le modifiche

  1. Rivedi la configurazione e verifica che le risorse che Terraform sta per creare o aggiornare corrispondano alle 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 che Terraform mostri il messaggio "Applicazione completata".

  3. Apri il tuo 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, imposta il file di configurazione Terraform 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, apporta 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 della 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 di queste 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 della 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 di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Esegui il recupero point-in-time utilizzando un timestamp

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 ulteriori informazioni sull'utilità mysqlbinlog, consulta la documentazione di riferimento di 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 ulteriori informazioni, consulta Attivare la registrazione in formato binario.
  • Un timestamp per definire il punto di ripristino. Gli eventi che si verificano a partire da questo timestamp non vengono riportati 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 specifico 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 per l'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 punto nel tempo fino al quale eseguire il ripristino

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 di queste 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 punto nel tempo fino al quale eseguire il ripristino

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 di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Disattivare il ripristino dei punti di ripristino incrementali

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 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 di queste 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 di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Controlla la posizione di archiviazione dei log delle transazioni utilizzati per la copia incrementale in tempo reale

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.

Puoi anche controllare la posizione di archiviazione dei log delle transazioni per più istanze nello stesso progetto. Per determinare la posizione di più istanze, utilizza il seguente comando:

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

Esempio di risposta:

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

Nell'output del comando, transactionalLogStorageState o la colonna TRANSACTIONAL_LOG_STORAGE_STATE fornisce informazioni su dove la transazione i log per PITR vengono archiviati per l'istanza. I possibili stati di archiviazione dei log delle transazioni sono i seguenti:

  • DISK: l'istanza memorizza i log delle transazioni utilizzati per il PITR sul disco. Se esegui l'upgrade di un'istanza Cloud SQL Enterprise alla versione Cloud SQL Enterprise Plus, il processo di upgrade imposta automaticamente la posizione di archiviazione dei log su Cloud Storage. Per ulteriori informazioni, vedi Esegui l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade in loco. Puoi anche scegliere di cambiare la posizione di archiviazione utilizzando gcloud CLI o l'API Cloud SQL Admin senza eseguire l'upgrade della versione dell'istanza e senza che si verifichino tempi di riposo. Per ulteriori informazioni, consulta Passare lo spazio di archiviazione dei log delle transazioni a Cloud Storage.
  • 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.

Passa l'archiviazione dei log delle transazioni in Cloud Storage

Se l'istanza memorizza i log delle transazioni utilizzati per la PITR su disco, puoi cambiare la posizione di archiviazione in Cloud Storage senza tempi di riposo. La procedura generale per effettuare il passaggio la posizione di archiviazione impiega all'incirca la durata della conservazione dei log delle transazioni (giorni) da completare. Non appena Quando avvii il passaggio, i log delle transazioni iniziano ad accumularsi di archiviazione ideale in Cloud Storage. Durante l'operazione, puoi controllare lo stato della configurazione utilizzando il comando in Verificare la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.

Al termine della procedura complessiva di passaggio a Cloud Storage, Cloud SQL utilizza i log delle transazioni di Cloud Storage per il PITR.

gcloud

Per impostare la posizione di archiviazione su Cloud Storage, utilizza il seguente comando:

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

Sostituisci INSTANCE_NAME con il nome dell'istanza. L'istanza deve essere un'istanza principale e non un'istanza di replica. La risposta è simile alla seguente:

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

Se il comando restituisce un errore, vedi Se possibile, risolvi i problemi relativi al passaggio a Cloud Storage passaggi successivi.

REST v1

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

  • PROJECT_ID: l'ID progetto.
  • INSTANCE_ID: l'ID istanza. L'istanza deve essere un'istanza principale e non un'istanza di replica.

Metodo HTTP e URL: 

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

Corpo JSON della richiesta: 

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Se la richiesta restituisce un errore, consulta Risolvere i problemi relativi al passaggio a Cloud Storage per possibili passaggi successivi.

REST v1beta4

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

  • PROJECT_ID: l'ID progetto.
  • INSTANCE_ID: l'ID istanza. L'istanza deve essere un'istanza principale e non un'istanza di replica.

Metodo HTTP e URL: 

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

Corpo JSON della richiesta: 

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Se la richiesta restituisce un errore, consulta Risolvere i problemi relativi al passaggio a Cloud Storage per possibili passaggi successivi.

Archiviazione e configurazione dei log delle transazioni dopo il passaggio

Una volta completato il passaggio a Cloud Storage per un'istanza, Cloud SQL conserva comunque copie log binari su disco a scopo di replica. L'archiviazione dei log binari su disco può essere utile se vuoi sfogliare i log binari con l'utilità mysqlbinlog.

Se hai configurato i flag expire_logs_days o binlog_expire_logs_seconds nell'istanza prima del passaggio, i valori configurati rimangono invariati.

Dopo il passaggio, poiché i log binari utilizzati per eseguire la RPI sono ora archiviati in Cloud Storage, assicurati che i valori degli indicatori riflettano la conservazione dei log delle transazioni su disco prevista. Cloud SQL conserva solo su disco per il valore minimo di uno dei seguenti valori:

  • l'impostazione di configurazione PITR transactionLogRetentionDays prima del . Il valore predefinito per questa impostazione è 7 giorni.
  • i flag expire_logs_days o binlog_expire_logs_seconds impostati manualmente sull'istanza.

Se vuoi risparmiare spazio su disco, al termine del processo di passaggio, e configurare il valore dell'attributo expire_logs_days binlog_expire_logs_seconds flag a 1 giorno per ridurre la e i costi di archiviazione su disco allocati. Per ulteriori informazioni sull'archiviazione dei log delle transazioni e su PITR, consulta Archiviazione dei log per PITR.

Per ulteriori informazioni su come controllare l'utilizzo del disco, vedi Log e utilizzo del disco.

Imposta la conservazione dei log delle transazioni

Per impostare il numero di giorni per la conservazione dei 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 il recupero point-in-time, espandi Opzioni avanzate.
  5. Inserisci il numero di giorni per conservare i log, da 1 a 35 per la versione Cloud SQL Enterprise Plus o da 1 a 7 per la versione 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 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 è tra 1 e 7 giorni, con un valore predefinito di 7 giorni.

    Se non viene specificato alcun valore, viene utilizzato il valore predefinito. Questo è valido solo quando la copia incrementale del piano di recupero è attivata. Conservare più 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:

  • PROJECT_ID: l'ID progetto.
  • INSTANCE_ID: l'ID istanza.

  • DAYS_TO_RETAIN: il numero di giorni per conservare i log delle transazioni. 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 Enterprise di Cloud SQL, 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 più giorni di log delle transazioni richiede una dimensione di archiviazione maggiore.

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 di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

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

  • PROJECT_ID: l'ID progetto.
  • INSTANCE_ID: l'ID istanza.

  • DAYS_TO_RETAIN: il numero di giorni per conservare i log delle transazioni. 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 Enterprise di Cloud SQL, 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 più giorni di log delle transazioni richiede una dimensione di archiviazione maggiore.

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 di queste 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:

Identifica la posizione di recupero

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

    A tale scopo, utilizza Cloud Shell o la tua macchina client locale. Per ulteriori informazioni, consulta la sezione 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 visualizzata come punto di partenza per cercare il successivo insieme di eventi:

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

  5. Quando trovi l'evento che indica il punto in cui vuoi eseguire il ripristino, registra la posizione (mostrata 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 esempio di output 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 fino all'istruzione DROP TABLE, in grassetto sopra, devi utilizzare "865" in "mysql-bin.000011" come posizione di recupero. L'istruzione DROP TABLE e tutte le operazioni successive non vengono applicate alla 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 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 cercare 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, lo stato RUNNING è restituito. Al termine dell'operazione, viene restituito uno stato DONE.

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, apporta 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 di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Crea la nuova istanza utilizzando il nome del file del log binario e la 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 di queste 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 che hai 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 si riferisce a un momento in cui non è stato possibile trovare i backup o le coordinate del file binlog.

Risolvere i problemi di passaggio a Cloud Storage

Nella tabella seguente sono elencati i possibili errori che potrebbero verificarsi con il parametro Codice INVALID REQUEST quando cambi la posizione di archiviazione dei log delle transazioni dal disco in Cloud Storage.

Problema Risoluzione dei problemi
Switching the storage location of the transaction logs used for PITR is not supported for instances with database type %s. Assicurati di eseguire il comando gcloud CLI o di effettuare la richiesta API su un'istanza Cloud SQL per MySQL o Cloud SQL per PostgreSQL. Il cambio della posizione di archiviazione dei log delle transazioni utilizzando gcloud CLI o l'API Cloud SQL Admin non è supportato per Cloud SQL per SQL Server.
MySQL transactional logging is not enabled on this instance. MySQL utilizza il logging binario come log delle transazioni recupero point-in-time (PITR). Per supportare il PITR, MySQL richiede di abilitare il logging binario sull'istanza. Per ulteriori informazioni su come attivare la registrazione binaria, consulta Attivare il PITR.
This command is not supported on replica instances. Run the command on the primary instance instead. Assicurati di specificare un'istanza principale quando esegui il comando o effettui la richiesta API.
This instance is already storing transaction logs used for PITR in Cloud Storage Per verificare la posizione di archiviazione dei log delle transazioni, esegui il comando in Controllare la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.
The instance is already switching transaction logs used for PITR from disk to Cloud Storage.

Attendi il completamento dell'operazione.

Per verificare lo stato dell'operazione e la posizione di archiviazione dei log delle transazioni, esegui il comando in Controllare la posizione di archiviazione dei log delle transazioni utilizzati per la PITR.

Passaggi successivi