Jedním z velkých problémů při poškození dat aplikací nebo lidských chyb je to, že závadný zápis na primární bude okamžitě replikován na sekundární.
To je jeden z důvodů, proč uživatelé využívají „slaveDelay“ – možnost spustit jeden z vašich sekundárních uzlů s pevným časovým zpožděním (samozřejmě vám to pomůže, pouze pokud chybu nebo chybu objevíte během časového období, které je kratší než zpoždění na tom sekundárním).
V případě, že takové nastavení nemáte, musíte se spolehnout na zálohu, která obnoví stav záznamů, které potřebujete obnovit do stavu před chybou.
Proveďte všechny operace na samostatné samostatné kopii vašich dat – teprve po ověření, že vše bylo správně znovu vytvořeno, byste pak opravená data měli přesunout do svého produkčního systému.
K tomu je potřeba nedávná kopie zálohy (řekněme, že záloha je X hodin stará) a oplog na vašem clusteru musí obsahovat více než X hodin dat. Nespecifikoval jsem oplog kterého uzlu, protože (a) každý člen sady replik má stejný obsah v oplogu a (b) je je možné, že se velikost vašeho oplogu na různých členech uzlu liší, v takovém případě chcete zkontrolovat ten "největší".
Řekněme tedy, že vaše poslední záloha je stará 52 hodin, ale naštěstí máte oplog, který uchovává 75 hodin dat (yay).
Už jste si uvědomili, že všechny vaše uzly (primární a sekundární) mají „špatná“ data, takže co byste udělali, bylo obnovit tuto nejnovější zálohu do nového mongoda. Zde obnovíte tyto záznamy do stavu, v jakém byly před problematickou aktualizací – a poté je můžete jednoduše přesunout do aktuální primární volby, odkud budou replikovány do všech sekundárních souborů.
Při obnově zálohy vytvořte mongodump své kolekce oplogů pomocí tohoto příkazu:
mongodump -d local -c oplog.rs -o oplogD
Přesuňte oplog do jeho vlastního adresáře a přejmenujte jej na oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Nyní musíte najít „provinilou“ operaci. Oplog můžete vypsat do podoby čitelné pro člověka pomocí bsondump příkaz v souboru oplogR/oplog.bson (a pak použijte grep nebo what-not k nalezení "špatné" aktualizace). Případně se můžete dotazovat na původní oplog v sadě replik pomocí use local a db.oplog.rs.find() příkazy v shellu.
Vaším cílem je najít tento záznam a poznamenat si jeho ts pole.
Může to vypadat takto:
"ts" : Timestamp( 1361497305, 2789 )
Všimněte si, že mongorestore má dvě možnosti, jednu nazvanou --oplogReplay a druhý s názvem oplogLimit . Nyní si tento oplog přehrajete na obnoveném samostatném serveru, ALE před touto problematickou aktualizační operací se zastavíte.
Příkaz by byl (hostitel a port jsou tam, kde je vaše nově obnovená záloha):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
To obnoví každou operaci ze souboru oplog.bson v adresáři oplogR a zastaví se těsně před záznamem s hodnotou ts Timestamp(1361497305, 2789).
Připomeňme si, že důvodem, proč jste to dělali na samostatné instanci, je to, abyste mohli ověřit správná data vytvořená obnovením a přehráním – jakmile to ověříte, můžete zapsat obnovené záznamy na příslušné místo ve skutečné primární instanci (a umožnit šíření replikace opravené záznamy na sekundární stránky).