Et af de store problemer i forbindelse med applikations- eller menneskelige fejldatakorruption er, at den fornærmende skrivning til den primære straks vil blive replikeret til den sekundære.
Dette er en af grundene til, at brugere drager fordel af "slaveDelay" - en mulighed for at køre en af dine sekundære noder med en fast tidsforsinkelse (det hjælper dig selvfølgelig kun, hvis du opdager fejlen eller fejlen i løbet af tidsperioden, der er kortere end forsinkelsen på den sekundære).
Hvis du ikke har sådan en opsætning, skal du stole på en sikkerhedskopi for at genskabe tilstanden for de poster, du skal gendanne til deres tilstand før fejl.
Udfør alle handlingerne på en separat selvstændig kopi af dine data - først efter at have verificeret, at alt var korrekt genskabt, bør du derefter flytte de rettede data ind i dit produktionssystem.
Det, der kræves for at kunne gøre dette, er en nylig kopi af sikkerhedskopien (lad os sige, at sikkerhedskopien er X timer gammel), og oploggen på din klynge skal indeholde mere end X timers data. Jeg specificerede ikke hvilken nodes oplog, fordi (a) hvert medlem af replikasættet har det samme indhold i oploggen og (b) det er muligt, at din oplog-størrelse er forskellig på forskellige nodemedlemmer, i hvilket tilfælde du vil markere den "største".
Så lad os sige, at din seneste backup er 52 timer gammel, men heldigvis har du en oplog, der rummer 75 timers data (yay).
Du har allerede indset, at alle dine noder (primære og sekundære) har de "dårlige" data, så hvad du ville gøre er at gendanne denne seneste sikkerhedskopi til en ny mongod. Det er her, du vil gendanne disse registreringer til, hvad de var lige før den stødende opdatering - og så kan du bare flytte dem til den nuværende primære, hvorfra de vil blive replikeret til alle de sekundære.
Mens du gendanner din sikkerhedskopi, skal du oprette en mongodump af din oplog-samling via denne kommando:
mongodump -d local -c oplog.rs -o oplogD
Flyt oploggen til dens egen mappe og omdøb den til oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Nu skal du finde den "fornærmende" operation. Du kan dumpe oplog'en til menneskelig læsbar form ved at bruge bsondump kommando på oplogR/oplog.bson-filen (og brug derefter grep eller what-not for at finde den "dårlige" opdatering). Alternativt kan du forespørge mod den originale oplog i replikasættet via use local og db.oplog.rs.find() kommandoer i skallen.
Dit mål er at finde denne post og notere dens ts felt.
Det kan se sådan ud:
"ts" : Timestamp( 1361497305, 2789 )
Bemærk, at mongorestore kommandoen har to muligheder, en kaldet --oplogReplay og den anden kaldet oplogLimit . Du vil nu afspille denne oplog på den gendannede stand-alone server, MEN du stopper før denne stødende opdatering.
Kommandoen ville være (vært og port er, hvor din nyligt gendannede backup er):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
Dette vil gendanne hver handling fra oplog.bson-filen i oplogR-biblioteket, der stopper lige før indtastningen med ts-værdien Timestamp(1361497305, 2789).
Husk på, at grunden til, at du gjorde dette på en separat instans, er, at du kan verificere gendannelsen og genafspille oprettede korrekte data - når du har verificeret det, kan du skrive de gendannede poster til det passende sted i den rigtige primære (og tillade replikering udbredelse de korrigerede poster til de sekundære).