Diagnosticare e Risolvere i Problemi Comuni di Ritardo di Replica di MongoDB

Il ritardo di replica di MongoDB non è solo un numero su un pannello di controllo. Cambia il modo in cui la tua applicazione si comporta. Un utente aggiorna un profilo, un'altra richiesta legge da un secondario e il vecchio valore ritorna. Un nodo fallisce, ma il miglior secondario è ancora indietro, quindi il failover richiede più tempo del previsto. Una query di reporting finisce sul membro sbagliato e improvvisamente il set di replica sembra sano tranne che per un secondario che continua ad allontanarsi dal primario.

Il modo utile di pensare al ritardo di replica è semplice: il primario produce voci oplog più velocemente di quanto uno o più secondari possano recuperarle e applicarle. La soluzione dipende da quale lato di quella frase è vero nel tuo ambiente. A volte il primario scrive troppo a raffiche. A volte il secondario è sottodimensionato. A volte la rete è lenta. A volte il ritardo è intenzionale perché il membro è configurato con secondaryDelaySecs. Il tuo primo compito è separare questi casi prima di apportare modifiche.

Inizia con la Forma Effettiva del Ritardo

Non iniziare ridimensionando l'oplog o riavviando mongod. Prima scopri se il ritardo è costante, a picchi, limitato a un membro o che colpisce ogni secondario.

In mongosh, inizia con:

rs.status()

Guarda stateStr, optimeDate, lastHeartbeatMessage e i campi di salute di ogni membro. Se un secondario è indietro e gli altri sono aggiornati, probabilmente hai un problema specifico del membro: disco, CPU, letture locali, manutenzione locale o un percorso di rete difettoso. Se ogni secondario è indietro, guarda più attentamente al volume di scrittura del primario, alla larghezza di banda di rete in uscita dal primario o a un'operazione insolitamente grande.

Per un controllo rapido della finestra oplog, esegui:

rs.printReplicationInfo()

La finestra oplog ti dice quanto tempo è coperto dall'oplog corrente. Non dice che la replica è sana. Dice quanto indietro può essere un secondario prima di rischiare di aver bisogno di una sincronizzazione iniziale. Se la tua finestra oplog è di 6 ore e le tue finestre di manutenzione richiedono abitualmente 8 ore, hai un vero rischio operativo anche quando il ritardo corrente è zero.

Per i secondari, anche questo è utile:

rs.printSecondaryReplicationInfo()

Negli esempi più vecchi potresti vedere rs.printSlaveReplicationInfo(). La nuova terminologia usa "secondary", ma i vecchi helper della shell e i vecchi post del blog potrebbero ancora usare "slave". I campi contano più del nome.

Se vuoi un piccolo script per una shell live, confronta l'optime del primario con ogni secondario:

const status = rs.status();
const primary = status.members.find(m => m.stateStr === "PRIMARY");

status.members
  .filter(m => m.stateStr === "SECONDARY")
  .forEach(m => {
    const lagSeconds = (primary.optimeDate - m.optimeDate) / 1000;
    print(`${m.name}: ${lagSeconds}s behind primary`);
  });

Trattalo come un'istantanea, non come una diagnosi. Un secondario che è 20 secondi indietro durante un'importazione batch potrebbe andare bene se recupera rapidamente. Un secondario che è sempre 20 secondi indietro durante il traffico normale merita attenzione.

Controlla se il Ritardo è Intenzionale

Prima di inseguire un falso incidente, ispeziona la configurazione del set di replica:

rs.conf()

Un membro ritardato è configurato per seguire il primario di proposito. Nella configurazione moderna di MongoDB, cerca secondaryDelaySecs su un membro. Quel membro è utile per alcuni scenari di recupero perché può preservare una vista più vecchia dei dati per un breve periodo. Non dovrebbe essere usato per letture fresche, e il suo ritardo previsto dovrebbe essere escluso dai normali avvisi di ritardo.

