Panoramica del ripristino di un'istanza

MySQL   |  PostgreSQL   |  SQL Server

Cloud SQL 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 prende 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 un progetto diversi dall'istanza di origine. L'istanza di destinazione può anche utilizzare un numero diverso di core o quantità di memoria rispetto all'istanza di origine.

Cloud SQL imposta sempre la capacità di archiviazione dell'istanza di destinazione sul valore massimo delle dimensioni sia del disco configurato sia del disco di backup. Il disco di backup ha le dimensioni del disco al momento della creazione 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 sull'istanza di destinazione vengono conservati 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 dopo il completamento dell'operazione di ripristino.
• L'operazione di ripristino riavvia l'istanza.
• Dopo 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.

Ripristinare utilizzando un backup

Cloud SQL consente di ripristinare un'istanza utilizzando un backup. Puoi utilizzare un backup di un'istanza attiva o eliminata e utilizzarlo per 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:

• Ripristina in una nuova istanza
• Ripristina in un'istanza esistente
• Ripristinare un'istanza in un altro progetto o regione

In caso di interruzione, puoi comunque recuperare un elenco dei backup in un progetto specifico da cui eseguire il ripristino.

Per ripristinare l'istanza utilizzando un backup, vedi Ripristinare un'istanza utilizzando un backup.

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 ripristinare un database nello stato in cui si trovava prima che si verificasse l'errore. A differenza del ripristino utilizzando un backup, il recupero temporizzato crea sempre una nuova istanza. Non puoi eseguire un PITR su 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 di Cloud SQL Enterprise Plus, il PITR è abilitato per impostazione predefinita. Devi disattivare la funzionalità manualmente.

Se crei un'istanza di Cloud SQL Enterprise nella console Google Cloud , il PITR è abilitato per impostazione predefinita. Se crei un'istanza Cloud SQL per MySQL con l'alta disponibilità abilitata, anche il PITR è abilitato per impostazione predefinita. In caso contrario, se crei l'istanza utilizzando gcloud CLI, Terraform o l'API Cloud SQL Admin, il PITR è disattivato per impostazione predefinita. Per abilitare il PITR per queste istanze, devi abilitarlo manualmente.

Per istruzioni passo passo su come eseguire il PITR, consulta Utilizzare il recupero point-in-time (PITR).

Archiviazione dei log per PITR

Il PITR utilizza il logging binario 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. Solo i nuovi log generati dopo il completamento del ripristino possono essere utilizzati per PITR.

L'11 agosto 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 binari 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 per le quali è stato attivato il PITR prima dell'11 agosto 2023 continuano ad archiviare 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.

  Nota: per le istanze create prima dell'11 agosto 2023, Cloud SQL cambia automaticamente la posizione dei log delle transazioni utilizzati per il PITR. Puoi utilizzare gcloud CLI o l'API Cloud SQL Admin per controllare dove vengono archiviati i log delle transazioni per la tua istanza.

• Se esegui l'upgrade di un'istanza Cloud SQL Enterprise Edition dopo l'11 agosto 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 saperne di più, vedi Eseguire l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade in loco.

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

Se l'istanza utilizza Cloud Storage per archiviare i log binari, i log 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 ripristino temporizzato, vedi Controllare dove sono archiviati i log delle transazioni per la tua istanza.

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. Per saperne di più, consulta Passare all'archiviazione dei log delle transazioni in Cloud Storage.

Attenzione :lo spostamento dei log delle transazioni dal disco a Cloud Storage comporta diversi minuti di inattività e la perdita dei log precedenti per il recupero temporizzato. Il tempo di inattività è dovuto al riavvio delle istanze e alla cancellazione dei log quando disattivi PITR.

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, esegui l'upgrade alla nuova architettura di rete.

• Se le dimensioni dei log sul disco causano problemi di prestazioni per l'istanza, disattiva PITR e riattivala. Questa azione garantisce che i nuovi log vengano archiviati in Cloud Storage anziché su disco.

  Attenzione: se disattivi e riattivi il recupero temporaneo, tutti i log esistenti vengono eliminati e non potrai eseguire il recupero temporaneo prima del momento in cui lo hai riattivato. L'attivazione e la disattivazione del PITR richiedono il riavvio del database.

Periodo di conservazione dei log

Cloud SQL conserva i log delle transazioni in Cloud Storage fino al valore impostato nell'impostazione di configurazione transactionLogRetentionDays 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 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 dei log delle transazioni, consulta Impostare la conservazione dei log delle transazioni.

Sebbene un'istanza memorizzi i log binari utilizzati per il ripristino point-in-time in Cloud Storage, l'istanza conserva anche un numero inferiore di log binari duplicati su disco per consentire la replica dei log in Cloud Storage. Per impostazione predefinita, quando crei un'istanza con 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
• Il flag 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 il passaggio a Cloud Storage è in corso 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 saperne di più, consulta Configura i flag di database.

Nota: se la tua istanza ha un numero elevato di log binari sul disco e vuoi risparmiare spazio su disco, ti consigliamo di ridurre lentamente il valore di quanto segue:

• Impostazione di configurazione di transactionLogRetentionDays
• expire_logs_days flag di database
• binlog_expire_logs_seconds flag di database

