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ù su PITR, consulta la sezione Recupero point-in-time (PITR).

Se crei un'istanza Cloud SQL Enterprise Plus, il PITR è abilitato per impostazione predefinita, indipendentemente dal metodo utilizzato per la creazione. Se vuoi disattivare la funzionalità, devi farlo manualmente.

Se crei un'istanza di Cloud SQL Enterprise nella console Google Cloud , il PITR è abilitato per impostazione predefinita. Altrimenti, se crei l'istanza utilizzando gcloud CLI, Terraform o l'API Cloud SQL Admin, il recupero point-in-time è disattivato per impostazione predefinita. In questo caso, se vuoi attivare la funzionalità, devi farlo manualmente.

Archiviazione dei log per PITR

Cloud SQL utilizza i log binari per il PITR.

L'11 agosto 2023 abbiamo lanciato l'archiviazione dei log delle transazioni per il PITR in Cloud Storage. A seguito di questo lancio, si applicano le seguenti condizioni:

  • Tutte le istanze di Cloud SQL Enterprise Plus memorizzano i log binari utilizzati per il PITR in Cloud Storage. Solo le istanze Cloud SQL Enterprise Plus di cui hai eseguito l'upgrade dalla versione Cloud SQL Enterprise prima del 1° aprile 2024 e per le quali è stato attivato il PITR prima dell'11 agosto 2023 continuano a memorizzare i log per il PITR su disco.

  • Le istanze Cloud SQL Enterprise create con il PITR abilitato prima dell'11 agosto 2023 continuano a memorizzare i log per il PITR su disco.

  • Se esegui l'upgrade di un'istanza Cloud SQL Enterprise edition dopo il 1° aprile 2024 che archivia i log delle transazioni per il PITR su disco alla versione Cloud SQL Enterprise Plus, la procedura di upgrade cambia la posizione di archiviazione dei log delle transazioni utilizzati per il PITR in Cloud Storage per te. Per saperne di più, consulta Eseguire l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade in loco.

  • Tutte le istanze Cloud SQL Enterprise edition create con il PITR abilitato dopo l'11 agosto 2023 archiviano i log utilizzati per il PITR in Cloud Storage.

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

Per le istanze che archiviano i log binari solo su disco, puoi cambiare la posizione di archiviazione dei log delle transazioni utilizzati per il PITR da disco a Cloud Storage utilizzando gcloud CLI o l'API Cloud SQL Admin senza incorrere in tempi di inattività. Per maggiori informazioni, consulta Passare all'archiviazione dei log delle transazioni in Cloud Storage.

Periodo di conservazione dei log

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 viene impostato un valore per questo parametro, il periodo di conservazione predefinito dei log delle transazioni è di 14 giorni per le istanze Cloud SQL Enterprise Plus e di 7 giorni per le istanze Cloud SQL Enterprise. Per saperne di più su come impostare i giorni di conservazione del log delle transazioni, consulta Impostare la conservazione del log delle transazioni.

Sebbene un'istanza memorizzi i log binari utilizzati per il ripristino temporizzato in Cloud Storage, l'istanza conserva anche un numero inferiore di log binari duplicati sul disco per consentire la replica dei log in Cloud Storage. Per impostazione predefinita, quando crei un'istanza con il PITR abilitato, l'istanza archivia i 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ò si traduce in un giorno di log sul disco.

Per i log binari PITR archiviati su disco, che vengono trasferiti a Cloud Storage o che sono già stati trasferiti a Cloud Storage, Cloud SQL conserva i log per il valore minimo impostato per una delle seguenti configurazioni:

  • L'impostazione di configurazione del backup transactionLogRetentionDays
  • expire_logs_days o il flag 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. Quando i log vengono archiviati su disco, la modifica dei valori di questi flag può influire sul comportamento del recupero PITR e sul numero di giorni di log archiviati su disco. Mentre la posizione di archiviazione dei log viene spostata in Cloud Storage, non puoi modificare i valori dei flag. Inoltre, non ti consigliamo di configurare il valore di nessuno dei due flag su 0. Per maggiori informazioni, vedi Configurare i flag di database.

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

Log e utilizzo del disco

I log vengono generati regolarmente e utilizzano spazio di archiviazione. I log binari vengono eliminati automaticamente con il backup automatico associato, il che avviene dopo che è stato raggiunto il valore impostato per transactionLogRetentionDays.

