Informazioni sugli snapshot RDB

Questa pagina offre una panoramica degli snapshot RDB per Memorystore for Redis. Questa pagina presuppone che tu conosca gli snapshot RDB di Redis open source e la funzionalità di importazione/esportazione di Memorystore.

Per scoprire come attivare, disattivare e monitorare gli snapshot RDB, consulta Gestione degli snapshot RDB.

Memorystore for Redis viene utilizzato principalmente come cache in memoria. Quando utilizzi Memorystore come cache, la tua applicazione può tollerare la perdita dei dati della cache o può ripopolare molto facilmente la cache da un archivio permanente. Tuttavia, in alcuni casi il tempo di inattività di un'istanza Memorystore o la perdita completa dei dati dell'istanza possono causare lunghi tempi di inattività dell'applicazione.

Ti consigliamo di utilizzare il livello standard come meccanismo principale per l'alta disponibilità. Inoltre, l'attivazione degli snapshot RDB sulle istanze di livello Standard fornisce una protezione aggiuntiva dai guasti che possono causare lo svuotamento della cache. Il livello standard fornisce un'istanza a disponibilità elevata con più repliche e consente un rapido ripristino utilizzando il failover automatico se l'istanza principale non funziona.

In alcuni scenari, potresti anche voler assicurarti che i dati possano essere recuperati dai backup degli snapshot in caso di guasto catastrofico delle istanze Standard Tier. In questi scenari, i backup automatici e la possibilità di ripristinare i dati dagli snapshot RDB possono fornire una protezione aggiuntiva dalla perdita di dati. Se gli snapshot RDB sono abilitati, se necessario, viene eseguito un ripristino dall'ultimo snapshot RDB.

Gli snapshot RDB sono adatti ai casi d'uso che possono tollerare una certa quantità di dati obsoleti dopo il recupero. Puoi anche utilizzare gli snapshot RDB per automatizzare il backup e il ripristino delle istanze di livello base.

Panoramica degli snapshot RDB

La funzionalità degli snapshot RDB ha il seguente comportamento:

  • Memorizza snapshot point-in-time completi a intervalli specificati dall'utente sullo spazio di archiviazione permanente.

  • Sei tu a scegliere la frequenza e la pianificazione degli snapshot di routine. L'intervallo minimo tra gli snapshot è 1h e quello massimo è 24h.

  • Le istanze di livello base recuperano i dati dallo snapshot più recente ogni volta che un'istanza viene riavviata a causa di un errore, viene sottoposta a un'operazione di scalabilità o a un upgrade della versione OSS di Redis.

  • Per impostazione predefinita, le istanze di livello standard recuperano i dati dalla replica, non da uno snapshot. Tuttavia, le istanze di livello Standard recuperano i dati da uno snapshot se una replica non è disponibile e sia la replica primaria che quella secondaria vengono riavviate.

  • Non aggiunge costi aggiuntivi alla fatturazione dell'istanza.

Comportamento aggiuntivo

  • Gli snapshot vengono utilizzati per il recupero delle istanze e non sono disponibili per i ripristini manuali. In qualsiasi momento, per il recupero è disponibile solo l'ultimo snapshot riuscito. Oltre agli snapshot RDB, puoi utilizzare Esporta e importa per eseguire manualmente il backup e il ripristino dei dati.

  • Su un'istanza del livello Standard, lo snapshot viene eseguito sulla replica per ridurre al minimo l'utilizzo di memoria e CPU sul database primario. Gli snapshot non vengono mai acquisiti dal nodo primario.

Vincoli

  • Disponibile sulle istanze Memorystore for Redis che utilizzano Redis versione 5.0 o successiva.

  • Se la tua istanza ha molte chiavi (circa 200 milioni o più), gli snapshot RDB e i recuperi possono essere lenti. In questo volume chiave, il server Redis stesso può essere il collo di bottiglia che rallenta gli snapshot e i recuperi.

Pianificazione degli snapshot RDB

Quando abiliti gli snapshot RDB durante la creazione dell'istanza, devi specificare un intervallo di snapshot. Hai anche la possibilità di specificare un orario di inizio. Insieme definiscono la pianificazione giornaliera degli snapshot. Gli intervalli che puoi impostare sono 1h, 6h, 12h e 24h. Ad esempio, se imposti l'ora di inizio alle 4:00 e l'intervallo a 1 ora, gli snapshot iniziano alle 4:00 del giorno in cui vengono attivati e continuano ogni ora.

Se non viene specificata un'ora di inizio, il primo snapshot viene acquisito il prima possibile e l'intervallo viene rispettato. Ad esempio, con un'ora di inizio non specificata e un intervallo di 1 ora, l'istantanea può iniziare alle 6:13 e continuare alle 7:13, alle 8:13 e così via.

