Risoluzione dei Problemi di Ritardo di Replica in MongoDB: Cause e Soluzioni

Il ritardo di replica in MongoDB di solito inizia come un piccolo fastidio operativo. Un grafico inizia a salire. Un secondario resta indietro di 15 secondi, poi di 2 minuti. Qualcuno chiede se le letture sono obsolete. Qualcun altro suggerisce di riavviare il nodo. Prima di farlo, rallenta e capisci quale parte della replica sta perdendo terreno.

I secondari di MongoDB copiano le operazioni dall'oplog del primario e le applicano localmente. Il ritardo di replica significa che un secondario non ha applicato le operazioni così recentemente come il primario. Ciò può influenzare le letture secondarie, i backup presi dai secondari, i lavori di analisi e il failover. Può anche nascondere un rischio maggiore: se il secondario resta indietro più della finestra dell'oplog, potrebbe non essere in grado di recuperare dall'oplog.

Il percorso di risoluzione più rapido è rispondere a tre domande:

• Ogni secondario è in ritardo, o solo uno?
• Il ritardo è temporaneo, costante o in crescita?
• Il secondario è ancora all'interno della finestra dell'oplog?

Queste risposte decidono cosa fare dopo.

Misura il Ritardo Senza Indovinare

Inizia in mongosh:

rs.status()

Trova il primario e confronta il suo optimeDate con quello di ogni secondario. Cerca anche membri non sani, messaggi di heartbeat e membri bloccati in stati come RECOVERING o STARTUP2.

Per un riepilogo più amichevole, esegui:

rs.printSecondaryReplicationInfo()

Alcuni materiali più vecchi usano rs.printSlaveReplicationInfo(). Se mantieni sistemi più vecchi, potresti ancora vedere quell'aiuto. La dicitura moderna è "secondary".

Poi controlla la finestra dell'oplog:

rs.printReplicationInfo()

La finestra dell'oplog è la quantità di storia attualmente conservata nell'oplog. Se il tuo secondario è in ritardo di 40 minuti e la finestra dell'oplog è di diversi giorni, hai spazio per risolvere. Se il tuo secondario è in ritardo di 40 minuti e la finestra dell'oplog è di 1 ora durante il traffico di punta, sei vicino a una situazione di ricostruzione.

Non affidarti solo a valori come SecondsBehind da un singolo strumento. Skew dell'orologio, membri ritardati e brevi picchi possono rendere un numero fuorviante. Confronta l'output dello stato con i grafici di monitoraggio per volume di scrittura, latenza del disco, CPU e throughput di rete.

Se Tutti i Secondari Sono in Ritardo

Quando ogni secondario resta indietro più o meno nello stesso momento, la causa è di solito a monte di un singolo secondario. Guarda prima il carico di lavoro di scrittura del primario.

I trigger comuni includono:

• Importazioni bulk o backfill.
• Grandi operazioni updateMany o deleteMany.
• Pulizia TTL dopo un periodo di arretrato.
• Deploy dell'applicazione che hanno cambiato il volume di scrittura.
• Costruzioni di indici o manutenzione dello schema.
• Un improvviso aumento di piccole scritture che creano molte voci nell'oplog.

Chiedi cosa è cambiato nello stesso momento in cui è iniziato il ritardo. Un picco che inizia esattamente quando inizia un lavoro notturno raramente è un mistero di MongoDB.

Sul primario, ispeziona le operazioni attive:

db.currentOp({ active: true })

Se trovi un lavoro batch, considera di limitarlo invece di lasciarlo finire alla massima velocità. Ad esempio, elabora i documenti in intervalli di _id, dormi tra i batch e guarda il ritardo. Questo è particolarmente utile per lavori di pulizia dove finire in 30 minuti è meno importante che mantenere sano il set di replica.

Se il volume di scrittura sostenuto è semplicemente più alto di quanto il set di replica possa gestire, hai bisogno di un cambiamento di capacità o architettura. Dischi migliori, più CPU, una classe di istanza diversa, ottimizzazione del percorso di scrittura o sharding potrebbero essere la risposta giusta. Cambiare la preferenza di lettura non risolverà un primario che produce più lavoro di quanto il set possa applicare.

Se Solo Un Secondario È in Ritardo

Un secondario in ritardo di solito indica un problema locale. Accedi a quell'host e controlla le basi:

iostat -xz 1
vmstat 1
top

All'interno di MongoDB, usa:

mongostat --host secondary.example.com:27017
mongotop --host secondary.example.com:27017

Il disco è un colpevole comune. Un secondario che usa storage più lento del primario può andare bene durante il traffico normale e poi restare indietro durante i picchi. I volumi cloud possono anche raggiungere i limiti di throughput o IOPS. Cerca alta utilizzazione, tempi di attesa elevati e code.