Per scoprire la quantità di spazio su disco utilizzata dai log binari, controlla la metrica bytes_used_by_data_type per l'istanza. Il valore per il tipo di dati binlog restituisce le dimensioni dei binlog sul disco. Per le istanze che archiviano i log delle transazioni utilizzati per il PITR su disco, Cloud SQL elimina i dati dal disco ogni giorno per soddisfare l'impostazione transactionLogRetentionDays PITR, come descritto in Conservazione dei backup automatici e dei log delle transazioni. Tuttavia, se imposti il flag expire_logs_days o binlog_expire_logs_seconds su un valore inferiore ai giorni di conservazione del log delle transazioni, Cloud SQL può eliminare i log binari prima.

Se le dimensioni dei log binari causano un problema per la tua istanza:

  • Controlla se l'istanza memorizza i log sul disco. Puoi cambiare la posizione di archiviazione dei log che Cloud SQL utilizza 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, puoi anche eseguire l'upgrade a Cloud SQL Enterprise Plus per cambiare la posizione di archiviazione dei log PITR.

  • Puoi aumentare le dimensioni 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 spazio di archiviazione imprevisti.

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

  • I log vengono eliminati una volta al giorno, non in modo continuo. 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 un valore superiore di un'unità rispetto ai giorni di conservazione dei log.

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

Per saperne di più sul PITR, consulta la sezione 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 Controllare la posizione di archiviazione dei log delle transazioni utilizzati per il ripristino temporizzato. Se vuoi che siano disponibili altri log 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 periodo minimo di conservazione dei log delle transazioni o per i valori impostati per i flag. Per saperne di più su come vengono archiviati i log per PITR dopo il passaggio e su come liberare spazio su disco, consulta Log dopo il passaggio a Cloud Storage.

Abilita PITR

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

La seguente procedura abilita il PITR su un'istanza primaria 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 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 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 visualizzi enabled: false nella sezione backupConfiguration, attiva i backup pianificati: 
    gcloud sql instances patch INSTANCE_NAME \
--backup-start-time=HH:MM

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

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

    Se abiliti il PITR su un'istanza primaria, puoi anche configurare il numero di giorni per i quali 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 è stata eseguita correttamente.

Terraform

Per attivare 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"
    }
  }
}

Applica le modifiche

Per applicare la configurazione di Terraform in un progetto Google Cloud , completa i passaggi nelle sezioni seguenti.

Prepara Cloud Shell

  1. Avvia Cloud Shell.

  2. Imposta il progetto Google Cloud predefinito in 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 di Terraform deve avere la propria directory (chiamata anche modulo radice).

  1. In Cloud Shell, crea una directory e un nuovo file al suo interno. Il nome file deve avere l'estensione .tf, ad esempio main.tf. In questo tutorial, il file viene 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 file main.tf appena creato.

    (Facoltativo) Copia il codice da GitHub. Questa operazione è consigliata quando lo snippet Terraform fa parte di una soluzione end-to-end.

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

    (Facoltativo) Per utilizzare l'ultima versione del provider Google, includi l'opzione -upgrade: 

    terraform init -upgrade

Applica le modifiche

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

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

    Attendi che Terraform visualizzi il messaggio "Apply complete!" (Applicazione completata).

  3. Apri il tuo Google Cloud progetto 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:

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

  1. Rimuovi le risorse applicate in precedenza con la configurazione Terraform eseguendo il seguente 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 primaria 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 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 o il numero di progetto del progetto Google Cloud che contiene l'istanza
  • INSTANCE_NAME: il nome dell'istanza primaria 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 di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Eseguire il PITR su un'istanza non disponibile

Console

Potresti voler recuperare un'istanza non disponibile in una zona diversa per i seguenti motivi:

  • La zona in cui è configurata l'istanza non è accessibile. Questa istanza ha uno stato FAILED.
  • È in corso la manutenzione dell'istanza. Questa istanza ha uno stato MAINTENANCE.

