Questa pagina fornisce informazioni da esaminare prima di ripristinare un'istanza da un backup o l'esecuzione di 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 su istanze di versioni diverse.
Quando ripristini un'istanza, i seguenti dati dell'istanza principale vengono ripristinati nella nuova istanza:
- Database
- Utenti
L'operazione di ripristino determina il riavvio dell'istanza.
Recupero point-in-time (PITR)
Il recupero point-in-time (PITR) consente di recuperare un'istanza in un punto specifico nel tempo. Ad esempio, se un errore causa una perdita di dati, puoi ripristinare un database allo stato precedente all'errore.
PITR crea sempre una nuova istanza, non puoi eseguire PITR su un'istanza esistente. La nuova istanza eredita delle impostazioni dell'istanza di origine, in modo simile funziona la creazione clone.
Quando crei un'istanza Cloud SQL nella console Google Cloud, Il PITR è abilitato per impostazione predefinita.Il PITR utilizza logging write-ahead (WAL). Per impostazione predefinita, PITR è abilitato per le istanze della versione Cloud SQL Enterprise Plus.
Quando ripristini un backup su un'istanza Cloud SQL prima di abilitarlo PITR, perderai i log archiviati che ti consentono di utilizzare PITR Se la dimensione dei log write-ahead il disco sta causando problemi di prestazioni per l'istanza, quindi disattivalo PITR e riattivarla. Questa azione garantisce che i nuovi log in Cloud Storage anziché su disco.Per istruzioni dettagliate sull'esecuzione del PITR, consulta l'articolo Utilizzare il recupero point-in-time (PITR).
Ripristina un'istanza non disponibile
Puoi utilizzare PITR per ripristinare un'istanza Cloud SQL che non è disponibile. Il PITR in genere offre un RPO (Recovery Point Objective) di cinque minuti o meno.
Se l'istanza non è disponibile, puoi utilizzare l'API per controllare l'ora più recente in cui puoi ripristinare l'istanza ed eseguire il ripristino fino a quel momento. Se la zona in cui è configurata l'istanza non è accessibile, puoi clonare l'istanza in una zona diversa.
Supponiamo che un'istanza Cloud SQL non sia disponibile alle 16:00 EST. Se l'ora di recupero più recente è alle 15:55 EST, puoi recuperare l'istanza fino a questo momento.
Suggerimenti generali sull'esecuzione di un ripristino
Quando ripristini un'istanza da un backup, nella stessa istanza o per un'istanza diversa, tieni presente quanto segue:
- L'operazione di ripristino sovrascrive tutti i dati sull'istanza di destinazione.
- L'istanza di destinazione non è disponibile per le connessioni durante il ripristino operativa; le connessioni esistenti vengono perse.
- Se stai eseguendo il ripristino in un'istanza con accesso devi eliminare tutte le repliche e ricrearle dopo il ripristino l'operazione.
- L'operazione di ripristino riavvia l'istanza.
Per istruzioni dettagliate sull'esecuzione di un ripristino, vedi:
Suggerimenti e requisiti per il ripristino in un'istanza diversa
Quando ripristini un backup in un'altra istanza, tieni presente che le seguenti restrizioni e best practice:
L'istanza di destinazione deve avere la stessa versione del database dell'istanza da cui è stato estratto il backup.
Cloud SQL imposta sempre la capacità di archiviazione dell'istanza di destinazione valore massimo della dimensione del disco configurato e del disco di backup. La il disco di backup è la dimensione del disco quando viene eseguito il backup.
La capacità di archiviazione dell'istanza di destinazione deve essere almeno pari a capacità dell'istanza di cui viene eseguito il backup. La quantità di spazio di archiviazione utilizzata non importa. Puoi vedere la capacità di archiviazione dell'istanza nella console Cloud SQL delle istanze VM.
L'istanza di destinazione deve essere nello stato
RUNNABLE.L'istanza di destinazione può avere un numero diverso di core o una quantità diversa di memoria rispetto all'istanza da cui è stato estratto 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 una progetto. Consulta Visualizzare i backup durante un'interruzione del servizio.
Limitazioni di frequenza di ripristino
È consentito un massimo di tre operazioni di ripristino ogni 30 minuti per per ogni regione e per progetto. Se un'operazione di ripristino non va a buon fine, non viene conteggiata a questa quota. Se raggiungi il limite, l'operazione non va a buon fine e viene generato un errore che ti avvisa quando puoi eseguire di nuovo l'operazione.
Vediamo in che modo Cloud SQL esegue la limitazione di frequenza per i ripristini.
Cloud SQL utilizza i token di un bucket per determinare il numero di operazioni di ripristino disponibili in qualsiasi momento. Per ogni backup, c'è un bucket per ogni target progetto e regione di destinazione. Le istanze di destinazione dello stesso progetto condividono un bucket se si trovano nella stessa regione. Ogni bucket contiene un massimo di tre token che puoi utilizzare per le operazioni di ripristino. Ogni 10 minuti, un nuovo token viene aggiunto al bucket. Se il bucket è piena, il token va in overflow.
Ogni volta che esegui un'operazione di ripristino, viene concesso un token dal bucket. Se l'operazione riesce, il token viene rimosso dal bucket. Se non riesce, viene restituito al bucket. Il seguente diagramma mostra come funziona:
Ad esempio, nella figura seguente, Backup1, Backup2 e Backup3 sono i backup dalla stessa istanza di origine.
- Ogni backup (Backup1, Backup2 e Backup3) ha il proprio bucket di token ripristina le operazioni 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, ci sono cinque
per il backup nella regione, uno in ogni progetto. Nella precedente
nella figura A, 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. Uno. 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 Progetto1, perché tutte le istanze lo stesso progetto e la stessa regione di destinazione condividono un bucket.