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 Trusted 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 l'archiviazione write-ahead logging (WAL) per il PITR.Il 9 gennaio 2023 abbiamo iniziato a memorizzare i log write-ahead per PITR in Cloud Storage. Dal lancio, si applicano le seguenti condizioni:
- Tutte le istanze della versione Cloud SQL Enterprise Plus archiviano i log write-ahead in Cloud Storage. Solo le istanze della versione Cloud SQL Enterprise Plus di cui esegui l'upgrade dalla versione Cloud SQL Enterprise e per cui era abilitato il PITR prima del 9 gennaio 2023 continuano a memorizzare i log su disco.
- Le istanze Cloud SQL Enterprise create con il PITR abilitato prima del 9 gennaio 2023 continuano a memorizzare i log su disco.
- Se esegui l'upgrade di un'istanza Cloud SQL Enterprise edition dopo il 15 agosto 2024 che archivia i log delle transazioni per il PITR su disco a Cloud SQL Enterprise Plus, la procedura di upgrade sposta 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 create con il PITR abilitato dopo il 9 gennaio 2023 archiviano i log in Cloud Storage.
Per le istanze che archiviano i log write-ahead 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
Per verificare se un'istanza archivia i log utilizzati per il PITR in Cloud Storage, utilizza Controlla la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.
Dopo aver utilizzato un client PostgreSQL come psql
o pgAdmin
per
connetterti a un database dell'istanza, esegui il comando seguente:
show archive_command
. Se i log write-ahead sono
archiviati in Cloud Storage, viene visualizzato -async_archive -remote_storage
.
Tutte le altre istanze esistenti per cui è abilitato il PITR continuano ad avere i log memorizzati su disco.
Se i log sono archiviati in Cloud Storage, Cloud SQL li carica ogni cinque minuti o meno. Di conseguenza, se un'istanza Cloud SQL è disponibile, può essere recuperata all'ultimo momento. Tuttavia, se l'istanza non è disponibile, l'obiettivo del punto di ripristino è in genere di cinque minuti o meno. Utilizza gcloud CLI o l'API Admin per verificare l'ora più recente a cui puoi ripristinare l'istanza ed eseguire il ripristino a quell'ora.
I log write-ahead utilizzati con il recupero temporizzato vengono eliminati
automaticamente con il backup automatico
associato, il che in genere avviene dopo che è stato raggiunto il valore impostato per
transactionLogRetentionDays
. Questo è il numero di giorni di log delle transazioni che Cloud SQL
conserva per il recupero point-in-time. Per la versione Cloud SQL Enterprise Plus, puoi impostare il valore da 1 a 35, mentre per la versione Cloud SQL Enterprise, puoi impostare il valore da 1 a 7.
Quando ripristini un backup su un'istanza Cloud SQL prima di abilitare il PITR, perdi i log write-ahead che consentono l'operatività del PITR.
Per le
istanze abilitate alla chiave di crittografia gestita dal cliente (CMEK),
i log write-ahead vengono criptati utilizzando l'ultima versione della
CMEK. Per eseguire un ripristino, devono essere disponibili tutte le versioni della chiave che erano le più recenti per il numero di giorni configurato per il parametro
retained-transaction-log-days
.
Per le istanze con log write-ahead archiviati in Cloud Storage, i log vengono archiviati nella stessa regione dell'istanza primaria. Questo spazio di archiviazione dei log (fino a 35 giorni per la versione Cloud SQL Enterprise Plus e 7 giorni per la versione Cloud SQL Enterprise, la durata massima per il PITR) non genera costi aggiuntivi per istanza.
Log e utilizzo del disco
Se il PITR è abilitato per la tua istanza e se le dimensioni dei log write-ahead su disco causano un problema per la tua istanza:
Puoi cambiare la posizione di archiviazione dei log utilizzati per il ripristino temporizzato dal disco a Cloud Storage senza tempi di inattività utilizzando gcloud CLI o l'API Cloud SQL Admin.
Puoi eseguire l'upgrade dell'istanza alla versione Cloud SQL Enterprise Plus.
Puoi aumentare le dimensioni dello spazio di archiviazione dell'istanza, ma l'aumento delle dimensioni del log write-ahead 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. Questo consiglio si applica solo se PITR è abilitato per la tua istanza e i log sono archiviati su disco.
Puoi disattivare PITR se vuoi eliminare i log e recuperare spazio di archiviazione. La riduzione dei log write-ahead utilizzati 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 parametrotransactionLogRetentionDays
, per il parametrobackupRetentionSettings
imposta il numero diretainedBackups
su8
.
Abilita PITR
Quando crei una nuova istanza nella console Trusted 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
-
Nella console Trusted Cloud , vai alla pagina Istanze Cloud SQL.
- Apri il menu Altre azioni
per l'istanza su cui vuoi attivare il PITR e fai clic su Modifica.
- In Personalizza la tua istanza, espandi la sezione Protezione dei dati.
- Seleziona la casella di controllo Abilita recupero point-in-time.
- 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.
- Fai clic su Salva.
gcloud
- Visualizza la panoramica dell'istanza:
gcloud sql instances describe INSTANCE_NAME
- Se visualizzi
enabled: false
nella sezionebackupConfiguration
, 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. - Abilita PITR:
gcloud sql instances patch INSTANCE_NAME \ --enable-point-in-time-recovery
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
- Conferma la modifica:
gcloud sql instances describe INSTANCE_NAME
Nella sezione
backupConfiguration
, vedraipointInTimeRecoveryEnabled: true
se la modifica è stata eseguita correttamente.
Terraform
Per attivare il PITR, utilizza una risorsa Terraform.
Applica le modifiche
Per applicare la configurazione di Terraform in un progetto Trusted Cloud , completa i passaggi nelle sezioni seguenti.
Prepara Cloud Shell
- Avvia Cloud Shell.
-
Imposta il progetto Trusted 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).
-
In Cloud Shell, crea una directory e un nuovo file al suo interno. Il nome file deve avere l'estensione
.tf
, ad esempiomain.tf
. In questo tutorial, il file viene denominatomain.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.(Facoltativo) Copia il codice da GitHub. Questa operazione è consigliata quando lo snippet Terraform fa parte di una soluzione end-to-end.
- Rivedi e modifica i parametri di esempio da applicare al tuo ambiente.
- Salva le modifiche.
-
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
-
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 di Terraform eseguendo il comando seguente e inserendo
yes
al prompt:terraform apply
Attendi che Terraform visualizzi il messaggio "Apply complete!" (Applicazione completata).
- Apri il tuo Trusted Cloud progetto per visualizzare i risultati. Nella console Trusted Cloud , vai alle risorse nell'interfaccia utente per assicurarti che Terraform le abbia create o aggiornate.
Elimina le modifiche
Per eliminare le modifiche:
- Per disattivare la protezione dall'eliminazione, imposta l'argomento
deletion_protection
sufalse
nel file di configurazione Terraform.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 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 Trusted 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, "pointInTimeRecoveryEnabled": 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 Trusted 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/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
Corpo JSON della richiesta:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "pointInTimeRecoveryEnabled": 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:
-
Nella console Trusted Cloud , vai alla pagina Istanze Cloud SQL.
- Trova la riga dell'istanza da clonare.
- Nella colonna Azioni, fai clic sul menu Altre azioni.
- Fai clic su Crea clone.
- Nella pagina Crea una clonazione, completa le seguenti azioni:
- Nel campo ID istanza, aggiorna l'ID istanza, se necessario.
- Fai clic su Clona da un momento specifico precedente.
- 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.
- Fai clic su Crea clone.
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_NAME: il nome dell'istanza di origine.
- TARGET_INSTANCE_NAME: il nome dell'istanza di destinazione (clonata).
- DATE_AND_TIME_STAMP: un timestamp di data e ora per l'istanza di origine nel fuso orario UTC e nel formato RFC 3339 (ad esempio,
2012-11-15T16:19:00.094Z
). - ZONE_NAME: (Facoltativo). Il nome della zona principale per l'istanza di destinazione. Viene utilizzato per specificare una zona primaria diversa per l'istanza Cloud SQL che vuoi clonare. Per un'istanza regionale, questa zona sostituisce la zona principale, ma la zona secondaria rimane la stessa dell'istanza.
- SECONDARY_ZONE_NAME: (Facoltativo). Il nome della zona secondaria per l'istanza di destinazione. Viene utilizzato per specificare una zona secondaria diversa per l'istanza Cloud SQL regionale che vuoi clonare.
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_NAME", "pointInTime": "DATE_AND_TIME_STAMP", "preferredZone": "ZONE_NAME", "preferredSecondaryZone": "SECONDARY_ZONE_NAME" } }
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_NAME: il nome dell'istanza di origine.
- TARGET_INSTANCE_NAME: il nome dell'istanza di destinazione (clonata).
- DATE_AND_TIME_STAMP: un timestamp di data e ora per l'istanza di origine nel
fuso orario UTC
e nel formato RFC 3339
(ad esempio,
2012-11-15T16:19:00.094Z
). - ZONE_NAME: (Facoltativo). Il nome della zona principale per l'istanza di destinazione. Viene utilizzato per specificare una zona primaria diversa per l'istanza Cloud SQL che vuoi clonare. Per un'istanza regionale, questa zona sostituisce la zona primaria, ma la zona secondaria rimane la stessa dell'istanza.
- SECONDARY_ZONE_NAME: (Facoltativo). Il nome della zona secondaria per l'istanza di destinazione. Viene utilizzato per specificare una zona secondaria diversa per l'istanza Cloud SQL regionale che vuoi clonare.
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_NAME", "pointInTime": "DATE_AND_TIME_STAMP", "preferredZone": "ZONE_NAME", "preferredSecondaryZone": "SECONDARY_ZONE_NAME" } }
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" }
Esegui PITR
Console
-
Nella console Trusted Cloud , vai alla pagina Istanze Cloud SQL.
- Apri il menu Altre azioni
per l'istanza che vuoi recuperare e fai clic su Crea clone.
- (Facoltativo) Nella pagina Crea un clone, aggiorna l'ID del nuovo clone.
- Seleziona Clona da un momento specifico precedente.
- Inserisci un orario PITR.
- 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
-
Nella console Trusted Cloud , vai alla pagina Istanze Cloud SQL.
- Apri il menu Altre azioni
per l'istanza che vuoi disattivare e seleziona Modifica.
- In Personalizza la tua istanza, espandi la sezione Protezione dei dati.
- Deseleziona Abilita recupero point-in-time.
- Fai clic su Salva.
gcloud
- Disattiva il recupero point-in-time:
gcloud sql instances patch INSTANCE_NAME \ --no-enable-point-in-time-recovery
- Conferma la modifica:
gcloud sql instances describe INSTANCE_NAME
Nella sezione
backupConfiguration
, vedraipointInTimeRecoveryEnabled: 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, "pointInTimeRecoveryEnabled": 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, "pointInTimeRecoveryEnabled": 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 POSTGRES_12 us-central-1 DISK my_02 POSTGRES_12 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.
Imposta la conservazione dei log delle transazioni
Per impostare il numero di giorni di conservazione dei log write-ahead:
Console
-
Nella console Trusted Cloud , vai alla pagina 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 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
Modifica l'istanza per impostare il numero di giorni per conservare i log write-ahead.
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:
Risoluzione dei problemi
Problema | Risoluzione dei problemi |
---|---|
OPPURE
|
Il timestamp che hai fornito non è valido. |
OPPURE
|
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. |
PostgreSQL transactional logging is not enabled on this instance.
|
PostgreSQL utilizza il logging write-ahead come log delle transazioni per il recupero point-in-time (PITR). Per supportare il PITR, PostgreSQL richiede che tu abiliti il logging write-ahead sull'istanza. Per maggiori informazioni su come attivare il logging write-ahead, vedi Attivare PITR. |
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
- Configura i flag sul clone.