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 open source Redis e la funzionalità di importazione/esportazione di Memorystore.

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

Memorystore per Redis viene utilizzato principalmente come cache in memoria. Quando utilizzi Memorystore come cache, l'applicazione può tollerare la perdita di dati della cache o ricompilare molto facilmente la cache da un archivio permanente. Tuttavia, in alcuni casi d'uso i tempi di inattività per un'istanza Memorystore o la perdita completa dei dati dell'istanza possono causare lunghi tempi di inattività delle applicazioni.

Ti consigliamo di utilizzare il livello Standard come meccanismo principale per l'alta disponibilità. Inoltre, l'abilitazione degli snapshot RDB nelle istanze del livello Standard offre un'ulteriore protezione dagli errori che possono causare svuotamenti della cache. Il livello Standard fornisce un'istanza a disponibilità elevata con più repliche e consente il recupero rapido utilizzando il failover automatico in caso di errore dell'istanza principale.

In alcuni scenari è consigliabile anche assicurarti che i dati possano essere recuperati dai backup degli snapshot in caso di errore catastrofico delle istanze del livello Standard. In questi scenari, i backup automatici e la possibilità di ripristinare i dati dagli snapshot RDB possono fornire un'ulteriore protezione dalla perdita di dati. Con gli snapshot RDB abilitati, se necessario, viene eseguito un ripristino dallo snapshot RDB più recente.

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

Panoramica degli snapshot RDB

Il comportamento della funzionalità snapshot RDB è il seguente:

  • Archivia snapshot point-in-time completi a intervalli specificati dall'utente in archiviazione permanente.

  • Sei tu a scegliere la frequenza e la programmazione degli snapshot delle routine. L'intervallo minimo di snapshot è 1h, mentre il massimo è 24h.

  • Le istanze del 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 viene eseguita un upgrade per la versione OSS Redis dell'istanza.

  • Per impostazione predefinita, le istanze del livello Standard recuperano i dati dalla replica, non da uno snapshot. Tuttavia, le istanze di livello Standard recuperano i dati da uno snapshot se non è disponibile una replica e se si verifica un riavvio sia della replica principale che della replica.

  • Non aggiunge costi aggiuntivi alla fatturazione dell'istanza.

Comportamento aggiuntivo

  • Gli snapshot vengono utilizzati per il recupero dell'istanza e non sono disponibili per il ripristino manuale. In qualsiasi momento, è disponibile per il recupero solo l'ultimo snapshot riuscito. Oltre agli snapshot RDB, puoi utilizzare Esportazione e importazione per eseguire manualmente il backup e il ripristino dei dati.

  • In un'istanza di livello Standard, lo snapshot viene acquisito nella replica per ridurre al minimo l'utilizzo di memoria e CPU sull'istanza principale. Gli snapshot non vengono mai acquisiti dal nodo principale.

Limitazioni

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

  • Se l'istanza ha molte chiavi (circa 200 milioni o più), gli snapshot e i recuperi RDB possono essere lenti. A questo volume di chiavi, il server Redis stesso può rappresentare il collo di bottiglia che rallenta snapshot e 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'ora di inizio. Insieme, questi elementi 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 04:00 e l'intervallo su 1 ora, gli snapshot iniziano alle 04:00 del giorno in cui vengono abilitati e continuano ogni ora dopo.

Se non viene specificata un'ora di inizio, il primo snapshot viene acquisito non appena possibile e l'intervallo viene rispettato. Ad esempio, con un'ora di inizio non specificata e un intervallo di un'ora, lo snapshot può iniziare alle 06:13 e continuare alle 07:13, 08:13 e così via.

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

Tuttavia, l'attivazione dell'istantanea in base alla pianificazione giornaliera è la soluzione migliore. La programmazione può discostarsi da quella determinata inizialmente per una serie di motivi:

  • Se uno snapshot non riesce o richiede più tempo dell'intervallo di snapshot specificato, lo snapshot successivo inizia immediatamente dopo il completamento dello snapshot 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 uno snapshot è già in corso in un orario in linea con la pianificazione giornaliera, viene completato e la data e l'ora dello snapshot successivo vengono calcolate esclusivamente nell'intervallo dall'inizio dell'ultimo snapshot riuscito.

Regolare la programmazione esistente

Potresti imbatterti in scenari in cui vuoi mettere temporaneamente in pausa l'esecuzione degli snapshot RDB per un determinato periodo di tempo. Ciò potrebbe essere per garantire che non ci siano impatti sulle prestazioni durante eventi critici o per disabilitare temporaneamente gli snapshot per risolvere i problemi di prestazioni.