L'errore che vedo nelle operazioni reali è avvisare su ogni membro ritardato come se fosse rotto. Avvisa sul ritardo oltre il ritardo configurato. Se un membro è ritardato di 1 ora e mostra 1 ora e 5 minuti di ritardo, il ritardo reale è di circa 5 minuti.

Quando la Finestra Oplog è Troppo Piccola

L'oplog è una raccolta capped nel database local. I secondari la leggono e applicano le operazioni in ordine. Se un secondario cade così indietro che il primario non ha più le voci oplog di cui ha bisogno, il recupero ordinario non è più possibile. Il membro di solito ha bisogno di una sincronizzazione iniziale o di un ripristino da un backup adatto.

Ecco perché la finestra oplog è importante. Vuoi che copra più del tuo tempo di inattività previsto, manutenzione, interruzione di rete e picchi di scrittura. Non esiste una dimensione oplog "corretta" universale. Un cluster tranquillo può mantenere giorni di storia in un oplog piccolo. Un cluster occupato con aggiornamenti pesanti può bruciare la stessa dimensione in un breve periodo.

Se la finestra oplog si sta restringendo durante il traffico di punta, aumentala prima della prossima finestra di manutenzione. Sulle versioni supportate di MongoDB, usa replSetResizeOplog piuttosto che eliminare e ricreare local.oplog.rs. Eliminare l'oplog su un membro del set di replica è una manovra di recupero ad alto rischio, non un normale passo di ottimizzazione.

Esegui il comando di ridimensionamento sul membro di cui vuoi ridimensionare l'oplog:

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

Il valore size è in megabyte. Un valore di 10240 significa circa 10 GB. Ridimensiona ogni membro secondo necessità. In ambienti gestiti come MongoDB Atlas, usa il percorso di configurazione supportato dalla piattaforma invece di assumere il controllo diretto del filesystem o del processo.

Dopo il ridimensionamento, verifica la nuova finestra sotto carico di scrittura reale. Un oplog più grande riduce la possibilità di cadere dall'oplog, ma non fa applicare le operazioni più velocemente a un secondario lento.

Quando un Secondario è Lento

Se solo un secondario è in ritardo, accedi a quell'host e guarda i sintomi di sistema ordinari. MongoDB è spesso incolpato per ciò che è in realtà saturazione del disco.

Usa strumenti come:

iostat -xz 1
vmstat 1
top
mongostat --host secondary.example.com:27017
mongotop --host secondary.example.com:27017

Alta utilizzazione del disco, alti tempi di attesa o una lunga coda I/O di solito significano che il secondario non può scrivere abbastanza velocemente. Questo può accadere quando un tipo di istanza più economico viene usato per i secondari, quando EBS o storage di rete hanno una velocità effettiva provisionata inferiore, o quando backup e snapshot del filesystem vengono eseguiti contemporaneamente ai picchi di scrittura dell'applicazione.

Anche la CPU può essere importante, specialmente con compressione, crittografia, spostamenti di documenti, manutenzione degli indici o un carico di lavoro con molti piccoli aggiornamenti. La pressione della memoria si manifesta come page fault, churn della cache e un secondario che continua a leggere dal disco mentre cerca di applicare le voci oplog.

La soluzione pratica è di solito noiosa: dai al secondario storage e CPU paragonabili al primario, riduci il lavoro concorrente su quell'host o sposta le letture pesanti da qualche altra parte. Un membro del set di replica non è capacità di reporting gratuita. Deve ancora tenere il passo con la replica.

Quando le Letture sui Secondari Causano il Problema

Il ridimensionamento delle letture con i secondari è utile, ma è facile esagerare. Una query di dashboard che scansiona una grande collezione può competere con l'applicazione dell'oplog. Il secondario può ancora accettare letture, ma la replica rimane indietro perché la stessa CPU, cache e disco vengono usati per le query degli utenti.

