Best Practices for Preventing Data Loss: RDB vs. AOF Configuration

La persistenza di Redis è facile da fraintendere perché Redis sembra un database ma si comporta prima di tutto come memoria. Se lo riavvii senza persistenza, i dati vengono persi. Se la persistenza è abilitata ma configurata con noncuranza, potresti comunque perdere scritture recenti, bloccare i client durante la pressione del disco o scoprire durante un'interruzione che l'unica copia dei tuoi dati risiede sullo stesso volume guasto del processo Redis.

La giusta strategia per la perdita di dati Redis inizia con una domanda onesta: cosa succede se le ultime scritture di secondi, minuti o ore scompaiono? Una cache di pagine prodotto può di solito essere ricostruita. Un archivio di sessioni può infastidire gli utenti ma non distruggere l'attività. Una coda, un registro di limitazione della velocità, un archivio carrello o un archivio di flag di funzionalità potrebbero richiedere una durabilità molto più stretta. RDB e AOF sono i due strumenti che Redis ti offre e risolvono diverse parti di quel problema.

Understanding Redis Persistence Mechanisms

Redis ha due modalità principali di persistenza:

RDB snapshots

RDB scrive un'istantanea puntuale del dataset su disco, di solito come dump.rdb. Redis crea un processo figlio, il figlio serializza il dataset e il genitore continua a servire i client. Questo rende RDB utile per backup, repliche e riavvii rapidi, ma ha un chiaro compromesso: tutto ciò che viene scritto dopo l'ultimo snapshot riuscito può essere perso se il processo o l'host fallisce.

Le impostazioni tipiche di RDB assomigliano a queste:

save 900 1       # Salva dopo 15 minuti se almeno 1 chiave è cambiata
save 300 10      # Salva dopo 5 minuti se almeno 10 chiavi sono cambiate
save 60 10000    # Salva dopo 1 minuto se almeno 10000 chiavi sono cambiate
dbfilename dump.rdb
dir /var/lib/redis

Quelle righe save non sono una promessa che Redis salverà esattamente secondo quella pianificazione. Sono regole di attivazione: se durante l'intervallo sono cambiate abbastanza chiavi, Redis avvia un salvataggio in background. Se il disco è lento, il dataset è enorme o l'host ha poca memoria, il salvataggio in background può fallire o creare latenza a causa della pressione di fork e copy-on-write.

RDB è più forte quando vuoi snapshot compatti e un comportamento di ripristino rapido. È più debole quando la tua tolleranza alla perdita di dati recenti è bassa.

AOF logging

AOF, o persistenza su file append-only, registra i comandi di scrittura in modo che Redis possa riprodurli al riavvio. Di solito offre una migliore durabilità rispetto a RDB perché può scaricare le scritture più spesso di una pianificazione di snapshot. Il compromesso è più I/O su disco, file più grandi prima della riscrittura e talvolta un avvio più lento se Redis deve riprodurre un log di grandi dimensioni.

Le impostazioni principali sono:

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

La riga importante è appendfsync. Con everysec, Redis chiede al sistema operativo di scaricare l'AOF circa una volta al secondo. In un normale crash del processo Redis, questo di solito limita la perdita a circa l'ultimo secondo di scritture. In un crash completo dell'host o un guasto dello storage, la perdita esatta dipende dal sistema operativo, dal filesystem, dalla cache del disco e dal comportamento dello storage, quindi non descriverlo come una garanzia matematica.

appendfsync always scarica dopo ogni scrittura ed è molto più costoso. Può essere appropriato per un piccolo deployment Redis critico con volume di scrittura modesto, ma può danneggiare gravemente la latenza sotto traffico reale. appendfsync no lascia che sia il sistema operativo a decidere quando scaricare; è veloce, ma ti dà una finestra di perdita molto più ampia e meno prevedibile.

Best Practices for Data Loss Prevention

Use both only when you understand which file Redis will load

Molti deployment Redis in produzione abilitano sia RDB che AOF. Questa è un'impostazione predefinita sensata quando Redis memorizza dati che sarebbero dolorosi da ricostruire. RDB ti fornisce artefatti di backup compatti. AOF ti fornisce una finestra di perdita recente più piccola.

Usa una configurazione come questa:

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Un dettaglio è importante durante il ripristino: quando AOF è abilitato, Redis normalmente carica i dati AOF all'avvio perché ci si aspetta che siano più completi dello snapshot RDB. Non dare per scontato che Redis caricherà prima RDB e poi ricadrà su AOF. Testa il percorso di ripristino per la tua versione di Redis e la disposizione del deployment, specialmente sulle versioni di Redis che utilizzano il nuovo formato AOF multi-parte.

Pick appendfsync from the loss window backward

Inizia con l'impatto aziendale, non con l'impostazione di Redis.

