Cloud SQL ti consente di ripristinare le istanze da un backup o eseguendo il recupero point-in-time (PITR). In questo modo puoi recuperare un'istanza in un periodo o un momento specifico ripristinando il backup in un'istanza esistente o in una nuova istanza. Per eseguire il ripristino, puoi utilizzare il backup di un'istanza attiva o eliminata. L'operazione di ripristino utilizza le impostazioni, i database e gli utenti dell'istanza di origine e li imposta nell'istanza di destinazione che scegli.
Quando esegui il ripristino in una nuova istanza, l'istanza di destinazione può trovarsi in una regione o in un progetto diverso rispetto all'istanza di origine. L'istanza di destinazione può anche utilizzare un numero diverso di core o una quantità di memoria diversa rispetto all'istanza di origine.
Cloud SQL imposta sempre la capacità di archiviazione dell'istanza di destinazione sul valore massimo della dimensione sia del disco configurato sia del disco di backup. Il disco di backup è la dimensione del disco al momento dell'esecuzione del backup.
Quando esegui un ripristino su un'istanza, tieni presente quanto segue:
- L'operazione di ripristino sovrascrive tutti i dati nell'istanza di destinazione.
- I flag dell'istanza di origine non vengono ripristinati. Tutti i flag impostati in precedenza nell'istanza di destinazione vengono mantenuti dopo il ripristino.
- L'istanza di destinazione non è disponibile per le connessioni durante l'operazione di ripristino; le connessioni esistenti vengono perse.
- Se esegui il ripristino in un'istanza con repliche di lettura, devi eliminare tutte le repliche e ricrearle al termine dell'operazione di ripristino.
- L'operazione di ripristino riavvia l'istanza.
- Dopo aver eseguito il ripristino da un backup, le configurazioni di backup dell'istanza di destinazione vengono impostate sui valori predefiniti. Se l'istanza di origine aveva configurazioni di backup personalizzate o utilizzava backup avanzati, dovrai aggiornare le configurazioni di backup al termine del ripristino.
Eseguire il ripristino utilizzando un backup
Cloud SQL ti consente di ripristinare un'istanza utilizzando un backup. Puoi utilizzare un backup di un'istanza attiva o eliminata e utilizzarlo per eseguire il ripristino in un'istanza nuova o esistente. Puoi utilizzare qualsiasi backup disponibile per ripristinare l'istanza. Per saperne di più su come funzionano i backup in Cloud SQL, consulta la panoramica dei backup.
Quando ripristini un'istanza utilizzando un backup, puoi:
- Ripristinare in una nuova istanza
- Ripristinare in un'istanza esistente
- Ripristinare in un'istanza in un altro progetto o in un'altra regione
In caso di interruzione, puoi comunque recuperare un elenco di backup in un progetto specifico da cui eseguire il ripristino.
Per ripristinare l'istanza utilizzando un backup, consulta Ripristinare un'istanza utilizzando un backup.
Ripristinare un'istanza abilitata per CMEK utilizzando backup avanzati
Quando utilizzi istanze abilitate per CMEK con backup avanzati, i backup sono protetti dalla stessa CMEK dell'istanza. Questa può essere una parte importante del piano di backup per le istanze che richiedono la crittografia CMEK, perché mantiene i backup criptati con CMEK in un progetto separato in cui possono essere ripristinati correttamente anche se il progetto del workload originale è compromesso o eliminato.
Quando ripristini un backup avanzato di un'istanza abilitata per CMEK in una nuova istanza, puoi scegliere una delle seguenti opzioni di crittografia per la nuova istanza:
- Utilizza la stessa chiave Cloud KMS dell'istanza originale. Questo è il comportamento predefinito.
- Seleziona una chiave Cloud KMS diversa per l'istanza di destinazione. Per selezionare una chiave diversa, imposta il flag
--disk-encryption-keynel comando di ripristino. - Ripristina a Google Cloud-powered encryption keys per l'istanza di destinazione.
Per utilizzare GMEK, imposta il flag
--clear-disk-encryptionnel comando di ripristino.
Recupero point-in-time (PITR)
Il PITR ti consente di ripristinare l'istanza in un momento specifico del database. Ad esempio, se un errore causa una perdita di dati, puoi recuperare un database allo stato in cui si trovava prima che si verificasse l'errore. A differenza del ripristino utilizzando un backup, il PITR crea sempre una nuova istanza. Non puoi eseguire un PITR in un'istanza esistente. La nuova istanza eredita le impostazioni dell'istanza di origine, in modo simile a quando crei un clone.
Se crei un'istanza della versione Cloud SQL Enterprise Plus, il PITR è abilitato per impostazione predefinita. Devi disattivare manualmente la funzionalità se non vuoi che sia abilitata.
Se crei un'istanza della versione Cloud SQL Enterprise nella Cloud de Confiance console, il PITR è abilitato per impostazione predefinita. In caso contrario, se crei l'istanza utilizzando il gcloud CLI, Terraform o l'API Cloud SQL Admin, il PITR è disabilitato per impostazione predefinita. Per abilitare il PITR per queste istanze, devi farlo manualmente.
Per istruzioni passo passo su come eseguire il PITR, consulta Utilizzare il recupero point-in-time (PITR).
Archiviazione dei log per il PITR
Il PITR utilizza la registrazione write-ahead (WAL) per archiviare i log. Quando ripristini un'istanza esistente utilizzando un backup, questi log di archivio vengono eliminati e non saranno disponibili per eseguire un PITR. Per il PITR possono essere utilizzati solo i nuovi log generati al termine del ripristino.
Il 9 gennaio 2023 abbiamo lanciato l'archiviazione dei log delle transazioni per il 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 utilizzati per il 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 che avevano il PITR abilitato prima del 9 gennaio 2023 continuano ad archiviare i log per il PITR su disco.
Le istanze della versione Cloud SQL Enterprise create con il PITR abilitato prima del 9 gennaio 2023 continuano ad archiviare i log per il PITR su disco.
Se esegui l'upgrade di un'istanza della versione Cloud SQL Enterprise dopo il 9 gennaio 2023 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 della versione Cloud SQL Enterprise che crei con il PITR abilitato dopo il 9 gennaio 2023 archiviano i log utilizzati per il PITR in Cloud Storage.
Se l'istanza utilizza Cloud Storage per archiviare i log write-ahead, questi vengono archiviati nella stessa regione dell'istanza primaria. Questi log vengono archiviati per un massimo di 35 giorni per la versione Cloud SQL Enterprise Plus e 7 giorni per la versione Cloud SQL Enterprise e non generano costi aggiuntivi per istanza.
Per saperne di più su come controllare la posizione di archiviazione dei log delle transazioni utilizzati per il PITR, consulta Controllare dove vengono archiviati i log delle transazioni per l'istanza.
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. Per saperne di più, consulta Passare all'archiviazione dei log delle transazioni in Cloud Storage.
Per assicurarti che i log della tua istanza vengano archiviati in Cloud Storage anziché su disco, completa le seguenti azioni:
- Controlla l'architettura di rete dell'istanza. Se l'istanza si trova nella vecchia architettura di rete, allora esegui l'upgrade alla nuova architettura di rete.
Se la dimensione dei log su disco causa problemi di prestazioni per l'istanza, disattiva il PITR e riattivalo. Questa azione garantisce che i nuovi log vengano archiviati in Cloud Storage anziché su disco.
Periodo di conservazione dei log
Cloud SQL conserva i log delle transazioni in Cloud Storage per un massimo di giorni pari al
valore impostato nell'
transactionLogRetentionDays
impostazione di configurazione PITR. 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 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.
Sebbene un'istanza archivi i log write-ahead utilizzati per il PITR in Cloud Storage, l'istanza conserva anche un numero inferiore di log write-ahead duplicati su 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 write-ahead 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 su disco.
Per i log write-ahead PITR archiviati su disco, che vengono spostati in Cloud Storage o che sono già stati spostati in Cloud Storage, Cloud SQL conserva i log per il valore minimo impostato per una delle seguenti configurazioni:
- L'impostazione di configurazione del backup
transactionLogRetentionDays - Il
expire_logs_dayso ilbinlog_expire_logs_secondsflag
Cloud SQL non imposta alcun valore per questi flag se i log write-ahead vengono archiviati su disco, vengono spostati in Cloud Storage o sono già stati spostati in Cloud Storage. 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. Durante lo spostamento della posizione di archiviazione dei log in Cloud Storage, non puoi modificare i valori dei flag.
Inoltre, non ti consigliamo di configurare il valore di uno dei due flag su 0. Per saperne di più, consulta
Configurare i flag del database.
- Impostazione di configurazione
transactionLogRetentionDays - Flag del database
expire_logs_days - Flag del database
binlog_expire_logs_seconds
Ad esempio, per evitare problemi di prestazioni, riduci il valore dei flag di un giorno, ogni giorno, per diversi giorni. Di conseguenza, Cloud SQL non elimina tutti i log write-ahead contemporaneamente.
Per
le istanze abilitate per la chiave di crittografia gestita dal cliente (CMEK),
i log write-ahead vengono criptati utilizzando la versione più recente della
CMEK. Per eseguire un ripristino, è necessaria la versione più recente della chiave per tutti i giorni conservati come parte del parametro retained-transaction-log-days.
Limitazioni del PITR
Le seguenti limitazioni sono associate all'istanza con il PITR abilitato e alla dimensione dei log delle transazioni su disco che causa un problema per l'istanza:
- Puoi disattivare il PITR e riattivarlo per assicurarti che Cloud SQL archivi i log in Cloud Storage nella stessa regione dell'istanza. Tuttavia, Cloud SQL elimina tutti i log esistenti, quindi non puoi eseguire un'operazione PITR prima del momento in cui hai riattivato il PITR.
- Puoi aumentare le dimensioni dello spazio di archiviazione dell'istanza, ma l'aumento delle dimensioni dei log delle transazioni nell'utilizzo del disco potrebbe essere temporaneo.
- Per evitare problemi di archiviazione imprevisti, ti consigliamo di abilitare gli aumenti automatici dello spazio di archiviazione. Questo consiglio si applica solo se l'istanza ha il PITR abilitato e i log vengono archiviati su disco.
Per istruzioni passo passo su come eseguire il PITR, consulta [Utilizzare il recupero point-in-time (PITR)][perform-pitr].
Ripristinare un'istanza non disponibile
Puoi utilizzare il PITR per ripristinare un'istanza Cloud SQL non disponibile. In genere, il PITR offre un Recovery Point Objective (RPO) di cinque minuti o meno.
Se l'istanza non è disponibile, puoi utilizzare l'API per ottenere l' ora di recupero più recente e più recente in cui puoi ripristinare l'istanza ed eseguire il recupero fino a quell'ora. Se la zona in cui è configurata l'istanza non è accessibile, puoi ripristinare l'istanza in una zona primaria o secondaria diversa fornendo i valori per le zone preferite.
Supponiamo che un'istanza Cloud SQL diventi non disponibile alle 16:00 EST. Se l'ora di recupero più recente è alle 15:55 EST, puoi recuperare l'istanza fino a quell'ora.
Ripristinare un'istanza eliminata utilizzando il PITR
Puoi utilizzare il PITR per ripristinare un'istanza Cloud SQL dopo l'eliminazione. Per utilizzare questa funzionalità, l'istanza deve avere il PITR e i backup conservati abilitati prima dell'eliminazione. Quando è abilitato, i log PITR vengono conservati dopo l'eliminazione dell'istanza.
Dopo l'eliminazione di un'istanza, i log PITR continuano a seguire le impostazioni di conservazione definite dall'istanza quando era attiva. I log PITR scadono in base alle impostazioni di conservazione su base continuativa dopo l'eliminazione dell'istanza. Il periodo continuativo viene definito in base al periodo di conservazione PITR impostato sull'istanza prima dell'eliminazione. Ad esempio, se l'istanza della versione Cloud SQL Enterprise Plus ha la conservazione PITR impostata su 14 giorni, l'ultimo log PITR verrà eliminato 14 giorni dopo l'eliminazione dell'istanza. Quando un log PITR scade, non può essere recuperato.
Poiché i nomi delle istanze possono essere riutilizzati dopo l'eliminazione di un'istanza in Cloud SQL, i log PITR conservati possono essere identificati nei seguenti campi: Cloud de Confiance by S3NS
instance_deletion_timelog_retention_days
Questi campi ti consentono di identificare se un log PITR appartiene a un'istanza eliminata.
La finestra di recupero PITR è definita come le ore di recupero più recenti e più recenti disponibili per ripristinare l'istanza utilizzando il PITR. Per trovare le ore di recupero più recenti e più recenti dell'istanza eliminata, consulta Ottieni l'ora di recupero più recente e più recente.
Per ripristinare un'istanza utilizzando il PITR dopo l'eliminazione dell'istanza, consulta Eseguire il PITR su un'istanza eliminata.
Requisiti per il ripristino in una nuova istanza
Quando ripristini l'istanza in una nuova istanza, tieni presente i seguenti requisiti:
- L'istanza di destinazione deve avere la stessa versione del database dell'istanza da cui è stato eseguito il backup.
Quando crei una nuova istanza, la funzionalità
storageAutoResizeè abilitata per impostazione predefinita. Qualsiasi backup creato successivamente eredita la stessa impostazionestorageAutoResize. Ciò significa che, indipendentemente dal fatto che tu stia ripristinando un backup in un'istanza nuova o esistente, la capacità di archiviazione dell'istanza verrà ridimensionata automaticamente in base alle esigenze. Le istanze legacy non hanno questa funzionalità abilitata. Per controllare le impostazioni dell'istanza, consulta Visualizzare le impostazioni dell'istanza.L'istanza di destinazione deve essere nello stato
RUNNABLE.
Limitazioni della frequenza di ripristino
Sono consentite un massimo di tre operazioni di ripristino ogni 30 minuti per istanza, per regione e per progetto. Se un'operazione di ripristino non riesce, non viene conteggiata ai fini di questa quota. Se raggiungi il limite, l'operazione non riesce e viene visualizzato un messaggio di errore che indica quando puoi eseguire di nuovo l'operazione.
Cloud SQL utilizza i token di un bucket per determinare il numero di operazioni di ripristino disponibili in un determinato momento. Per ogni backup, è presente un bucket per ogni progetto di destinazione e regione di destinazione. Le istanze di destinazione dello stesso progetto condividono un bucket se si trovano nella stessa regione. In ogni bucket sono disponibili un massimo di tre token che puoi utilizzare per le operazioni di ripristino. Ogni 10 minuti viene aggiunto un nuovo token al bucket. Se il bucket è pieno, il token va in overflow.
Ogni volta che esegui un'operazione di ripristino, viene concesso un token dal bucket. Se l'operazione ha esito positivo, il token viene rimosso dal bucket. Se non riesce, il token viene restituito al bucket. Il seguente diagramma mostra come funziona:
Ad esempio, nella figura seguente, Backup1, Backup2 e Backup3 sono i backup della stessa istanza di origine.
- Ogni backup (Backup1, Backup2 e Backup3) ha il proprio bucket di token per le operazioni di ripristino destinate a istanze diverse nel progetto 1 nella regione A (Bucket11A, Bucket21A e Bucket31A). Poiché ogni backup ha il proprio bucket, puoi ripristinare ogni backup nella stessa istanza tre volte ogni 30 minuti.
- Ogni backup ha un bucket per un progetto separato e per una regione separata.
Ad esempio, se in una regione sono presenti cinque progetti, sono presenti cinque bucket per quel backup in quella regione, uno in ogni progetto. Nella figura precedente, abbiamo due progetti nella regione A: Progetto 1 e Progetto n.
- Backup1 ha due bucket di token per le operazioni di ripristino nella regione A. Un bucket per il progetto 1 (Bucket11A) e un bucket per il progetto n (Bucket1nA).
- Analogamente, Backup3 ha due bucket per le operazioni di ripristino nella regione A. Uno per il progetto 1 (Bucket31A) e uno per il progetto n (Bucket3nA).
- Backup3 ha un bucket nella regione B, per il progetto 1, perché tutte le istanze nello stesso progetto di destinazione e nella stessa regione di destinazione condividono un bucket.