Comprendere il backlog di replica di Redis: PSYNC, dimensioni e limiti di alta disponibilità

Il sito Backlog di replica di Redis determina se, in seguito a un’interruzione della connessione, una replica debba recuperare solo le modifiche mancanti oppure ricevere nuovamente l’intero set di dati. Chi dimensiona il buffer in base al volume effettivo di replica può evitare inutili sincronizzazioni complete. A tal fine, tuttavia, anche la cronologia delle repliche, il budget di memoria e i processi operativi devono essere coordinati: un backlog di grandi dimensioni non sostituisce né la persistenza né un solido concetto di failover.

Cosa contiene effettivamente il backlog

All'indirizzo Replica di Redis Il primario elabora le modifiche al database e trasmette un flusso continuo di comandi alle proprie repliche. Ciò non comprende solo i valori scritti direttamente dai client; anche le chiavi scadute o sovrascritte possono innescare modifiche che devono essere trasmesse. Il backlog conserva in memoria una porzione limitata e recente di questo flusso di replica. Non contiene quindi una copia completa aggiuntiva del database né costituisce un archivio di operazioni di scrittura di qualsiasi età.

In condizioni di funzionamento regolare, le repliche seguono il flusso corrente. Se una connessione viene interrotta, la cronologia sul primario continua ad aumentare. Dopo il ripristino della connessione, la replica cerca di allinearsi allo stato precedente. A quel punto è fondamentale verificare se i byte necessari siano ancora disponibili. Se così fosse e la cronologia di replica corrispondesse, Redis può colmare il divario. A tal fine non è necessario sostituire completamente i dati già presenti nella replica.

I vantaggi sono particolarmente evidenti in caso di brevi interruzioni di rete, cambi di connessione e interventi di manutenzione programmati. Una sincronizzazione completa di un ampio volume di dati richiede capacità di trasmissione e potenza di calcolo; a seconda della configurazione, si aggiungono ulteriori carichi sulla memoria e sui supporti dati. Il backlog può ridurre questo carico, ma non è in grado di compensare ogni tipo di interruzione. Un riavvio del processo o una cronologia modificata richiedono un approccio diverso rispetto a una connessione TCP interrotta per un breve periodo.

Quando è sufficiente un PSYNC e quando è necessaria una sincronizzazione completa

A Risincronizzazione parziale con PSYNC richiede due dati correlati: l’ID di replica e l’offset. L’ID identifica una specifica cronologia di dati. L’offset descrive una posizione in byte all’interno del flusso di replica. Due offset di uguale dimensione provenienti da cronologie diverse non sono quindi automaticamente comparabili. Al contrario, un leggero ritardo all’interno della stessa cronologia può già trovarsi al di fuori del backlog disponibile, se la sua capacità è limitata.

In parole semplici, al momento della riconnessione la replica comunica fino a quale punto è arrivata. Il primario verifica se è in grado di fornire i dati necessari per proseguire. Se la cronologia è sconosciuta o manca la sezione richiesta, viene generato un Sincronizzazione completa necessario. In questo modo la replica riceve un set completo di dati e, successivamente, le modifiche apportate durante la sincronizzazione. A seconda della configurazione, il trasferimento può avvenire con una fase intermedia RDB su supporto dati oppure senza tale fase intermedia.

Dopo un failover, una risincronizzazione completa non è inevitabile in ogni caso. Una replica trasferita può inoltre memorizzare l’ID di replica precedente e il relativo intervallo di offset valido. In questo modo, altre repliche possono, a determinate condizioni, allinearsi alla cronologia nota. Per la pianificazione, tuttavia, ciò non costituisce una garanzia: l’intervallo pertinente deve continuare a essere disponibile e il ricollegamento effettivo deve corrispondere agli ID memorizzati.

Misurare il tasso di replica anziché stimare le dimensioni del database

La semplice mole dei dati è sufficiente per Dimensionamento del backlog non è sufficiente. Un database di grandi dimensioni, utilizzato prevalentemente per la lettura, può generare un traffico di replica limitato. Una cache di piccole dimensioni con valori che cambiano frequentemente e molti eventi di scadenza, invece, può trasferire continuamente notevoli quantità di dati. Anche un numero fisso di operazioni al secondo descrive in modo insufficiente la memoria necessaria: piccole modifiche alle chiavi e grandi sovrascritture di valori non generano lo stesso volume di byte.

