Informazioni sul ripristino di un'istanza

Questa pagina fornisce informazioni da esaminare prima di ripristinare un'istanza da un backup o eseguire un recupero point-in-time (PITR).

Che cosa succede durante un ripristino?

Quando ripristini un'istanza, vengono ripristinati i seguenti dati nell'istanza principale:

  • Database
  • Utenti

L'operazione di ripristino causa il riavvio dell'istanza.

Recupero point-in-time

Il recupero point-in-time ti consente di recuperare un'istanza in un momento specifico. Ad esempio, se un errore causa una perdita di dati, puoi recuperare il suo database nello stato precedente all'errore.

Un recupero point-in-time crea sempre una nuova istanza; non è possibile eseguire un recupero point-in-time su un'istanza esistente. La nuova istanza eredita le impostazioni dell'istanza di origine, in modo simile al funzionamento della creazione di cloni.

Il recupero point-in-time è abilitato per impostazione predefinita quando crei una nuova istanza Cloud SQL.

Per istruzioni dettagliate su come eseguire un recupero point-in-time, consulta l'articolo Eseguire un recupero point-in-time.

Suggerimenti generali sull'esecuzione di un ripristino

Quando ripristini un'istanza da un backup, nella stessa istanza o in un'altra istanza, 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 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 a un'istanza diversa

Quando ripristini un backup a un'altra istanza, tieni presente le seguenti restrizioni e best practice:

  • L'istanza di destinazione deve avere la stessa versione del database e la stessa versione dell'istanza da cui è stato eseguito il backup.

    Se vuoi eseguire l'upgrade della versione del database per la tua istanza, segui i passaggi descritti in Eseguire l'upgrade del database per un'istanza.

  • La capacità di archiviazione dell'istanza di destinazione deve essere almeno pari alla capienza dell'istanza di cui viene eseguito il backup. La quantità di spazio di archiviazione utilizzata non è importante. Puoi verificare 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 una quantità di memoria diversi rispetto all'istanza da cui è stato eseguito il backup.

  • L'istanza di destinazione può trovarsi in un'area geografica diversa da quella dell'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 frequenza di ripristino

Sono consentite un massimo di tre operazioni di ripristino ogni 30 minuti per istanza per area geografica e progetto. Se un'operazione di ripristino non riesce, non viene conteggiata per questa quota. Se raggiungi il limite, l'operazione non riuscirà e verrà visualizzato un messaggio di errore che indica quando puoi eseguirla di nuovo.

Diamo un'occhiata al modo in cui 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 esiste 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 area geografica. In ogni bucket sono disponibili massimo 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 fuoriesce.

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:

Come funzionano i token

Ad esempio, nella figura seguente, Backup1, Backup2 e Backup3 sono i backup della stessa istanza di origine.

Token per la limitazione della frequenza di ripristino

  • 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 nell'area geografica A (bucket11A, bucket21A e bucket31A). 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 un'area geografica separata. Ad esempio, se in un'area geografica sono presenti cinque progetti, in questa area geografica saranno presenti cinque bucket, uno per ogni progetto. Nella figura precedente abbiamo due progetti nell'area geografica A: Progetto 1 e Progetto n.
    • Backup1 ha due bucket di token per le operazioni di ripristino nell'area geografica 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 nell'area geografica A. Uno per il Progetto 1 (Bucket31A) e uno per il Progetto n (Bucket3nA).
  • Backup3 ha un bucket nell'area geografica B, per il Progetto 1, perché tutte le istanze nello stesso progetto di destinazione e nella stessa area geografica di destinazione condividono un bucket.

Passaggi successivi