La CPU può essere importante quando il carico di lavoro include molti aggiornamenti, compressione, crittografia o traffico di query pesante sullo stesso membro. La pressione della memoria è importante quando il secondario non può mantenere dati caldi e indici in cache mentre applica le scritture.

Controlla anche cosa altro gira sull'host. Backup, scansioni antivirus, snapshot del filesystem, compressione dei log e query di reporting possono competere con la replica. Se il nodo in ritardo è anche il "posto sicuro" dove tutti eseguono analisi ad-hoc, probabilmente hai trovato il problema.

Le Letture sui Secondari Possono Creare Ritardo

Le letture secondarie non sono gratuite. Usano la stessa cache, CPU e disco di cui la replica ha bisogno. Una singola aggregazione che scansiona una grande collezione può essere sufficiente per far restare indietro un secondario durante un periodo di attività.

Cerca letture di lunga durata:

db.currentOp({ active: true })

Se l'applicazione invia letture ai secondari, rivedi la preferenza di lettura. secondary può forzare letture su membri in ritardo. secondaryPreferred può ancora restituire dati obsoleti. Per flussi utente che devono leggere le proprie scritture, usa il primario. Per letture eventualmente consistenti, imposta maxStalenessSeconds in modo che il driver eviti secondari troppo indietro.

Per carichi di lavoro di reporting, considera un secondario nascosto o una pipeline di analisi separata. I membri nascosti possono ancora replicare, ma i driver non li sceglieranno per letture normali. Questo li rende un posto migliore per backup o lavori di reporting controllati, purché li dimensioni correttamente.

La Dimensione dell'Oplog È un Margine di Recupero, Non una Soluzione di Velocità

Un oplog troppo piccolo di solito non causa ritardo da solo. Rende il ritardo pericoloso. Se un secondario resta indietro e le voci dell'oplog necessarie vengono sovrascritte, non può recuperare normalmente.

La tua finestra dell'oplog dovrebbe essere più lunga dei tuoi scenari realistici di outage e manutenzione. Se un secondario può essere offline per 6 ore durante la patch, una finestra dell'oplog di 4 ore non è sufficiente. Se un'importazione trimestrale consuma l'oplog in poche ore, dimensiona per quel carico di lavoro o cambia come viene eseguita l'importazione.

Sulle versioni supportate, ridimensiona con replSetResizeOplog su ogni membro che necessita di un oplog più grande:

use admin
db.adminCommand({ replSetResizeOplog: 1, size: 20480 })

Questo esempio richiede circa 20 GB. Nelle piattaforme gestite, usa il metodo di configurazione gestito. Evita vecchi consigli che eliminano e ricreano l'oplog a meno che tu non stia seguendo una procedura di recupero attentamente testata.

Dopo aver aumentato l'oplog, continua a risolvere il ritardo sottostante. Un oplog più grande ti dà più tempo; non rimuove la saturazione del disco, i limiti di rete o i picchi eccessivi di scrittura.

Controlli di Rete Che Aiutano Davvero

I problemi di rete sono più probabili quando il ritardo colpisce un secondario remoto, una zona di disponibilità o un percorso del data center. Inizia semplice:

ping primary.example.com
traceroute primary.example.com

Poi guarda oltre la latenza. La replica ha bisogno di throughput affidabile. Perdita di pacchetti, ispezione del firewall, limiti VPN, limiti di larghezza di banda cross-regione o interfacce di rete sovraccaricate possono creare ritardo anche quando il ping sembra accettabile.

Se solo il membro cross-regione è in ritardo, confrontalo con un secondario locale sotto lo stesso carico di scrittura. Potresti aver bisogno di una topologia diversa, un collegamento più grande o un'aspettativa più chiara che i membri remoti siano per il disaster recovery piuttosto che per letture fresche.

Deriva dei Dati e degli Indici

I membri del set di replica dovrebbero avere gli stessi indici. Se non è così, l'applicazione dell'oplog può rallentare o fallire. Questo di solito deriva da modifiche manuali, manutenzione fallita o un membro ripristinato da una fonte incoerente.

Confronta gli indici sulle collezioni calde:

db.orders.getIndexes()

Eseguilo sul primario e sul secondario in ritardo. Se le definizioni differiscono, correggi la deriva deliberatamente. Ricostruire un grande indice può aggiungere più carico, quindi programmalo attentamente o ricostruisci il membro da una fonte pulita se le differenze sono diffuse.

La divergenza dei dati è più seria. Se gli errori di replica mostrano record mancanti o chiavi duplicate, il ritardo non è più l'unico problema. Devi ispezionare l'errore, confrontare i dati e decidere se una riparazione a livello di tabella, una risincronizzazione o una ricostruzione completa sia la via più sicura.