Un’approssimazione utilizzabile nella pratica si ricava dall’incremento temporale di master_repl_offset. Rileva il valore due volte sullo stesso primario e dividi la differenza per i secondi trascorsi. Verifica anche l’ID di replica. Dopo un cambio di ruolo o un riavvio, non devi semplicemente sottrarre tra loro due punti di misurazione non correlati. Inoltre, un singolo intervallo di misurazione fornisce solo una frequenza media all’interno di quell’intervallo, non un limite massimo garantito in modo permanente.

La query seguente legge le informazioni di diagnostica. Non modifica alcuna configurazione di Redis. Eseguila utilizzando le opzioni di connessione e autenticazione richieste dal tuo ambiente. La chiamata riportata di seguito utilizza la connessione predefinita di redis-cli; è necessario impostare espressamente un altro host, porta o accesso TLS.

redis-cli INFO replication

Effettua misurazioni nelle diverse fasi di carico, ad esempio durante le normali attività quotidiane, in caso di importazioni e durante i ricarichi della cache su larga scala. Documenta sia i valori tipici che i brevi picchi. Se si verificano molte modifiche dovute alla scadenza delle chiavi, l’articolo interno può essere utile per approfondire l’argomento. Analisi della scadenza delle chiavi Redis. Questo nesso è importante ai fini della pianificazione, poiché non tutti gli spunti di scrittura rilevanti derivano direttamente da una nuova richiesta dell'utente.

Calcolare in modo trasparente l'entità del backlog

Come Approssimazione di progettazione puoi moltiplicare la frequenza di replica pertinente per la durata dell'interruzione da colmare e poi aggiungere una riserva adeguata. La durata non dovrebbe tenere conto solo dell'interruzione effettiva della rete. Anche il rilevamento, i tentativi di ricollegamento e il ripristino del percorso di connessione possono richiedere tempo. Quale riserva sia adeguata dipende dalle fluttuazioni osservate e dall'obiettivo operativo desiderato, non da una percentuale universale.

Un esempio di calcolo volutamente semplificato: per una fase di carico considerata, si ipotizzano 12 MiB al secondo. La connessione potrebbe essere assente per 90 secondi; si prevedono altri 30 secondi come riserva di tempo. Ne conseguono 12 MiB/s × 120 s = 1.440 MiB, ovvero circa 1,41 GiB. Questi numeri sono valori ipotetici forniti a titolo illustrativo e non costituiscono un benchmark di Redis. Prima di un'implementazione in produzione, devono essere sostituiti dai valori effettivi rilevati dalla tua applicazione.

Il calcolo inverso aiuta a valutare la capacità di un buffer esistente. Un backlog completamente pieno di 256 MiB corrisponde, a una velocità costante di 12 MiB al secondo, a circa 21 secondi di cronologia. A una velocità di 2 MiB al secondo, sarebbero circa 128 secondi. In un'applicazione reale, tuttavia, le velocità variano. Tale intervallo rappresenta quindi un'istantanea e non una garanzia che ogni evento di questa durata possa essere parzialmente sincronizzato.

Verifica inoltre se, una volta ristabilita la connessione, la replica riesca a recuperare il ritardo più velocemente di quanto ne vengano generate di nuove. Aumentare la cronologia non risolve né il problema di una rete costantemente troppo lenta né quello di un destinatario costantemente sovraccarico. Se il ritardo persiste o continua ad aumentare, è necessario individuarne la causa. Limitarvisi ad aumentare la memoria disponibile non fa altro che rimandare il problema e può mettere a dura prova l'intero sistema in termini di memoria.

Modificare la configurazione di Redis in modo chiaro e controllato

I parametri repl-backlog-size e repl-backlog-ttl controllano aspetti diversi. Il primo descrive la dimensione prevista del backlog. Il secondo determina, sul server primario, dopo quanto tempo senza repliche connesse il backlog possa essere rilasciato. Esso è nessuna durata massima di interruzione per PSYNC. Finché il buffer viene sovrascritto o manca un altro requisito, un TTL lungo da solo non è sufficiente.

Le righe seguenti sono impostazioni commentate tratte dal modello di configurazione di Redis 7.2.0. I simboli di commento sono stati mantenuti intenzionalmente. La semplice copia di queste righe non attiva alcuna impostazione; inoltre, i valori indicati non costituiscono una raccomandazione generale in termini di capacità per i sistemi di produzione.