Se viene specificata un'ora di inizio, la pianificazione giornaliera viene rispettata in modo coerente se gli snapshot vengono sempre creati correttamente e non richiedono più tempo dell'intervallo di backup specificato.

Tuttavia, l'attivazione dello snapshot in base alla pianificazione giornaliera viene eseguita al meglio delle possibilità. La pianificazione può discostarsi da quella inizialmente determinata per una serie di motivi:

  • Se uno snapshot non va a buon fine o richiede più tempo dell'intervallo specificato per il completamento, lo snapshot successivo inizia immediatamente dopo il completamento di quello corrente.

    • Per evitare che lo snapshot venga eseguito continuamente e sovraccarichi l'istanza, ti consigliamo di impostare un intervallo sufficientemente lungo da consentire il completamento dello snapshot.

  • Se è già in corso uno snapshot in un momento allineato alla pianificazione giornaliera, lo snapshot viene completato e l'ora dello snapshot successivo viene calcolata solo in base all'intervallo dall'inizio dell'ultimo snapshot riuscito.

Modifica della programmazione esistente

Potresti riscontrare scenari in cui vuoi sospendere temporaneamente l'acquisizione di snapshot RDB per un determinato periodo di tempo. Questo potrebbe essere per garantire che non vi siano impatti sulle prestazioni durante eventi critici o per disattivare temporaneamente gli snapshot per risolvere i problemi di prestazioni.

Per interrompere temporaneamente l'acquisizione di snapshot per un breve periodo di tempo, puoi modificare l'ora di inizio in modo che corrisponda a una data futura. Una volta modificato l'orario di inizio con una data futura, la successiva istantanea non inizierà fino a quella data. Se lo fai, l'ultimo snapshot viene conservato per almeno 7 giorni e viene utilizzato in caso di ripristino.

Per saperne di più sulla modifica delle pianificazioni degli snapshot, vedi Modifica della pianificazione degli snapshot.

Comportamento di recupero

Le istanze Redis di livello base attivano un ripristino ogni volta che l'istanza viene riavviata. Le operazioni comuni che attivano i riavvii sono lo scaling e l'upgrade della versione dell'istanza. Gli snapshot RDB conservano i dati delle istanze di livello base durante queste operazioni che causano riavvii, manutenzione pianificata e guasti imprevisti del sistema.

Le istanze Redis di livello Standard eseguono il failover su una replica come meccanismo di recupero principale anziché caricare da uno snapshot. Un'istanza di livello standard viene recuperata dallo snapshot quando il ripristino da una replica non riesce.

Coerenza dei dati durante il recupero

Se abilitati, gli snapshot RDB fanno del loro meglio per garantire che i backup vengano eseguiti all'intervallo specificato, ma ciò non può essere garantito. Gli snapshot possono non riuscire per diversi motivi. Consulta le best practice su come configurare e monitorare le istanze quando gli snapshot RDB sono abilitati.

Se lo snapshot non va a buon fine consecutivamente in più intervalli, l'ultimo backup disponibile potrebbe essere arbitrariamente obsoleto.

La perdita di dati nel caso peggiore per un ripristino da uno snapshot è la somma dell'intervallo specificato dall'inizio dell'ultimo snapshot valido e del tempo necessario per salvare lo snapshot successivo nello spazio di archiviazione. In caso di incidente di recupero, utilizza la metrica last_success_age per visualizzare il periodo di tempo per la perdita di dati.

Ti consigliamo di impostare avvisi per rilevare gli errori degli snapshot pianificati e intraprendere azioni correttive. Per saperne di più sulla configurazione degli avvisi, consulta Monitoraggio degli snapshot.

Tempo di recupero

L'istanza non è disponibile durante il recupero da uno snapshot. Il tempo di recupero dipende dalle dimensioni dello snapshot. Per comprendere il tempo di ripristino previsto, controlla la metrica RDB recovery remaining time utilizzando Cloud Monitoring nella console Google Cloud .

Mitigare il recupero lento

A volte il ripristino da un'istantanea potrebbe richiedere più tempo del previsto. Potresti dover intervenire per ricollegare la tua applicazione a Redis il più rapidamente possibile.

In questo caso, puoi creare una nuova istanza Redis e indirizzare il traffico dell'applicazione. Una volta ripristinati, puoi trasferire i dati nella nuova istanza dopo il recupero dell'istanza originale.

Errore snapshot ed errore di ripristino

Errore snapshot