Sii Cauto con Riavvii e Sincronizzazione Iniziale

Riavviare un secondario in ritardo a volte aiuta se il processo è bloccato dietro un problema transitorio. Non è una soluzione universale. Se il membro è vicino al bordo della finestra dell'oplog, un riavvio può costare abbastanza tempo da spingerlo in uno stato irrecuperabile.

Prima di riavviare, controlla:

• Ritardo corrente.
• Finestra dell'oplog corrente.
• Se il membro sta sincronizzando.
• Se esistono altri secondari sani.
• Se il set di replica può tollerare che il membro sia giù.

La sincronizzazione iniziale è la risposta pulita quando un secondario non può recuperare o i suoi dati non sono affidabili. È anche pesante. Copia dati, costruisce indici e consuma risorse da un altro membro. Ricostruisci un membro alla volta e assicurati che la tua configurazione di voto supporti ancora elezioni sicure mentre il nodo si sta ricostruendo.

Quando Non Dovresti Affrettarti a Risolvere

Un po' di ritardo è previsto durante il lavoro controllato. Se stai eseguendo un backfill pianificato, ripristinando un secondario o importando dati storici, la domanda utile è se il secondario sta recuperando a un ritmo accettabile. Un grafico del ritardo che sale per 20 minuti e poi scende costantemente potrebbe non aver bisogno di intervento. Un grafico del ritardo che sale ogni giorno e non torna mai alla linea di base, sì.

Questa distinzione è importante perché alcune soluzioni sono dirompenti. Uccidere un lavoro batch può lasciare i dati dell'applicazione mezzo aggiornati. Riavviare un secondario può costare calore della cache e rendere il recupero più lento. Ricostruire un membro può consumare più rete e disco che semplicemente lasciarlo applicare l'arretrato.

Per lavori pianificati, imposta un budget di ritardo prima che il lavoro inizi. Ad esempio, potresti decidere che un backfill di manutenzione può creare fino a 10 minuti di ritardo su un secondario di reporting, ma non su un candidato al failover. Guarda il ritardo, la finestra dell'oplog e il tasso di scrittura mentre il lavoro gira. Se il lavoro si avvicina al budget, mettilo in pausa o riduci la dimensione del batch.

Aiuta anche separare le repliche rivolte agli utenti dalle repliche di manutenzione. Un secondario usato per letture dell'applicazione dovrebbe avere una tolleranza al ritardo più stretta di un membro nascosto usato per i backup. Se ogni secondario ha un lavoro diverso, le soglie di allerta dovrebbero riflettere quei lavori invece di usare un numero per l'intero set.

Cosa Registrare Durante un Incidente

Gli incidenti di replica sono molto più facili da capire dopo il fatto se salvi le prove giuste. Prima di cambiare configurazione, cattura:

rs.status()
rs.conf()
rs.printReplicationInfo()
rs.printSecondaryReplicationInfo()

Salva anche le metriche a livello di host dal primario e dal secondario in ritardo: latenza del disco, CPU, memoria e throughput di rete. Se un lavoro batch o un deploy era in esecuzione, registra il suo orario di inizio e il comando o la versione del rilascio.

Questa non è burocrazia fine a se stessa. Senza una timeline, il prossimo incidente parte da zero. Con una timeline, potresti notare che il ritardo segue sempre un'esportazione, un backup o un'attività di pulizia specifica. Questo trasforma un vago problema di database in un problema di capacità programmabile.

Una Mappa Pratica di Soluzioni

Usa il sintomo per scegliere la prossima mossa:

Sintomo	Area probabile	Prossima azione
Tutti i secondari in ritardo durante lavoro batch	Picco di scrittura	Limita o suddividi il lavoro
Un secondario è sempre in ritardo	Problema di risorse locali	Controlla disco, CPU, memoria e letture locali
Il ritardo cresce solo sul membro remoto	Rete/topologia	Controlla throughput, perdita di pacchetti e design cross-regione
Il ritardo è vicino alla finestra dell'oplog	Rischio di recupero	Aumenta l'oplog e riduci la fonte del ritardo
Il secondario serve letture obsolete	Preferenza di lettura	Usa il primario per letture fresche o imposta maxStalenessSeconds
Il membro non può recuperare dopo un downtime	Storia dell'oplog mancante	Ricostruisci da backup o sincronizzazione iniziale

Una buona risoluzione dei problemi di replica MongoDB è per lo più osservazione disciplinata. Scopri se il primario sta producendo troppo lavoro, il secondario sta applicando troppo lentamente o il collegamento tra loro è limitato. Poi cambia la cosa che sta effettivamente limitando la replica invece di applicare un riavvio generico, una risincronizzazione o una modifica di configurazione.