Questa pagina fornisce informazioni da esaminare prima di ripristinare un'istanza da un backup o eseguire un recupero point-in-time (PITR).
Cosa succede durante un ripristino?
Quando ripristini un'istanza, i seguenti dati dell'istanza principale vengono ripristinati nella nuova istanza:
- Database
- Utenti
L'operazione di ripristino causa il riavvio dell'istanza.
Recupero point-in-time
Il recupero point-in-time ti aiuta a 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 verifichi l'errore.
Un recupero point-in-time crea sempre una nuova istanza; non puoi eseguire un recupero point-in-time in un'istanza esistente. La nuova istanza eredita le impostazioni dell'istanza di origine, in modo simile a come funziona la creazione di cloni. Tuttavia, la nuova istanza può ereditare queste impostazioni solo se lo stato dell'istanza è RUNNABLE.
Per istruzioni dettagliate per eseguire un recupero point-in-time, consulta Eseguire un recupero point-in-time.
Suggerimenti generali sull'esecuzione di un ripristino
Quando ripristini un'istanza da un backup, alla stessa istanza o in un'istanza diversa, tieni presente i seguenti elementi:
- 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 ripristini 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.
Per istruzioni dettagliate su come eseguire un ripristino, consulta le seguenti risorse:
Suggerimenti e requisiti per il ripristino in un'istanza diversa
Quando ripristini un backup di un'istanza diversa, tieni presente le seguenti limitazioni e best practice:
L'istanza di destinazione deve avere la stessa versione di database e la stessa edizione dell'istanza da cui è stata presa il backup.
Se vuoi eseguire l'upgrade della versione del database per l'istanza, segui i passaggi descritti in Eseguire l'upgrade della versione principale del database in loco.
Cloud SQL imposta sempre la capacità di archiviazione dell'istanza di destinazione sul valore massimo delle dimensioni sia del disco configurato che del disco di backup. Il disco di backup è la dimensione del disco quando viene eseguito il backup.
La capacità di archiviazione dell'istanza di destinazione deve essere pari almeno alla capacità dell'istanza di cui viene eseguito il backup. La quantità di spazio di archiviazione utilizzato non è rilevante. Puoi visualizzare la capacità di archiviazione dell'istanza nella pagina 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 estratto il backup.
L'istanza di destinazione può trovarsi in una regione diversa da quella dell'istanza di origine.
Durante un'interruzione, puoi ancora recuperare un elenco dei backup in un determinato progetto. Vedi Visualizzare i backup durante un'interruzione.
Limiti di frequenza di ripristino
Sono consentite al massimo tre operazioni di ripristino ogni 30 minuti per istanza per regione e per progetto. Se un'operazione di ripristino non riesce, non viene conteggiata per questa quota. Se raggiungi il limite, l'operazione non va a buon fine e viene visualizzato un messaggio di errore che indica quando puoi eseguire di nuovo l'operazione.
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 un dato momento. Per ogni backup è disponibile un bucket per ogni progetto e area geografica di destinazione. Le istanze di destinazione dello stesso progetto condividono un bucket se si trovano nella stessa regione. È disponibile un massimo di tre token in ogni bucket che puoi utilizzare per le operazioni di ripristino. Ogni 10 minuti viene aggiunto un nuovo token al bucket. Se il bucket è pieno, il token eccede.
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 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) dispone di un proprio bucket di token per le operazioni di ripristino che hanno come target istanze diverse nel Progetto 1 nella regione A (bucket11A, bucket21A e bucket 31A). Poiché ogni backup ha il proprio bucket, puoi ripristinare ogni backup nella stessa istanza tre volte ogni trenta minuti.
- Ogni backup ha un bucket per un progetto separato e per una regione separata.
Ad esempio, se in un'area geografica ci sono cinque progetti, esistono cinque bucket per il backup in quell'area geografica, uno per ogni progetto. Nella figura precedente sono presenti 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.