# Redis 7.2.0: auskommentierte Vorgaben aus redis.conf
# repl-backlog-size 1mb
# repl-backlog-ttl 3600

Con repl-backlog-ttl 0 la abilitazione temporizzata viene disattivata dopo la disconnessione di tutte le repliche. Ciò non garantisce la conservazione di una cronologia illimitata: il buffer esistente può comunque essere sovrascritto da nuovi dati di replica. Inoltre, ciò non garantisce la persistenza in caso di eventuali riavvii del processo. Valuta quindi attentamente se il consumo di memoria aggiuntivo è compatibile con il comportamento di riconnnessione previsto.

Prima di apportare una modifica, dovresti verificare i valori effettivamente in vigore e chiarire la procedura di distribuzione. Una variabile d'ambiente del container, un file di configurazione gestito e un'impostazione modificata in fase di esecuzione non sono la stessa cosa. Se in seguito viene ricreata un'istanza, solo le modifiche apportate in fase di esecuzione potrebbero andare perse. Le seguenti query sono di sola lettura; richiedono comunque i diritti di accesso appropriati.

redis-cli CONFIG GET repl-backlog-size
redis-cli CONFIG GET repl-backlog-ttl

Con Managed Redis, il fornitore può limitare l'accesso a CONFIG limitare o gestire le impostazioni tramite un'interfaccia dedicata. Questo non è un motivo per aggirare i meccanismi di protezione. Utilizza quindi i canali di gestione autorizzati e documenta la dimensione scelta insieme al volume di replica sottostante. Nel piano di modifica dovrebbero inoltre essere riportati i valori precedenti e un percorso di ritorno realistico.

Monitoraggio: quali valori vanno considerati insieme

Per la Monitoraggio della replica di Redis Un singolo indicatore verde dello stato della connessione non è sufficiente. Una connessione può essere stata ripristinata mentre la replica sta ancora recuperando il ritardo o sta caricando un set completo di dati. Al contrario, una breve interruzione della connessione non deve necessariamente essere considerata critica se la cronologia e la capacità di recupero sono sufficienti. Valuta quindi congiuntamente la connessione, lo stato di sincronizzazione, l’andamento dell’offset e la cronologia disponibile.

I campi di una INFO-Le risposte possono variare a seconda delle versioni di Redis e tra primario e replica. Un’analisi dovrebbe quindi trattare espressamente i campi mancanti, anziché interpretarli tacitamente come nulli o come uno stato privo di errori. Anche le denominazioni master e slave per motivi di compatibilità continuano a comparire nei nomi dei campi; non devono essere tradotti liberamente nel codice eseguibile.

Per l'interpretazione del ritardo, si fa riferimento alla guida interna Analisi dell'offset di replica di Redis un complemento adeguato. Nel monitoraggio continuo dovresti considerare l'andamento storico, non solo due valori rilevati manualmente. Una distanza crescente richiede una reazione diversa rispetto a un divario che si riduce costantemente dopo un breve crollo.

Gli allarmi efficaci devono essere in linea con i tuoi obiettivi operativi: per quanto tempo una replica può rimanere irraggiungibile? Entro quanto tempo deve recuperare il ritardo? Qual è la frequenza insolita delle sincronizzazioni complete? I valori limite rigidi, senza alcun riferimento al profilo di carico e al volume dei dati, spesso generano segnalazioni inutili o trascurano effettivi peggioramenti. Oltre alle metriche di replica, tieni sotto controllo anche l’utilizzo della RAM, il carico di rete e gli indizi relativi ai riavvii dei processi.

Come valutare correttamente il budget di archiviazione e le repliche lente

Il backlog è solo una parte del totale Requisiti di memoria di Redis. A ciò si aggiungono il volume dei dati, le strutture amministrative, i buffer dei client e, a seconda delle condizioni operative, memoria aggiuntiva durante le operazioni di persistenza o sincronizzazione. Pertanto, non destinare l’intera memoria di lavoro disponibile ai dati utente più un backlog calcolato con precisione. La riserva necessaria deve essere determinata in base all’ambiente specifico e ai picchi di carico che vi si verificano.

