Uno dei grandi problemi nell'applicazione o nel danneggiamento dei dati dell'errore umano è che la scrittura dannosa sul primario verrà immediatamente replicata sul secondario.
Questo è uno dei motivi per cui gli utenti sfruttano "slaveDelay" - un'opzione per eseguire uno dei tuoi nodi secondari con un ritardo di tempo fisso (ovviamente questo ti aiuta solo se scopri l'errore o il bug durante un periodo di tempo inferiore a il ritardo su quella secondaria).
Nel caso in cui non disponi di tale configurazione, devi fare affidamento su un backup per ricreare lo stato dei record che devi ripristinare allo stato precedente al bug.
Esegui tutte le operazioni su una copia separata dei tuoi dati, solo dopo aver verificato che tutto sia stato ricreato correttamente, dovresti quindi spostare i dati corretti nel tuo sistema di produzione.
Ciò che è necessario per poter eseguire questa operazione è una copia recente del backup (diciamo che il backup ha X ore) e l'oplog sul tuo cluster deve contenere più di X ore di dati. Non ho specificato l'oplog di quale nodo perché (a) ogni membro del set di repliche ha lo stesso contenuto nell'oplog e (b) è possibile che la dimensione del tuo oplog sia diversa su diversi membri del nodo, nel qual caso vuoi selezionare quello "più grande".
Quindi supponiamo che il tuo backup più recente abbia 52 ore, ma fortunatamente hai un oplog che contiene 75 ore di dati (sì).
Ti sei già reso conto che tutti i tuoi nodi (primari e secondari) hanno i dati "cattivi", quindi quello che faresti è ripristinare questo backup più recente in un nuovo mongod. Qui è dove ripristinerai questi record a quello che erano prima dell'aggiornamento offensivo, quindi puoi semplicemente spostarli nel primario corrente da dove verranno replicati su tutti i secondari.
Durante il ripristino del backup, crea un mongodump della tua raccolta oplog tramite questo comando:
mongodump -d local -c oplog.rs -o oplogD
Sposta l'oplog nella sua directory rinominandolo in oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Ora devi trovare l'operazione "incriminata". Puoi scaricare l'oplog in un formato leggibile dall'uomo, usando il bsondump comando sul file oplogR/oplog.bson (e quindi utilizzare grep o what-not per trovare l'aggiornamento "cattivo"). In alternativa puoi interrogare l'oplog originale nel set di repliche tramite use local e db.oplog.rs.find() comandi nella shell.
Il tuo obiettivo è trovare questa voce e annotarne i ts campo.
Potrebbe assomigliare a questo:
"ts" : Timestamp( 1361497305, 2789 )
Nota che il mongorestore comando ha due opzioni, una chiamata --oplogReplay e l'altro chiamato oplogLimit . Ora riprodurrai questo oplog sul server autonomo ripristinato MA ti fermerai prima di questa operazione di aggiornamento offensiva.
Il comando sarebbe (l'host e la porta sono dove si trova il backup appena ripristinato):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
Questo ripristinerà ogni operazione dal file oplog.bson nella directory oplogR fermandosi subito prima della voce con il valore ts Timestamp(1361497305, 2789).
Ricordiamo che il motivo per cui lo stavi facendo su un'istanza separata è che puoi verificare il ripristino e riprodurre i dati corretti creati:una volta verificati, puoi scrivere i record ripristinati nella posizione appropriata nel file primario reale (e consentire la propagazione della replica i record corretti alle secondarie).