Controlla il profiler e le operazioni correnti sul membro in ritardo:

db.currentOp({ active: true })

Se vedi letture lunghe, lavori di aggregazione o script di manutenzione, decidi se quel secondario dovrebbe davvero servire quel carico di lavoro. Per il reporting, un secondario nascosto o dedicato potrebbe essere una scelta migliore. Per le letture dell'applicazione, imposta maxStalenessSeconds in modo che il driver eviti i secondari che sono troppo indietro.

Per i percorsi critici per la coerenza, usa letture dal primario. Esempi includono stato di accesso, conferma del checkout, cambiamenti di password, impostazioni dell'account e qualsiasi cosa in cui un utente si aspetta di leggere la propria scrittura immediatamente. Le letture secondarie sono migliori per i dati in cui una breve obsolescenza è accettabile.

Quando il Primario Produce Raffiche

Grandi scritture possono far sembrare rotti secondari sani. Importazioni bulk, aggiornamenti multi-documento ampi, pulizia TTL, grandi cancellazioni e cambiamenti di indice possono produrre una raffica di attività oplog che richiede tempo per essere applicata.

Cerca operazioni recenti sul primario:

db.currentOp({ active: true })

Controlla anche i deploy dell'applicazione, i lavori di riparazione dei dati, i backfill e le attività programmate. Il ritardo di replica che inizia esattamente alle 02:00 spesso non è misterioso. È un lavoro batch.

Quando controlli il lavoro, suddividilo in pezzi più piccoli. Ad esempio, aggiorna i documenti per intervalli di _id, fai una pausa tra i batch e guarda il ritardo mentre il lavoro viene eseguito. Con bulkWrite, le scritture non ordinate possono migliorare la velocità effettiva, ma la gestione degli errori deve essere esplicita perché i fallimenti possono essere parziali. L'obiettivo non è sempre far finire il primario il più velocemente possibile. L'obiettivo è permettere al set di replica di assorbire il lavoro senza perdere il suo margine di recupero.

Indici e Applicazione dell'Oplog

In un normale set di replica, gli indici vengono replicati. Se gli indici differiscono tra i membri a causa di lavoro manuale, manutenzione fallita o un nodo che è stato ripristinato in modo errato, un secondario può diventare dolorosamente lento nell'applicare aggiornamenti e cancellazioni. L'operazione oplog potrebbe aver bisogno di trovare un documento e, senza l'indice previsto, il secondario può fare molto più lavoro di quanto abbia fatto il primario.

Confronta le definizioni degli indici sulle collezioni interessate:

db.orders.getIndexes()

Esegui lo stesso comando sul primario e sul secondario in ritardo. Se differiscono, scopri perché prima di apportare ulteriori modifiche. Ricostruire un grande indice può esso stesso creare carico, quindi pianificalo durante un periodo tranquillo o ricostruisci il membro da una fonte nota e buona se la divergenza è ampia.

Non usare vecchi consigli che dicono che le build di indici in background risolvono tutte le preoccupazioni di replica. Il comportamento di build degli indici di MongoDB è cambiato tra le versioni, e la scelta operativa giusta dipende dalla tua versione e topologia. Usa la documentazione corrente del server per la versione esatta che esegui.

I Problemi di Rete Sono Di Solito Visibili Da Qualche Altro Parte

Il ritardo di rete tende a manifestarsi come battiti cardiaci instabili, errori intermittenti o scarsa velocità effettiva tra host o regioni specifici. I controlli di base aiutano ancora:

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

Ma una bassa latenza di ping non prova abbastanza larghezza di banda. La replica può essere limitata dalla velocità effettiva, dalla perdita di pacchetti, dall'ispezione del firewall, dai collegamenti tra regioni o dalla rete condivisa rumorosa. Se il ritardo appare solo per un secondario remoto, confrontalo con un secondario nella stessa regione del primario. Se i membri della stessa regione stanno bene e il membro remoto è indietro, la topologia potrebbe chiedere troppo al collegamento.