Per recuperare un'istanza non disponibile, completa i seguenti passaggi:

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

    Vai a Istanze Cloud SQL

  2. Trova la riga dell'istanza da clonare.
  3. Nella colonna Azioni, fai clic sul menu Altre azioni.
  4. Fai clic su Crea clone.
  5. Nella pagina Crea una clonazione, completa le seguenti azioni:
    1. Nel campo ID istanza, aggiorna l'ID istanza, se necessario.
    2. Fai clic su Clona da un momento specifico precedente.
    3. Nel campo Point in time, seleziona una data e un'ora a partire dalle quali vuoi clonare i dati. In questo modo viene recuperato lo stato dell'istanza in quel momento.
    4. Fai clic su Crea clone.

    6. Durante l'inizializzazione del clone, tornerai alla pagina dell'elenco delle istanze.

gcloud

Potresti voler recuperare un'istanza non disponibile in una zona diversa perché la zona in cui è configurata l'istanza non è accessibile.

gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \
--point-in-time DATE_AND_TIME_STAMP \
--preferred-zone ZONE_NAME \
--preferred-secondary-zone SECONDARY_ZONE_NAME

L'utente o il account di servizio che esegue il comando gcloud sql instances clone deve disporre dell'autorizzazione cloudsql.instances.clone. Per ulteriori informazioni sulle autorizzazioni richieste per eseguire i comandi gcloud CLI, consulta Autorizzazioni Cloud SQL.

REST v1

Potresti voler recuperare un'istanza non disponibile in una zona diversa perché la zona in cui è configurata l'istanza non è accessibile.

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

  • PROJECT_ID: l'ID progetto
  • SOURCE_INSTANCE_ID: l'ID dell'istanza di origine
  • TARGET_INSTANCE_ID: l'ID istanza di destinazione

Metodo HTTP e URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone

Corpo JSON della richiesta: 

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

L'utente o il account di servizio che utilizza il metodo API instances.clone deve disporre dell'autorizzazione cloudsql.instances.clone. Per saperne di più sulle autorizzazioni richieste per utilizzare i metodi API, consulta Autorizzazioni Cloud SQL.

REST v1beta4

Potresti voler recuperare un'istanza non disponibile in una zona diversa perché la zona in cui è configurata l'istanza non è accessibile.

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

  • PROJECT_ID: l'ID progetto
  • SOURCE_INSTANCE_ID: l'ID dell'istanza di origine
  • TARGET_INSTANCE_ID: l'ID istanza di destinazione

Metodo HTTP e URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone

Corpo JSON della richiesta: 

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

L'utente o il account di servizio che utilizza il metodo API instances.clone deve disporre dell'autorizzazione cloudsql.instances.clone. Per saperne di più sulle autorizzazioni richieste per utilizzare i metodi API, consulta Autorizzazioni Cloud SQL.

Se provi a creare un clone PITR in un momento successivo all'ultimo momento recuperabile, viene visualizzato il seguente messaggio di errore:

The timestamp for point-in-time recovery is after the latest recovery time of
Timestamp of latest recovery time. Clone the instance with a time
that's earlier than this recovery time.

Visualizzare l'ultimo tempo di recupero

Per un'istanza disponibile, puoi eseguire il PITR fino all'ultimo momento. Se l'istanza non è disponibile e i log dell'istanza sono archiviati in Cloud Storage, puoi recuperare l'ultimo orario di recupero ed eseguire il PITR fino a quell'ora. In entrambi i casi, puoi ripristinare l'istanza in una zona primaria o secondaria diversa fornendo i valori per le zone preferite.

gcloud

Recupera l'ultimo momento in cui puoi recuperare un'istanza Cloud SQL non disponibile.

Sostituisci INSTANCE_NAME con il nome dell'istanza su cui stai eseguendo la query.

gcloud sql instances get-latest-recovery-time INSTANCE_NAME

REST v1

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

  • PROJECT_ID: l'ID progetto
  • INSTANCE_NAME: il nome dell'istanza per cui stai eseguendo una query per l'ultimo tempo di ripristino

Metodo HTTP e URL: 

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