Qualsiasi snapshot non riuscito viene segnalato a Cloud Monitoring e il tentativo di creazione dello snapshot viene ripetuto immediatamente. Gli errori consecutivi degli snapshot aumentano la quantità di dati persi in caso di ripristino perché i dati recuperati diventano sempre più obsoleti. Per informazioni su come rilevare e risolvere i problemi relativi agli snapshot non riusciti, consulta Monitoraggio degli snapshot.

Recupero non riuscito

Gli errori di ripristino sono rari, ma possono verificarsi. Se si verifica un errore di ripristino, l'istanza viene ripristinata senza dati.

Best practice

Per ottenere risultati ottimali dal backup dell'istanza con gli snapshot RDB, segui le best practice descritte di seguito:

Gestione della memoria

Gli snapshot RDB utilizzano un fork del processo e un meccanismo di "copy-on-write" per acquisire uno snapshot dell'istanza. A seconda del pattern di scrittura nell'istanza, la memoria utilizzata dell'istanza aumenterà man mano che le pagine toccate dalle scritture vengono copiate. Nel caso peggiore, l'ingombro della memoria può essere il doppio delle dimensioni dei dati nell'istanza.

Per assicurarti che l'istanza abbia memoria sufficiente per completare lo snapshot, devi impostare maxmemory-gb all'80% della capacità dell'istanza, in modo che il 20% sia riservato all'overhead. Per saperne di più, consulta le best practice di gestione della memoria. Questo overhead di memoria, oltre agli snapshot di monitoraggio, ti aiuta a gestire il workload per avere snapshot riusciti.

Snapshot obsoleti

Il recupero dell'istanza da uno snapshot obsoleto può causare problemi di rendimento per l'applicazione, in quanto tenta di riconciliare una quantità significativa di chiavi obsolete o altre modifiche al database, ad esempio una modifica dello schema.

Se ritieni che lo snapshot sia troppo obsoleto o che l'istanza abbia subito altre modifiche importanti difficili da conciliare con lo snapshot, puoi disattivare e riattivare gli snapshot RDB. In questo modo vengono eliminati gli snapshot esistenti, consentendoti di evitare il recupero da uno snapshot obsoleto.

Per monitorare gli snapshot obsoleti, imposta un avviso per le metriche snapshot RDB last_status e last_success_age.

Ripristino prolungato da uno snapshot

Ti consigliamo di impostare un avviso per la metrica redis.googleapis.com/server/uptime per ricevere una notifica se la tua istanza non è più disponibile.

Se la tua istanza non è disponibile e il ripristino da uno snapshot richiede troppo tempo, puoi creare una nuova istanza Redis e indirizzare il traffico verso di essa. Una volta ripristinata l'istanza Redis originale, puoi trasferire i dati ripristinati alla nuova istanza.

Impatto sulle prestazioni degli snapshot RDB

A seconda del pattern del carico di lavoro, gli snapshot RDB possono influire sulle prestazioni dell'istanza e aumentare la latenza per le applicazioni.

A seconda della quantità di potenziale perdita di dati che la tua applicazione può tollerare, puoi ridurre al minimo l'impatto sulle prestazioni degli snapshot RDB pianificandone l'esecuzione durante i periodi di basso traffico dell'istanza.

Utilizza l'ora di inizio e l'intervallo per pianificare gli snapshot per gli orari richiesti. Ad esempio, se il carico è molto basso dalle 01:00 alle 04:00, puoi impostare l'ora di inizio alle 03:00 e l'intervallo a 24 ore.

Se il tuo sistema ha un carico costante e richiede snapshot frequenti, devi valutare attentamente l'impatto sulle prestazioni e soppesare i vantaggi dell'utilizzo di snapshot RDB per il workload.

Snapshot di monitoraggio

È importante monitorare gli snapshot e impostare avvisi per quelli non riusciti. Gli snapshot non riusciti possono indicare un'istanza sovraccarica che potrebbe continuare ad avere difficoltà a ripristinare lo snapshot.

Per un elenco delle metriche disponibili per il monitoraggio degli snapshot, consulta Metriche degli snapshot RDB. Per ricevere una notifica di uno snapshot non riuscito, imposta un avviso per la metrica last_status dello snapshot RDB. Puoi anche utilizzare la console Google Cloud per verificare la presenza di errori.

Monitoraggio dell'impatto sulle prestazioni

Puoi monitorare l'impatto sulle prestazioni di un'istantanea sulla tua istanza Memorystore visualizzando le metriche disponibili tramite Cloud Monitoring, come l'utilizzo della CPU, l'utilizzo della memoria e così via. Se hai notato un calo delle prestazioni, puoi utilizzare la metrica in_progress dell'istantanea RDB per determinare se era in corso un'istantanea quando sono stati rilevati problemi di prestazioni.

Passaggi successivi