Questa pagina fornisce 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 Gestire gli snapshot RDB.
Memorystore for Redis viene utilizzato principalmente come cache in memoria. Quando utilizzi Memorystore come cache, la tua applicazione può tollerare la perdita di dati della cache o può ricolmare molto facilmente la cache da un archivio permanente. Tuttavia, esistono alcuni casi d'uso in cui 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 un'elevata disponibilità. Inoltre, l'attivazione degli snapshot RDB sulle istanze di livello standard offre una protezione aggiuntiva dai guasti che possono causare svuotamenti della cache. Il livello standard fornisce un'istanza altamente disponibile con più repliche e consente un recupero rapido utilizzando il failover automatico in caso di errore dell'istanza principale.
In alcuni scenari, ti consigliamo inoltre di assicurarti che i dati possano essere recuperati dai backup degli snapshot in caso di guasto catastrofico delle istanze di livello Standard. In questi scenari, i backup automatici e la possibilità di ripristinare i dati dagli snapshot RDB possono fornire una protezione aggiuntiva contro la perdita di dati. Se gli snapshot RDB sono attivati, se necessario, viene eseguito un recupero dall'ultimo snapshot RDB.
Gli snapshot RDB sono adatti a casi d'uso che possono tollerare una certa quantità di dati устарелости dopo il recupero. Puoi anche utilizzare gli snapshot RDB per automatizzare il backup e il recupero 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 su archiviazione persistente.
Sei tu a scegliere la frequenza e la pianificazione degli snapshot di routine. L'intervallo minimo delle istantanee è
1he 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 per la versione Redis OSS della tua istanza.
Per impostazione predefinita, le istanze di livello standard recuperano i dati dalla replica, non da un snapshot. Tuttavia, le istanze di livello standard recuperano i dati da uno snapshot se non è disponibile una replica e sia l'istanza principale che la replica vengono riavviate.
Non comporta costi aggiuntivi per la fatturazione delle istanze.
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.
In un'istanza di livello standard, lo snapshot viene acquisito sulla replica per ridurre al minimo l'utilizzo di memoria e CPU sull'istanza principale. Gli snapshot non vengono mai acquisiti dal nodo principale.
Vincoli
Disponibile nelle istanze Memorystore for Redis che utilizzano Redis 5.0 o versioni successive.
Se l'istanza ha molte chiavi (circa 200 milioni o più), gli snapshot e i recupero della RDB possono essere lenti. A questo volume chiave, il server Redis stesso può essere il collo di bottiglia che rallenta gli snapshot e i ripristini.
Pianificazione degli snapshot RDB
Quando attivi 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 parametri 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 su 4:00 e
l'intervallo su 1 ora, gli istantanei iniziano alle 4:00 del giorno in cui vengono attivati
e continuano ogni ora successiva.
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 06:13 e continuare alle 07:13, alle 08:13 e così via.
Se viene specificata un'ora di inizio, la pianificazione giornaliera viene rispettata in modo coerente se gli istantanei riescono sempre e non richiedono più tempo dell'intervallo di backup specificato.
Tuttavia, l'attivazione dello snapshot in base alla pianificazione giornaliera avviene secondo il criterio del massimo impegno. La programmazione può discostarsi da quella inizialmente stabilita per una serie di motivi:
Se uno snapshot non va a buon fine o richiede più tempo dell'intervallo di snapshot specificato per completarsi, lo snapshot successivo inizia immediatamente al termine 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 a un'ora in linea con la programmazione giornaliera, lo snapshot viene completato e l'ora dello snapshot successivo viene calcolata esclusivamente in base all'intervallo dall'inizio dell'ultimo snapshot riuscito.
Modificare la programmazione esistente
Potresti trovarti in situazioni in cui vuoi mettere temporaneamente in pausa l'acquisizione di istantanee RDB per un determinato periodo di tempo. Ad esempio, per assicurarti che non ci 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 impostare l'ora di inizio su una data futura. Una volta impostata l'ora di inizio su una data futura, l'istantanea successiva non inizierà fino a quella data. In questo modo, l'ultimo snapshot viene conservato per almeno 7 giorni e viene utilizzato in caso di recupero.
Per scoprire di più sulla modifica delle pianificazioni degli snapshot, consulta Modificare 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 il scaling e l'upgrade della versione dell'istanza. Gli snapshot RDB preservano 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 nell'intervallo specificato, ma non è possibile garantire questo risultato. Gli snapshot possono non andare a buon fine per diversi motivi. Consulta le best practice per scoprire come configurare e monitorare le istanze quando sono abilitati gli snapshot RDB.
Se lo snapshot non va a buon fine consecutivamente in più intervalli, l'ultimo backup disponibile può essere arbitrariamente obsoleto.
La perdita di dati peggiore per un recupero da uno snapshot è la somma dell'intervallo specificato dall'avvio dell'ultimo snapshot valido e del tempo necessario per salvare lo snapshot successivo nell'archiviazione. In caso di incidente di recupero, utilizza la metrica last_success_age per visualizzare il periodo di tempo di perdita di dati.
Ti consigliamo di impostare avvisi per rilevare i guasti degli screenshot pianificati e intervenire in modo appropriato. Per scoprire di più sull'impostazione 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 recupero previsto, controlla la metrica RDB recovery remaining time
utilizzando Cloud Monitoring
nella console Google Cloud.
Ridurre il recupero lento
A volte il recupero da uno snapshot può richiedere più tempo del previsto. Potresti dover intervenire per ricollegare l'applicazione a Redis il più rapidamente possibile.
In questo caso, puoi creare una nuova istanza Redis e indirizzare il traffico dell'applicazione. Una volta recuperata l'istanza originale, potrai trasferire i dati ripristinati alla nuova istanza.
Errore di snapshot ed errore di ripristino
Errore di snapshot
Eventuali snapshot non riusciti vengono segnalati a Cloud Monitoring e viene eseguito immediatamente un nuovo tentativo. Gli errori consecutivi degli snapshot aumentano la quantità di dati persi in caso di recupero perché i dati recuperati diventano sempre meno aggiornati. Per informazioni su come rilevare e risolvere i problemi relativi agli snapshot, consulta Monitoraggio degli snapshot.
Recupero non riuscito
Gli errori di recupero sono rari, ma possono verificarsi. Se si verifica un errore di recupero, l'istanza viene recuperata senza dati.
Best practice
Per ottenere i risultati migliori dal backup dell'istanza con gli snapshot RDB, devi seguire le best practice descritte di seguito:
Gestione della memoria
Gli snapshot RDB utilizzano un fork del processo e un meccanismo di "copia su scrittura" per acquisire uno snapshot dell'istanza. A seconda del pattern di scrittura nell'istanza, la memoria utilizzata dell'istanza aumenta man mano che le pagine interessate dalle scritture vengono copiate. Nel peggiore dei casi, l'impronta in 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 sull'80% della capacità dell'istanza in modo che il 20% sia riservato per l'overhead. Per scoprire di più, consulta le best practice per la gestione della memoria. Questo overhead di memoria, oltre agli snapshot di monitoraggio,
ti aiuta a gestire il tuo carico di lavoro per ottenere snapshot efficaci.
Istantanee obsolete
Il recupero dell'istanza da uno snapshot non aggiornato può causare problemi di prestazioni per la tua applicazione mentre tenta di riconciliare una quantità significativa di chiavi non aggiornate 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 riconciliare con lo snapshot, puoi disattivare e riattivare gli snapshot RDB. In questo modo vengono eliminati gli snapshot esistenti, il che ti consente di evitare di recuperare da uno snapshot obsoleto.
Per monitorare la presenza di snapshot non aggiornati, imposta un avviso sulle metriche last_status
e last_success_age degli 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 la tua istanza non è disponibile.
Se l'istanza non è disponibile e il recupero da uno snapshot richiede troppo tempo, puoi creare una nuova istanza Redis e indirizzare il traffico verso di essa. Una volta recuperata l'istanza Redis originale, puoi trasferire i dati ripristinati nella nuova istanza.
Impatto sulle prestazioni degli snapshot RDB
A seconda del pattern 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 traffico ridotto dell'istanza.
Utilizza l'ora di inizio e l'intervallo per pianificare gli snapshot per le ore richieste. Ad esempio, se il carico è molto ridotto dalle 01:00 alle 04:00, puoi impostare l'ora di inizio su 03:00 e l'intervallo su 24 ore.
Se il sistema ha un carico costante e richiede snapshot frequenti, devi valutare attentamente l'impatto sul rendimento 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 quelli non riusciti. Gli snapshot non riusciti possono indicare un'istanza sovraccaricata che potrebbe continuare a riscontrare difficoltà a recuperare dallo 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 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 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 Istantanea RDB in_progress per determinare se era in corso uno snapshot quando sono stati rilevati problemi di prestazioni.
Passaggi successivi
- Scopri di più sull'importazione e sull'esportazione dei backup.
- Segui la guida per l'esportazione di dati da un'istanza Redis.