{
  "kind": "sql#getLatestRecoveryTime",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

REST v1beta4

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

  • PROJECT_ID: l'ID progetto
  • INSTANCE_NAME: il nome dell'istanza per cui stai eseguendo una query per l'ultimo tempo di ripristino

Metodo HTTP e URL: 

GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

{
  "kind": "sql#getLatestRecoveryTime",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

Eseguire il PITR in base a un timestamp

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

Per completare l'attività seguente, devi disporre di 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, vedi Attivare la registrazione binaria.
  • Un timestamp per definire il punto di ripristino. Gli eventi che si verificano in corrispondenza di questo timestamp e dopo non vengono riflessi 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. (Facoltativo) Nella pagina Crea un clone, aggiorna l'ID del nuovo clone.
  4. Seleziona Clona da un momento specifico precedente.
  5. Inserisci un orario PITR.
  6. Fai clic su Crea clone.

gcloud

Crea un clone utilizzando PITR.

Sostituisci quanto segue:

  • SOURCE_INSTANCE_NAME - Nome dell'istanza da cui esegui 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, apporta le seguenti sostituzioni:

  • project-id: l'ID progetto
  • target-instance-id: l'ID dell'istanza di destinazione
  • source-instance-id: l'ID dell'istanza di origine
  • restore-timestamp Il point-in-time da ripristinare 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 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
  • target-instance-id: l'ID dell'istanza di destinazione
  • source-instance-id: l'ID dell'istanza di origine
  • restore-timestamp Il point-in-time da ripristinare 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 di queste 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 che vuoi 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, vedrai binaryLogEnabled: false se la modifica è stata eseguita correttamente.

REST v1

Prima di utilizzare i dati della richiesta, apporta 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, apporta 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 il PITR

Puoi controllare dove l'istanza Cloud SQL archivia i log delle transazioni utilizzati per il PITR.

gcloud

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

   gcloud sql instances describe INSTANCE_NAME

Sostituisci INSTANCE_NAME con il nome dell'istanza.

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

   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, il campo transactionalLogStorageState o la colonna TRANSACTIONAL_LOG_STORAGE_STATE forniscono informazioni su dove vengono archiviati i log delle transazioni per il recupero point-in-time per l'istanza. I possibili stati di archiviazione del 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 cambia automaticamente la posizione di archiviazione dei log in Cloud Storage. Per saperne di più, consulta Eseguire 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 incorrere in tempi di inattività. Per maggiori informazioni, consulta Passare all'archiviazione dei log delle transazioni in Cloud Storage.
  • SWITCHING_TO_CLOUD_STORAGE: l'istanza sta cambiando la posizione di archiviazione dei log delle transazioni PITR in Cloud Storage.
  • SWITCHED_TO_CLOUD_STORAGE: l'istanza ha completato il passaggio della posizione di archiviazione dei log delle transazioni PITR dal disco a Cloud Storage.
  • CLOUD_STORAGE: l'istanza memorizza i log delle transazioni utilizzati per il PITR in Cloud Storage.

Passa all'archiviazione del log delle transazioni in Cloud Storage

Se la tua istanza archivia i log delle transazioni utilizzati per il PITR su disco, puoi cambiare la posizione di archiviazione in Cloud Storage senza incorrere in tempi di inattività. L'intero processo di cambio della posizione di archiviazione richiede circa la durata del periodo di conservazione del log delle transazioni (giorni) per essere completato. Non appena avvii il passaggio, i log delle transazioni iniziano ad accumularsi in Cloud Storage. Durante l'operazione, puoi controllare lo stato dell'intero processo utilizzando il comando in Controllare la posizione di archiviazione dei log delle transazioni utilizzati per il recupero temporizzato.

Una volta completato il processo complessivo di passaggio a Cloud Storage, Cloud SQL utilizza i log delle transazioni di Cloud Storage per il recupero point-in-time.

gcloud

Per passare a Cloud Storage come posizione di archiviazione, 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, consulta la sezione Risolvere i problemi relativi al passaggio a Cloud Storage per possibili 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 la sezione 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 la sezione Risolvere i problemi relativi al passaggio a Cloud Storage per possibili passaggi successivi.

Archiviazione e configurazione del log delle transazioni dopo il cambio

Ai fini della replica, Cloud SQL conserva comunque copie dei log binari su disco.

Se vuoi sfogliare i log binari con l'utilità mysqlbinlog, è utile memorizzarli su disco.

Se hai configurato i flag expire_logs_days o binlog_expire_logs_seconds nella tua istanza prima del cambio, i valori configurati rimangono invariati.

Dopo il passaggio, poiché i log binari utilizzati per eseguire il recupero temporizzato vengono ora archiviati in Cloud Storage, assicurati che i valori dei flag riflettano la conservazione dei log delle transazioni su disco che ti aspetti. Cloud SQL conserva i log su disco solo per il valore minimo di uno dei seguenti:

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

Se vuoi risparmiare spazio su disco, al termine della procedura di cambio, configura il valore dei flag expire_logs_days o binlog_expire_logs_seconds su 1 giorno per ridurre le dimensioni del disco allocate e i costi di archiviazione su disco. Per saperne di più sull'archiviazione dei log delle transazioni e sul PITR, consulta Archiviazione dei log per PITR.

Per saperne di più 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 di 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 recupero point-in-time, espandi Opzioni avanzate.
  5. 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.
  6. Fai clic su Salva.

gcloud

Modifica l'istanza per impostare il numero di giorni per 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 è tra 1 e 7 giorni, con un valore predefinito di 7 giorni.

    Se non specifichi un valore, Cloud SQL utilizza il valore predefinito. È valido solo quando il PITR è abilitato. Conservare i log delle transazioni per più giorni richiede uno spazio di archiviazione più grande.

  gcloud sql instances patch INSTANCE_NAME 

    --retained-transaction-log-days=DAYS_TO_RETAIN

REST v1

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 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 i log delle transazioni per più giorni richiede uno spazio 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 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 i log delle transazioni per più giorni richiede uno spazio 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:

Esegui il recupero point-in-time utilizzando le posizioni del log binario

Sebbene ti 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 o una posizione dell'evento in un file di log binario.

Per saperne di più sul PITR che utilizza le posizioni dei log binari, consulta PITR che utilizza il log binario.

Prima di iniziare

Prima di completare questa attività, devi:

  • 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, vedi Attivare la registrazione binaria.

  • I log binari devono essere disponibili su disco per poterli sfogliare alla ricerca di eventi. Per controllare la durata della 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.

  • Il nome di un file di log binario e la posizione dell'evento da cui vuoi eseguire il recupero (questo evento e tutti quelli successivi non vengono riflessi nella nuova istanza). Per ulteriori informazioni, consulta Identificare la posizione del log binario.

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

Identificare la posizione di recupero

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

    Per farlo, utilizza Cloud Shell o la tua macchina client locale. Per ulteriori informazioni, vedi Opzioni di connessione per applicazioni esterne.

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

    SHOW BINARY LOGS;

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

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

    Puoi modificare il numero di righe da mostrare, ma non visualizzare tutti gli eventi nel file finché non sai quanto è grande. 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 successivo insieme di eventi:

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

  5. Quando trovi l'evento che segna il punto nel tempo fino al quale vuoi eseguire il ripristino, registra la posizione (visualizzata come Pos) e il nome del file di log binario.

    Il nome del file di log binario e la posizione sono i valori che utilizzi per il recupero point-in-time.

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 fino all'istruzione DROP TABLE, in grassetto nell'esempio precedente, utilizzeresti 865 in mysql-bin.000011 come posizione di recupero. L'istruzione DROP TABLE e tutte le operazioni successive non vengono riflesse nella nuova istanza.

Esegui il PITR utilizzando le posizioni degli eventi del log binario

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 del file di log binario e la posizione di recupero.

    Sostituisci quanto segue:

    • SOURCE_INSTANCE_NAME: il nome dell'istanza da cui esegui il ripristino.
    • NEW_INSTANCE_NAME: il 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 avere un aspetto 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 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 del file di log binario e la posizione di recupero che hai identificato:

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

  • project-id: l'ID progetto
  • target-instance-id: l'ID dell'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 di log binario e la posizione di recupero che hai identificato:

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

  • project-id: l'ID progetto
  • target-instance-id: l'ID dell'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 binlog.

Risolvere i problemi relativi al passaggio a Cloud Storage

La seguente tabella elenca i possibili errori che potrebbero essere restituiti con il codice INVALID REQUEST quando sposti la posizione di archiviazione dei log delle transazioni dal disco a 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 per il recupero point-in-time (PITR). Per supportare il PITR, MySQL richiede che tu abiliti il logging binario sull'istanza. Per maggiori informazioni su come abilitare la registrazione binaria, vedi Abilitare il PITR.
This command is not supported on replica instances. Run the command on the primary instance instead. Assicurati di specificare un'istanza primaria 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 Controlla 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 di cambio.

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

Passaggi successivi