Il problema (molto probabile)
L'ultima operazione sul primario è da "2015-05-15T02:10:56Z", mentre l'ultima operazione sul secondario è da "2015-05-14T11:23:51Z", che è una differenza di circa 15 ore. Quella finestra potrebbe superare la finestra dell'oplog di replica (la differenza tra l'ora della prima e dell'ultima voce dell'operazione nell'oplog). In parole povere, ci sono troppe operazioni sul primario perché il secondario possa recuperare il ritardo.
Un po' più elaborato (sebbene semplificato):durante una sincronizzazione iniziale, i dati da cui si sincronizza il secondario sono i dati di un determinato momento. Quando i dati di quel momento vengono sincronizzati, il secondario si connette all'oplog e applica le modifiche apportate tra detto momento e ora in base alle voci dell'oplog. Funziona bene fintanto che l'oplog conserva tutte le operazioni tra il momento indicato. Ma l'oplog ha una dimensione limitata (è una cosiddetta capped collection
). Quindi, se ci sono più operazioni in corso sul primario di quante l'oplog possa contenere durante la sincronizzazione iniziale, le operazioni più vecchie "svaniscono". Il secondario riconosce che non tutte le operazioni sono disponibili necessarie per "costruire" gli stessi dati del primario e rifiuta di completare la sincronizzazione, rimanendo in RECOVERY modalità.
La/le soluzione/i
Il problema è noto e non è un bug, ma è il risultato del funzionamento interno di MongoDB e di diverse ipotesi di sicurezza fatte dal team di sviluppo. Quindi, ci sono diversi modi per affrontare la situazione. Purtroppo, dal momento che hai solo due nodi di rilevamento dati, tutti implicano tempi di inattività.
Opzione 1:aumenta la dimensione dell'oplog
Questo è il mio metodo preferito, poiché affronta il problema una volta e (più o meno) per tutte. Tuttavia, è un po' più complicato rispetto ad altre soluzioni. Da una prospettiva di alto livello, questi sono i passaggi che fai.
- Chiudi il principale
- Crea un backup dell'oplog utilizzando l'accesso diretto ai file di dati
- Riavvia il
mongodin modalità autonoma - Copia l'oplog corrente in una raccolta temporanea
- Elimina l'oplog corrente
- Ricrea l'oplog con la dimensione desiderata
- Copia le voci dell'oplog dalla raccolta temporanea al nuovo brillante oplog
- Riavvia
mongodcome parte del set di repliche
Non dimenticare di aumentare l'oplog del secondario prima di eseguire la sincronizzazione iniziale, poiché potrebbe diventare primario in futuro!
Per i dettagli, leggi "Modifica la dimensione dell'oplog" nei tutorial sulla manutenzione dei set di repliche .
Opzione 2:spegni l'app durante la sincronizzazione
Se l'opzione 1 non è valida, l'unica vera altra soluzione è chiudere l'applicazione che causa il carico sul set di repliche, riavviare la sincronizzazione e attendere che sia troppo completa. A seconda della quantità di dati da trasferire, calcola con diverse ore.
Una nota personale
Il problema della finestra di oplog è ben noto. Sebbene i set di repliche e i cluster partizionati siano facili da configurare con MongoDB, sono necessarie alcune conoscenze e un po' di esperienza per mantenerli correttamente. Non eseguire qualcosa di importante come un database con una configurazione complessa senza conoscere le basi:nel caso in cui si verificasse qualcosa di brutto (tm), potrebbe portare a una situazione FUBAR.