Se Redis è una cache usa e getta, RDB da solo può essere sufficiente, o anche nessuna persistenza se la tua applicazione si ripopola in sicurezza. Se Redis contiene sessioni, appendfsync everysec è spesso un equilibrio pratico. Se Redis fa parte di un flusso di lavoro in cui la perdita di scritture riconosciute crea danni aziendali reali, la sola persistenza di Redis potrebbe non essere il confine di durabilità giusto. Potresti aver bisogno di un database primario, una coda durevole o un comportamento di write-ahead a livello di applicazione al di fuori di Redis.

Per la maggior parte degli usi operativi di Redis, inizia con:

appendonly yes
appendfsync everysec

Poi osserva la latenza, il tempo di scrittura su disco, il comportamento di riscrittura AOF e il tempo di riavvio prima di decidere se spostarti verso always o allontanarti da AOF.

Keep RDB snapshots, but do not make them too aggressive

Salvataggi RDB frequenti riducono la quantità di dati persi tra gli snapshot, ma aumentano anche la frequenza dei fork. Forkare un grande processo Redis può essere costoso e le scritture durante il salvataggio del figlio creano pressione sulla memoria copy-on-write. Se la tua istanza Redis ha un dataset di 40 GB e il tasso di scrittura è alto, salvare ogni minuto potrebbe creare una peggiore affidabilità perché l'host passa troppo tempo sotto pressione di memoria e disco.

Regole di salvataggio RDB ragionevoli dipendono dal tasso di scrittura e dalle aspettative di recupero. Una piccola cache può fare snapshot spesso senza problemi. Un grande archivio di sessioni potrebbe aver bisogno di meno snapshot RDB più AOF per la durabilità recente. Osserva INFO persistence, i log di Redis e la memoria dell'host durante BGSAVE, non solo il file di configurazione di Redis.

Treat AOF rewrite as normal maintenance, not an emergency

I file AOF crescono perché registrano le scritture. Redis li riscrive in una rappresentazione compatta in background. I valori predefiniti sono spesso un punto di partenza decente:

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

Ciò significa che Redis considera la riscrittura quando l'AOF è cresciuto significativamente rispetto alla dimensione dopo la riscrittura precedente, una volta che ha raggiunto almeno la dimensione minima. Se le riscritture avvengono costantemente, aumenta la dimensione minima o indaga su un modello di scrittura rumoroso. Se l'AOF cresce per molto tempo senza riscrittura, controlla i log, lo spazio su disco e INFO persistence.

Puoi attivare una riscrittura manualmente:

redis-cli BGREWRITEAOF

Fallo durante un periodo tranquillo se possibile. Una riscrittura è più sicura che lasciare che il file cresca per sempre, ma consuma comunque CPU, larghezza di banda del disco e memoria copy-on-write.

Back up the persistence files somewhere else

La persistenza non è un backup. I file di persistenza sullo stesso host ti proteggono da un riavvio del processo Redis. Non ti proteggono da un disco perso, una cancellazione accidentale, un deploy errato che sovrascrive la directory dei dati o un errore dell'operatore che esegue FLUSHALL.

Copia i file RDB e AOF in uno storage separato. Se usi snapshot del filesystem o snapshot di volume cloud, testa il ripristino su un'istanza separata. Per le copie RDB, preferisci copiare un file di snapshot completato piuttosto che un file in fase di scrittura. Per AOF, comprendi la disposizione del file per la tua versione di Redis prima di creare script di backup basati sui nomi dei file.

Watch the signals that predict data loss

Il comando utile durante un incidente è:

redis-cli INFO persistence

Cerca salvataggi in background falliti, stato della riscrittura AOF, ora dell'ultimo salvataggio e indicatori di fsync ritardato. Abbina questo alle metriche dell'host: latenza del disco, spazio libero su disco, margine di memoria ed eventi OOM del kernel. Se BGSAVE fallisce per ore e nessuno se ne accorge, la configurazione di Redis può sembrare sicura mentre il punto di recupero effettivo diventa sempre più vecchio.

Use replication or Sentinel for availability, not as your only backup

Repliche, Redis Sentinel e Redis Cluster aiutano con la disponibilità. Non risolvono automaticamente ogni problema di perdita di dati. Una scrittura errata, una cancellazione accidentale o un bug dell'applicazione possono replicarsi rapidamente. Il failover può anche promuovere una replica a cui mancano scritture recenti se esiste lag di replica. Mantieni persistenza, backup e test di ripristino nel progetto.

La configurazione pratica per molti team è AOF con appendfsync everysec, snapshot RDB a una cadenza ragionevole, backup esterni, monitoraggio dei guasti di persistenza e un runbook di ripristino testato. Redis può essere affidabile in questa forma, ma solo se tratti la persistenza come un sistema operativo invece di una casella da spuntare.