Questa pagina fornisce informazioni da esaminare prima di ripristinare un'istanza da un backup o di eseguire un recupero point-in-time (PITR).
Cosa succede durante un ripristino?
Per le versioni Cloud SQL Enterprise e Cloud SQL Enterprise Plus, puoi ripristinare un'istanza da un backup. Puoi anche ripristinare i backup di istanze di versioni diverse.
Quando ripristini un'istanza, nella nuova istanza vengono ripristinati i seguenti dati dell'istanza principale:
- Database
- Utenti
L'operazione di ripristino determina il riavvio dell'istanza.
PIT
Il recupero point-in-time (PITR) consente di recuperare un'istanza in un momento specifico. Ad esempio, se un errore causa una perdita di dati, puoi ripristinare lo stato di un database prima che si verificasse.
Il PITR 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 come funziona la creazione di cloni.
Tuttavia, affinché la nuova istanza erediti queste impostazioni, lo stato dell'istanza deve essere RUNNABLE.
PITR usa il logging binario per archiviare i log. Per impostazione predefinita, il PITR è abilitato per le istanze della versione Cloud SQL Enterprise Plus.
Quando ripristini un backup su un'istanza Cloud SQL prima di abilitare PITR, perdi i log archiviati che ti consentono di utilizzare PITR. Se le dimensioni dei log binari sul disco causano problemi di prestazioni per l'istanza, disattiva il PITR e riabilitalo. Questa azione assicura che i nuovi log vengano archiviati in Cloud Storage anziché su disco.Per istruzioni dettagliate sull'esecuzione del PITR, consulta l'articolo Utilizzare il recupero point-in-time (PITR).
Suggerimenti generali sull'esecuzione di un ripristino
Quando ripristini un'istanza da un backup, nella stessa istanza o in un'altra, tieni presente quanto segue:
- L'operazione di ripristino sovrascrive tutti i dati nell'istanza di destinazione.
- 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.
- L'operazione di ripristino riavvia l'istanza.
Per istruzioni dettagliate sull'esecuzione di un ripristino, vedi:
Suggerimenti e requisiti per il ripristino su un'istanza diversa
Quando ripristini un backup in un'istanza diversa, tieni presente le restrizioni e le best practice seguenti:
L'istanza di destinazione deve avere la stessa versione del database dell'istanza da cui proviene il backup.
Se vuoi eseguire l'upgrade della versione del database per l'istanza, segui i passaggi descritti in Esegui l'upgrade della versione principale del database in loco.
Cloud SQL imposta sempre la capacità di archiviazione dell'istanza di destinazione sul valore massimo della dimensione del disco configurato e del disco di backup. Il disco di backup è la dimensione del disco al momento dell'esecuzione del 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 utilizzata non è importante. Puoi visualizzare la capacità di archiviazione dell'istanza nella pagina delle istanze Cloud SQL della console.
L'istanza di destinazione deve essere in stato
RUNNABLE.L'istanza di destinazione può utilizzare un numero di core e quantità di memoria diversi rispetto all'istanza da cui è stato recuperato il backup.
L'istanza di destinazione può trovarsi in una regione diversa dall'istanza di origine.
Durante un'interruzione, puoi comunque recuperare un elenco di backup in un determinato progetto. Vedi Visualizzare i backup durante un'interruzione.
Limitazioni della percentuale di ripristino
Sono consentite un massimo di tre operazioni di ripristino ogni 30 minuti per istanza per area geografica 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 è possibile eseguirla di nuovo.
Vediamo come Cloud SQL esegue la limitazione di frequenza per i ripristini.
Cloud SQL utilizza i token di un bucket per determinare quante operazioni di ripristino sono disponibili in qualsiasi momento. Per ogni backup, c'è un bucket per ogni progetto e regione di destinazione. Le istanze di destinazione dello stesso progetto condividono un bucket se si trovano nella stessa regione. In ogni bucket sono presenti 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, si verifica un overflow del token.
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. In caso di errore, il token viene restituito al bucket. Il seguente diagramma illustra il funzionamento:
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 ci sono cinque progetti in una regione, esistono cinque bucket per il 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).
- 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 Project1, perché tutte le istanze nello stesso progetto di destinazione e nella stessa regione di destinazione condividono un bucket.