Utilizzare il recupero point-in-time (PITR)

MySQL | PostgreSQL | SQL Server

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

Per impostazione predefinita, il PITR viene abilitato quando crei 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 viene 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 log per PITR

Cloud SQL utilizza log binari per il 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 della versione Cloud SQL Enterprise Plus archiviano i log binari utilizzati per PITR in Cloud Storage. Solo le istanze della versione Cloud SQL Enterprise Plus di cui hai eseguito l'upgrade dalla versione Cloud SQL Enterprise prima del 1° aprile 2024 e per cui avevi abilitato PITR prima dell'11 agosto 2023 continuano ad archiviare i propri log per 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 esegui l'upgrade di un'istanza della versione Cloud SQL Enterprise dopo il 1° aprile 2024 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 il PITR in Cloud Storage. Per maggiori 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 maggiori informazioni su come verificare la posizione di archiviazione dei log delle transazioni utilizzati per il PITR, consulta Controllare 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 poi riattivando PITR.

Periodo di conservazione dei log

Cloud SQL conserva i log delle transazioni in Cloud Storage fino al valore impostato nell'impostazione di configurazione PITR di transactionLogRetentionDays. Questo valore può variare da 1 a 35 giorni per la versione Cloud SQL Enterprise Plus e da 1 a 7 giorni per 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 saperne di più su come impostare i giorni di conservazione dei log delle transazioni, consulta Impostare la conservazione dei log delle transazioni.

Anche se un'istanza archivia i log binari utilizzati per 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 propri log binari per il 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ò equivale a un giorno di log su disco.

Riducendo i valori di queste impostazioni dei flag, Cloud SQL ti aiuta a risparmiare sui costi di utilizzo del disco. Tuttavia, se vuoi che altri 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 dei giorni di conservazione dei log delle transazioni o per i valori impostati per i flag.

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

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

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

Per le istanze abilitate per le chiavi di crittografia gestite 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 versioni più recenti per il numero di giorni configurati per il parametro retained-transaction-log-days.

Utilizzo dei log e del disco

I nuovi log vengono generati regolarmente e occupano spazio di archiviazione. I log binari vengono eliminati automaticamente con il backup automatico associato, operazione una volta soddisfatto 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 PITR su disco, Cloud SQL elimina definitivamente i dati dal disco ogni giorno per soddisfare l'impostazione PITR 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:

Controlla se l'istanza sta archiviando i log su disco. Puoi spostare i log utilizzati per il PITR dal disco a Cloud Storage disattivando e riattivando PITR. Questa operazione comporta un tempo di inattività di alcuni minuti, ma libera spazio su disco. Se utilizzi la versione Cloud SQL Enterprise, puoi anche eseguire l'upgrade alla versione Cloud SQL Enterprise Plus per cambiare la posizione 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 abilitare l' aumento automatico dello spazio di archiviazione per evitare problemi imprevisti.
Se vuoi eliminare i log e recuperare lo spazio di archiviazione, puoi disattivare PITR senza abilitarlo di nuovo. Tuttavia, la riduzione dello spazio di archiviazione utilizzato non riduce la dimensione del disco di cui è stato 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 2 giorni, vengono conservati almeno due giorni di log e un massimo di tre giorni di log. Ti consigliamo di impostare il numero di backup su uno superiore ai giorni di conservazione dei log per garantire un minimo di giorni specificati di conservazione dei log.

Per ulteriori informazioni sul PITR, consulta PITR.

Abilita PITR

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

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

Console

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

Vai a Istanze Cloud SQL
Apri il menu Altre azioni per l'istanza su cui vuoi abilitare il PITR e fai clic su Modifica.
In Personalizza la tua istanza, espandi la sezione Protezione dei dati.
Seleziona la casella di controllo Abilita il recupero point-in-time.
Espandi Opzioni avanzate.
Inserisci il numero di giorni per la conservazione dei log, da 1 a 35 per la versione Cloud SQL Enterprise Plus o da 1 a 7 per la versione Cloud SQL Enterprise.
Fai clic su Salva.

gcloud

Visualizza la panoramica dell'istanza:

gcloud sql instances describe INSTANCE_NAME

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 l'ora a 24 ore nel fuso orario UTC±00.
Abilita PITR:
```
gcloud sql instances patch INSTANCE_NAME \
--enable-bin-log
```
Se abiliti il 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
```
Conferma la modifica:
```
gcloud sql instances describe INSTANCE_NAME
```
Nella sezione backupConfiguration, viene visualizzato binaryLogEnabled: true se la modifica è riuscita.

Terraform

Per abilitare il 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 sezioni seguenti.

prepara Cloud Shell

Avvia Cloud Shell.
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
```
Se imposti valori espliciti nel file di configurazione Terraform, le variabili di ambiente vengono sostituite.

