Informazioni sul recupero point-in-time (PITR)

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Il recupero point-in-time di Spanner (PITR) fornisce protezione contro l'eliminazione o le scritture accidentali. Ad esempio, se un operatore scrive dati inavvertitamente o un'implementazione di un'applicazione danneggia il database, con PITR puoi recuperare i dati da un momento precedente in passato (fino a un massimo di 7 giorni). Se hai bisogno di conservare i dati a lungo termine, puoi utilizzare Backup e ripristino o Esporta e importa.

Per impostazione predefinita, il tuo database conserva tutte le versioni dei suoi dati e schema per 1 ora. Puoi aumentare questo limite di tempo fino a 7 giorni tramite l'opzione version_retention_period. Spanner archivia le versioni precedenti dei dati con granularità in microsecondi e il database mantiene una earliest_version_time, che rappresenta la prima data/ora in cui è possibile recuperare le versioni precedenti dei dati.

Metodi per recuperare i dati

Esistono due modi per recuperare i dati:

  • Per recuperare una parte del database, esegui una lettura temporanea specificando una condizione della query e un timestamp nel passato, quindi scrivi di nuovo i risultati nel database pubblicato. Questa soluzione di solito viene utilizzata per interventi chirurgici su un database in tempo reale. Ad esempio, se elimini accidentalmente una determinata riga o aggiorni in modo errato un sottoinsieme di dati, puoi recuperarla con questo metodo. Per le istruzioni, vedi recupero di una parte del tuo database.

  • Per recuperare l'intero database, esegui il backup o esporta il database specificando un timestamp nel passato, quindi ripristinalo o importalo in un nuovo database. Questa opzione viene in genere utilizzata per ripristinare i problemi di danneggiamento dei dati quando è necessario ripristinare l'intero database su un punto di accesso prima che si verificasse il danneggiamento. Tieni presente che il backup o l'esportazione di un database potrebbe richiedere diverse ore e che non è possibile ripristinarlo o importarlo in un database esistente. Per le istruzioni, vedi Recupero dell'intero database.

Considerazioni sul rendimento

I database con periodi di conservazione più lunghi e, in particolare, quelli che spesso sovrascrivono i dati, utilizzano più risorse di sistema. Ciò può influire sulle prestazioni del tuo database, soprattutto se non è stato eseguito il provisioning sufficiente per la istanza di capacità di calcolo. Se il tuo database ha una frequenza di sovrascrittura molto elevata (ad esempio, se il database viene sovrascritto più volte al giorno), potresti valutare di aumentare il periodo di conservazione e monitorare il sistema in modo graduale. Ecco alcuni aspetti da tenere presenti:

  • Maggiore utilizzo dello spazio di archiviazione. Ti consigliamo di configurare gli avvisi sullo spazio di archiviazione per assicurarti di non superare il limite di archiviazione. Quando aumenti il periodo di conservazione, tieni presente che l'utilizzo dello spazio di archiviazione aumenterà gradualmente man mano che il database accumulerà versioni precedenti dei dati. Questo perché i dati precedenti che sarebbero scaduti durante il periodo di conservazione precedente non sono più scaduti. Quindi, ad esempio, se aumenti il periodo di conservazione da 3 giorni a 7 giorni, dovrai attendere 4 giorni prima che l'utilizzo dello spazio di archiviazione si stabilizzi. Forniamo anche istruzioni per stimare l'aumento di spazio di archiviazione.

  • Aumento dell'utilizzo e della latenza della CPU. Spanner utilizza risorse di calcolo aggiuntive per compattare e gestire le vecchie versioni dei dati. Monitora l'istanza e il database per assicurarti che la latenza e l'utilizzo della CPU rimangano a livelli accettabili.

  • Tempo maggiore per eseguire gli aggiornamenti dello schema. Un periodo di conservazione più lungo significa che le versioni dello schema devono essere conservate per durate più lunghe, il che potrebbe far sì che gli aggiornamenti dello schema siano throttled in attesa di risorse del server. Assicurati di seguire le best practice per gli aggiornamenti dello schema e di rispettare i limiti per gli aggiornamenti dello schema.

Passaggi successivi