A partire da Redis 7.0, il buffer di replica e il backlog di replica condividono la memoria. La documentazione INFO sottolinea quindi, tra l’altro, che mem_clients_slaves può essere pari a zero se i buffer di replica non superano la capacità del backlog. Ciò non significa però che la replica non occupi memoria. Considera i valori previsti a tale scopo come mem_replication_backlog e mem_total_replication_buffers nel contesto e non sommare ciecamente le grandezze che si sovrappongono.

Un errore diagnostico comune consiste nel considerare ogni sincronizzazione interrotta come il risultato di un accumulo di dati in sospeso. Repliche lente, larghezza di banda di rete limitata o limiti del buffer di output superati possono avere altre cause. Il parametro client-output-buffer-limit replica si riferisce alla classe client in questione e non deve essere confusa con repl-backlog-size devono essere considerati equivalenti. Prima di modificare i limiti, controlla i log, la documentazione relativa alle versioni e le possibili ripercussioni sulle altre connessioni.

Perché un backlog consistente non garantisce ancora un’elevata disponibilità

Il backlog migliora il ripristino della connessione, ma non rende la replica, di default asincrona, priva di perdite. Un primario può aver già confermato un'operazione di scrittura al client prima che una replica l'abbia elaborata. Se il primario si guasta in questo lasso di tempo, l'operazione in questione potrebbe non essere presente sul sistema di riserva selezionato in seguito. La dimensione del buffer da sola non risolve questo Rischio di perdita dei dati in caso di failover no.

Anche WAIT non trasforma una topologia Redis in un sistema con forte coerenza garantita. Il comando può attendere le conferme dalle repliche; l'effettiva sicurezza dei dati continua a dipendere da ulteriori fattori, in particolare dal comportamento in termini di persistenza e failover. Allo stesso modo, limitano min-replicas-to-write e min-replicas-max-lag accettare nuove operazioni di scrittura alle rispettive condizioni, senza salvare automaticamente e in modo permanente ogni singola operazione su più istanze.

Per Alta disponibilità È quindi necessario definire una strategia coerente che comprenda: perdita di dati tollerabile, tempo di inattività ammissibile, persistenza, rilevamento dei guasti, selezione del nuovo primario e ripristino. Sentinel o Redis Cluster possono assumere compiti diversi rispetto al backlog. Chi si limita ad aumentare la dimensione di un buffer lasciando invariate tutte le altre ipotesi non dispone ancora di un piano di ripristino affidabile.

Testare le modifiche e individuare i problemi ricorrenti

Avvia un test controllato in un ambiente isolato con una versione di Redis comparabile e un carico di scrittura tracciabile. Prima dell’interruzione, registra gli ID di replica, gli offset, lo stato del backlog e l’utilizzo della memoria. Simula quindi un'interruzione limitata della connessione, senza modificare firewall o processi di produzione non verificati. Dopo il ripristino della connessione, osserva se avviene una sincronizzazione parziale o completa e quanto tempo richiede il recupero.

Per ogni prova, modifica, per quanto possibile, solo una variabile rilevante. Se il backlog, il carico di scrittura e le condizioni di rete cambiano contemporaneamente, è difficile attribuire l’effetto a una causa specifica. Ripeti la prova con durate di interruzione diverse e diverse fasi di carico. In questo modo, da una singola riconnessione riuscita si ottiene una valutazione comprensibile del comportamento. I limiti osservati dovrebbero essere documentati, senza però dedurne una garanzia per ogni futuro malfunzionamento.

In caso di risincronizzazioni complete ripetute, verifica innanzitutto se la cronologia è effettivamente compatibile. Successivamente, controlla i byte ancora presenti, il tempo trascorso senza replica, le indicazioni relative ai riavvii e la velocità effettiva di recupero. Un buffer troppo piccolo è una possibile causa, ma non l’unica. È particolarmente importante distinguere tra un’interruzione una tantum troppo lunga e una replica che rimane costantemente in ritardo anche in presenza di una connessione attiva.

L'impostazione corretta è, in definitiva, quella che copre la finestra di inattività da te definita con un carico realistico e lascia memoria sufficiente per il resto del funzionamento. Registra insieme la base di riferimento delle misurazioni, la fonte di configurazione e la data della verifica. Dopo modifiche significative al comportamento di scrittura, alla topologia o alla versione di Redis, è necessario riesaminare il dimensionamento. In questo modo, il backlog rimane una decisione operativa fondata anziché un valore adottato una volta per tutte.