Prepara la directory

Ogni file di configurazione Terraform deve avere una propria directory (detta anche modulo principale).

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 è indicato come main.tf.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
Se stai seguendo un tutorial, puoi copiare il codice campione in ogni sezione o passaggio.

Copia il codice campione nel file main.tf appena creato.

Se vuoi, copia il codice da GitHub. Questa opzione è consigliata se lo snippet Terraform fa parte di una soluzione end-to-end.
Esamina e modifica i parametri di esempio da applicare al tuo ambiente.
Salva le modifiche.
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

Rivedi la configurazione e verifica che le risorse che Terraform creerà o aggiornerà corrispondano alle tue aspettative:
```
terraform plan
```
Apporta le correzioni necessarie alla configurazione.
Applica la configurazione Terraform eseguendo il comando seguente e inserendo yes al prompt:
```
terraform apply
```
Attendi finché Terraform non visualizza il messaggio "Applicazione completata".
Apri il progetto Google Cloud per visualizzare i risultati. Nella console Google Cloud, vai alle risorse nell'interfaccia utente per assicurarti che Terraform le abbia create o aggiornate.

Elimina le modifiche

Per eliminare le modifiche:

Per disabilitare la protezione dall'eliminazione, nel file di configurazione Terraform imposta l'argomento deletion_protection su false.
```
deletion_protection =  "false"
```
Applica la configurazione Terraform aggiornata eseguendo il comando seguente e inserendo yes al prompt:
```
terraform apply
```

Rimuovi le risorse applicate in precedenza con la tua configurazione Terraform eseguendo il comando seguente 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 di replica principale o di lettura che stai configurando per l'alta disponibilità
START_TIME: l'ora (in ore e minuti)

Metodo HTTP e URL:

PATCH http://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:

curl (Linux, macOS o Cloud Shell)

Nota: il comando seguente presuppone che tu abbia eseguito l'accesso all'interfaccia a riga di comando gcloud con il tuo account utente eseguendo gcloud init o gcloud auth login oppure utilizzando Cloud Shell, che ti consente di accedere automaticamente all'interfaccia a riga di comando di gcloud. . Puoi controllare l'account attualmente attivo eseguendo gcloud auth list.

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "http://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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 di replica principale o di lettura che stai configurando per l'alta disponibilità
START_TIME: l'ora (in ore e minuti)

Metodo HTTP e URL:

PATCH http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "http://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Esegui PITR utilizzando un timestamp

L'uso di un timestamp è l'approccio consigliato per eseguire il PITR. Cloud SQL utilizza l'utilità mysqlbinlog per ripristinare le istanze fino a un momento specifico. Per ulteriori informazioni sull'utilità mysqlbinlog, consulta la documentazione di riferimento di MySQL.

Per completare la seguente attività, devi avere quanto segue:

Logging binario e backup abilitati per l'istanza, con log binari continui dall'ultimo backup prima dell'evento da cui vuoi eseguire il recupero. Per ulteriori informazioni, consulta Abilitare il logging binario.
Un timestamp per definire il punto di ripristino. Gli eventi che si verificano a partire da questo timestamp non si riflettono nella nuova istanza.

Console

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

Vai a Istanze Cloud SQL
Apri il menu Altre azioni per l'istanza da recuperare e fai clic su Crea clone.
Facoltativamente, nella pagina Crea un clone, aggiorna l'ID del nuovo clone.
Seleziona Clona da un momento precedente.
Inserisci un'ora PITR.
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: il nome del clone.
TIMESTAMP: fuso orario UTC per l'istanza di origine in 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 istanza di origine
restore-timestamp Il momento specifico per ripristinare fino a

Metodo HTTP e URL:

POST http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "http://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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 istanza di origine
restore-timestamp Il momento specifico per ripristinare fino a

Metodo HTTP e URL:

POST http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Disattiva PITR

Console

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

Vai a Istanze Cloud SQL
Apri il menu Altre azioni per l'istanza da disabilitare e seleziona Modifica.
In Personalizza la tua istanza, espandi la sezione Protezione dei dati.
Deseleziona Abilita recupero point-in-time.
Fai clic su Salva.
Nella pagina Panoramica dell'istanza, in Configurazione, l'impostazione PITR è elencata come disabilitata.

gcloud

Disabilita il recupero point-in-time:

gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log