Per interrompere temporaneamente l'acquisizione di snapshot per un breve periodo di tempo, puoi impostare l'ora di inizio in modo che corrisponda a una data futura. Se imposti l'ora di inizio su una data futura, lo snapshot successivo non inizierà prima di quella data. In questo caso, l'ultimo snapshot viene conservato per almeno 7 giorni e viene utilizzato in caso di ripristino.

Per ulteriori informazioni sulla regolazione delle pianificazioni di snapshot, consulta la sezione Regolare la pianificazione degli snapshot.

Comportamento di recupero

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

Le istanze Redis di livello standard eseguono il failover su una replica come meccanismo di recupero principale anziché eseguire il caricamento da uno snapshot. Un'istanza di livello Standard viene ripristinata dallo snapshot quando il ripristino da una replica non va a buon fine.

Coerenza dei dati durante il ripristino

Se sono abilitati, gli snapshot RDB fanno il possibile per garantire che i backup vengano eseguiti nell'intervallo specificato, ma questo non può essere garantito. Gli snapshot possono avere errori per diversi motivi. Consulta le best practice su come configurare e monitorare le istanze quando sono abilitati gli snapshot RDB.

Se lo snapshot si arresta in modo consecutivo a intervalli multipli, l'ultimo backup disponibile potrebbe essere arbitrariamente inattivo.

Il caso peggiore per la perdita di dati per un ripristino da uno snapshot è la somma dell'intervallo specificato dall'inizio dell'ultimo snapshot valido e il 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 gli avvisi in modo da rilevare gli errori degli snapshot programmati e di eseguire azioni correttive. Per scoprire di più sulla configurazione degli avvisi, consulta Monitoraggio delle istantanee.

Tempo di recupero

L'istanza non è disponibile durante il recupero da uno snapshot. Il tempo di ripristino 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 recupero da uno snapshot può richiedere più tempo del previsto. Potresti dover intervenire per riconnettere la tua applicazione a Redis il più rapidamente possibile.

In questa circostanza puoi creare una nuova istanza Redis e indirizzarvi il traffico dell'applicazione. Quindi puoi trasferire i dati ripristinati nella nuova istanza dopo il recupero dell'istanza originale.

Errori relativi allo snapshot e al ripristino non riusciti

Errore dello snapshot

Qualsiasi snapshot non riuscito viene segnalato a Cloud Monitoring e viene eseguito un nuovo tentativo 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 gli errori degli snapshot, consulta Monitoraggio degli snapshot.

Ripristino non riuscito

Gli errori di ripristino sono rari, ma possono verificarsi. In caso di errore di recupero, l'istanza viene recuperata senza dati.

best practice

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

Gestione della memoria

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

Per assicurarti che l'istanza disponga di memoria sufficiente per completare lo snapshot, devi impostare maxmemory-gb sull'80% della capacità dell'istanza, in modo che il 20% sia riservato all'overhead. Per scoprire di più, consulta le best practice per la gestione della memoria. Questo overhead di memoria, oltre agli snapshot di Monitoring, consente di gestire il carico di lavoro in modo da ottenere snapshot correttamente.

Istantanee inattive

Il recupero dell'istanza da uno snapshot inattivo può causare problemi di prestazioni per l'applicazione, poiché tenta di riconciliare una quantità significativa di chiavi inattive o altre modifiche al database, ad esempio una modifica allo schema.

Se ritieni che lo snapshot sia troppo inattivo o se l'istanza ha subito altre modifiche importanti difficili da riconciliare con lo snapshot, puoi disabilitare e poi riattivare gli snapshot RDB. In questo modo vengono eliminati gli snapshot esistenti, in modo da evitare il ripristino da uno snapshot inattivo.

Per monitorare gli snapshot inattivi, imposta un avviso sulle metrics dello snapshot RDB last_status e last_success_age dello snapshot RDB.

Recupero prolungato da uno snapshot

Ti consigliamo di impostare un avviso per la metrica redis.googleapis.com/server/uptime per ricevere una notifica se l'istanza diventa non disponibile.

Se l'istanza non è disponibile e il recupero da uno snapshot sta richiedendo troppo tempo, puoi creare una nuova istanza Redis e indirizzarvi il traffico. Una volta ripristinata l'istanza Redis originale, puoi trasferire i dati ripristinati nella 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 potenziale perdita di dati che l'applicazione può tollerare, puoi ridurre al minimo l'impatto sulle prestazioni degli snapshot RDB pianificandone l'esecuzione durante periodi di traffico ridotto delle istanze.

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

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

Snapshot di monitoraggio

È importante monitorare gli snapshot e impostare avvisi per gli snapshot non riusciti. Gli snapshot non riusciti possono indicare un'istanza sovraccaricata che potrebbe continuare ad avere difficoltà a recuperare dallo snapshot.

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

Monitoraggio dell'impatto sulle prestazioni

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

Passaggi successivi