Per i set di replica tra regioni, sii onesto sul compromesso. Possono aiutare con il disaster recovery, ma sono più esposti a limiti di latenza e larghezza di banda. Se il membro remoto è destinato alle letture, usa i controlli di obsolescenza e testa il comportamento di failover invece di assumere che si comporterà come un secondario locale.

Fai Attenzione con i Consigli su Riavvio e Risincronizzazione

Riavviare mongod può risolvere un problema transitorio, ma può anche peggiorare un incidente se il nodo era vicino a cadere dall'oplog. Prima di un riavvio, controlla la finestra oplog e il ritardo corrente. Se il nodo ha bisogno di due ore per recuperare e la finestra oplog è solo di tre ore durante il traffico di punta, un lungo riavvio potrebbe lasciarti con una sincronizzazione iniziale invece di un recupero.

La sincronizzazione iniziale è un'opzione di riparazione valida quando un secondario è obsoleto, corrotto o manca della storia oplog richiesta. È anche costosa. Copia i dati, costruisce indici e consuma risorse di rete e disco dalle fonti di sincronizzazione. In produzione, preferisci aggiungere o ricostruire un membro alla volta in modo che il set di replica mantenga abbastanza membri votanti e portatori di dati per tollerare i guasti.

Se un membro è così indietro che non può recuperare, prendi un percorso basato su backup fresco o snapshot che corrisponda ai tuoi standard operativi. Non eliminare una directory di dati perché una checklist lo dice. Conferma che il membro è usa e getta, conferma che il set di replica può tollerare la ricostruzione e conferma di avere abbastanza finestra oplog o una fonte di sincronizzazione iniziale affidabile.

Avvisa su Ciò che Utenti e Operatori Curano

Un buon avviso non è "il ritardo di replica è maggiore di 1 secondo" per ogni sistema. Alcune applicazioni possono tollerare 30 secondi sulle letture di analisi. Altre non possono tollerare letture obsolete sullo stato dell'account. Le soglie di avviso dovrebbero riflettere il caso d'uso.

Avvisi utili includono:

• Ritardo di replica sopra la tolleranza dell'applicazione per un periodo sostenuto.
• Finestra oplog sotto l'intervallo di manutenzione o recupero più lungo previsto.
• Un secondario in stato RECOVERING, STARTUP2 o non sano più a lungo del previsto.
• Saturazione I/O del disco su qualsiasi membro portatore di dati.
• Fallimenti del battito cardiaco o errori di rete tra i membri.

I pannelli di controllo dovrebbero mostrare il ritardo accanto al volume di scrittura, alla latenza del disco, alla CPU, alla pressione della memoria e alla velocità effettiva della rete. Il ritardo da solo ti dice che c'è un problema. I grafici vicini di solito ti dicono quale problema.

Un Ordine di Triage Pratico

Quando sei di turno, usa questo ordine:

1. Conferma quali membri sono in ritardo con rs.status().
2. Controlla se qualche ritardo è intenzionale a causa di secondaryDelaySecs.
3. Controlla la finestra oplog con rs.printReplicationInfo().
4. Confronta il ritardo con i picchi di scrittura, i lavori batch e i deploy recenti.
5. Ispeziona disco, CPU, memoria e carico di query locale del secondario in ritardo.
6. Controlla errori di rete e latenza tra i membri interessati.
7. Decidi se il membro può recuperare, ha bisogno di rimuovere il carico, ha bisogno di più risorse o deve essere ricostruito.

Il miglior risultato di solito non è un comando drammatico. È trovare il collo di bottiglia e rimuoverlo senza creare divergenza di dati. Il ritardo di replica di MongoDB è gestibile quando lo tratti come un segnale di capacità e topologia, non come un fallimento generico di MongoDB.