Conferma la modifica:
```
gcloud sql instances describe INSTANCE_NAME
```
Nella sezione backupConfiguration, viene visualizzato 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 http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "http://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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 http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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 il PITR su disco o 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 su dove vengono archiviati i log delle transazioni per il 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 della versione Cloud SQL Enterprise alla versione Cloud SQL Enterprise Plus, il processo di upgrade trasferisce 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 la località di archiviazione dei log delle transazioni PITR a Cloud Storage.
SWITCHED_TO_CLOUD_STORAGE: l'istanza ha completato il cambio della località 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 per la conservazione dei log binari:

Console

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

Vai a Istanze Cloud SQL
Apri il menu Altre azioni per l'istanza su cui vuoi impostare il log delle transazioni e seleziona Modifica.
In Personalizza la tua istanza, espandi la sezione Protezione dei dati.
Nella sezione Abilita il recupero point-in-time, espandi Opzioni avanzate.
Inserisci il numero di giorni per la conservazione dei log, da 1 a 35 per la versione Cloud SQL Enterprise Plus o da 1 a 7 per Cloud SQL Enterprise.
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 se il PITR è abilitato. Conservare più giorni di log delle transazioni richiede maggiori dimensioni di archiviazione.

  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 per la conservazione dei log delle transazioni, da 1 a 7
project-id: l'ID progetto
instance-id: l'ID istanza

Metodo HTTP e URL:

PATCH http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "http://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

days-to-retain: il numero di giorni per la conservazione dei log delle transazioni, da 1 a 7
project-id: l'ID progetto
instance-id: l'ID istanza

Metodo HTTP e URL:

PATCH http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

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 anche eseguire il PITR fornendo una posizione specifica del log binario in un file di log binario.

Per ulteriori informazioni sul PITR che utilizza le posizioni dei log binari, consulta la pagina di riferimento di MySQL PITR sull'utilizzo del 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 ulteriori informazioni, consulta Abilitare il logging binario.
I log binari devono essere disponibili su disco per poterli sfogliare alla ricerca di eventi. Per verificare la durata di conservazione dei log binari su 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 eseguire il recupero (l'evento e tutti gli eventi successivi non vengono riflessi nella nuova istanza). Per ulteriori informazioni, 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 del log binario.

Identifica la posizione di recupero

Utilizza il client MySQL per connetterti all'istanza da ripristinare.

Per farlo, utilizza Cloud Shell o il tuo computer client locale. Per maggiori informazioni, consulta Opzioni di connessione per applicazioni esterne.
Mostra i file di log binari per l'istanza:
```
SHOW BINARY LOGS;
```
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 visualizzare, ma non mostrare tutti gli eventi nel file finché non ne conosci le dimensioni. La visualizzazione di un numero elevato di eventi può influire sulle prestazioni del sistema.
Se l'evento che stai cercando non è visualizzato, utilizza l'ultima posizione mostrata come punto di partenza per cercare nel gruppo di eventi successivo:
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
```
Quando trovi l'evento che segna il momento esatto da ripristinare, registra la posizione (indicata come Pos) e il nome del file di log binario.

Il nome file e la posizione del log binario sono i valori utilizzati per il PITR.

Di seguito sono riportati alcuni esempi 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 l'istruzione DROP TABLE, in grassetto sopra, devi usare "865" in "mysql-bin.000011" come posizione di ripristino. L'istruzione DROP TABLE e tutte le operazioni successive non vengono applicate alla nuova istanza.

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

Crea la nuova istanza utilizzando il nome file e la posizione di recupero 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, 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 \
```
Utilizza l'ID operazione restituito dal comando clone per controllare lo stato dell'operazione di ripristino.
```
gcloud sql operations describe OPERATION_ID
```
Quando l'operazione è in corso, viene restituito lo stato RUNNING. Al termine dell'operazione, viene restituito lo stato DONE.

REST v1

Crea la nuova istanza utilizzando il nome file e la posizione di recupero 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 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 http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "http://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

Crea la nuova istanza utilizzando il nome del file di 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 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 http://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:

curl (Linux, macOS o Cloud Shell)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Salva il corpo della richiesta in un file denominato request.json ed esegui questo comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "[email protected]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "http://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Risolvere i problemi

Problema 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` 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 che hai 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 fornito si riferisce a un momento in cui non è stato possibile trovare i backup o le coordinate binlog.

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

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.

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

Il timestamp fornito si riferisce a un momento in cui non è stato possibile trovare i backup o le coordinate binlog.

Passaggi successivi

Configura i flag sul tuo clone