Ad esempio, per evitare problemi di rendimento, riduci il valore dei flag di un giorno ogni giorno per diversi giorni. Di conseguenza, Cloud SQL non elimina tutti i log binari contemporaneamente.

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, è necessaria l'ultima versione della chiave per tutti i giorni conservati nell'ambito del 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 viene 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 PITR transactionLogRetentionDays, 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 utilizzati da Cloud SQL 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.

Per saperne di più sul PITR, consulta Recupero point-in-time (PITR).

Dopo aver completato il passaggio della posizione di archiviazione dei log delle transazioni a Cloud Storage, puoi liberare spazio su disco riducendo i valori dei flag expire_logs_days o binlog_expire_logs_seconds. Per controllare lo stato del passaggio, consulta Controllare la posizione di archiviazione dei log delle transazioni utilizzati per il PITR. Se vuoi che siano disponibili log aggiuntivi su disco, ad esempio per sfogliare i log binari con l'utilità mysqlbinlog, aumenta i valori di questi flag. Cloud SQL conserva i log binari su disco per il minimo dei giorni di conservazione dei log delle transazioni o per i valori impostati per i flag. Per saperne di più su come vengono archiviati i log per il PITR dopo il passaggio e su come liberare spazio su disco, consulta Log dopo il passaggio a Cloud Storage.

Nota: alcune istanze create tra giugno 2023 e agosto 2023 potrebbero avere i valori dei flag expire_logs_days o binlog_expire_logs_seconds impostati automaticamente sull'equivalente di 7 giorni.

Limitazioni PITR

Le seguenti limitazioni sono associate all'istanza con PITR abilitato e alle dimensioni dei log delle transazioni sul disco che causano un problema per l'istanza:

• Puoi disattivare il PITR e riattivarlo per assicurarti che Cloud SQL memorizzi 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 PITR.
• Puoi aumentare le dimensioni dello spazio di archiviazione dell'istanza, ma l'aumento delle dimensioni del log delle transazioni nell'utilizzo del disco potrebbe essere temporaneo.
• Per evitare problemi di spazio di archiviazione imprevisti, ti consigliamo di attivare gli aumenti automatici dello spazio di archiviazione. Questo suggerimento si applica solo se PITR è abilitato per l'istanza e i log sono archiviati su disco.

• Se vuoi eliminare i log e recuperare spazio di archiviazione, puoi disattivare PITR senza riattivarla. 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 istruzioni passo passo su come eseguire il PITR, vedi [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, 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 a 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 valori per le zone preferite.

Supponiamo che un'istanza Cloud SQL non sia più disponibile alle 16:00 EST. Se l'ultimo orario di recupero è alle 15:55 EST, puoi recuperare l'istanza fino a questo orario.

Ripristinare un'istanza eliminata utilizzando il recupero point-in-time

Puoi utilizzare il PITR per ripristinare un'istanza Cloud SQL dopo l'eliminazione. Per utilizzare questa funzionalità, l'istanza deve avere PITR e backup conservati attivati prima dell'eliminazione dell'istanza. Se questa opzione è attivata, 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 rotativa dopo l'eliminazione dell'istanza. Il periodo di rotazione è definito in base al periodo di conservazione PITR impostato sull'istanza prima dell'eliminazione. Ad esempio, se la conservazione PITR è impostata su 14 giorni per l'istanza Cloud SQL Enterprise Plus, 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 in Google Cloud con i seguenti campi:

• instance_deletion_time
• log_retention_days

Questi campi ti consentono di identificare se un log PITR appartiene a un'istanza eliminata.

La finestra di recupero PITR è definita come gli orari di recupero più recenti e meno recenti disponibili per ripristinare l'istanza utilizzando PITR. Per trovare gli orari di recupero più recenti e meno recenti dell'istanza eliminata, consulta Recuperare l'orario di recupero più recente e meno 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.

• La capacità di archiviazione dell'istanza di destinazione deve essere almeno pari alla capacità dell'istanza di cui viene eseguito il backup. La quantità di spazio di archiviazione utilizzato non ha importanza. Puoi visualizzare la capacità di archiviazione dell'istanza nella pagina Istanze Cloud SQL della console.

• L'istanza di destinazione deve essere nello stato RUNNABLE.

Ripristinare le limitazioni di frequenza

Sono consentite un massimo di tre operazioni di ripristino ogni 30 minuti per istanza per regione per progetto. Se un'operazione di ripristino non va a buon fine, non viene conteggiata ai fini di questa quota. Se raggiungi il limite, l'operazione non va a buon fine e viene visualizzato un messaggio di errore che indica quando puoi eseguirla di nuovo.

Cloud SQL utilizza i token di un bucket per determinare il numero di operazioni di ripristino disponibili in un determinato momento. Per ogni backup, esiste 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 puoi utilizzare un massimo di tre token 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 va a buon fine, il token viene rimosso dal bucket. Se non va a buon fine, 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 che hanno come target 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, in quella regione sono presenti cinque bucket per il backup, uno in ogni progetto. Nella figura precedente, abbiamo due progetti nella regione A: il progetto 1 e il 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).
  • Allo stesso modo, 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.

Passaggi successivi

• Eseguire il ripristino da un backup
• Utilizzare il recupero point-in-time (PITR)