Jednym z głównych problemów związanych z uszkodzeniem danych w aplikacji lub błędami ludzkimi jest to, że nieprawidłowy zapis do podstawowego zostanie natychmiast zreplikowany do drugorzędnego.
Jest to jeden z powodów, dla których użytkownicy korzystają z "slaveDelay" - opcji uruchomienia jednego z twoich drugorzędnych węzłów z ustalonym opóźnieniem (oczywiście pomaga to tylko wtedy, gdy odkryjesz błąd lub błąd w okresie krótszym niż opóźnienie na tym wtórnym).
Jeśli nie masz takiej konfiguracji, musisz polegać na kopii zapasowej, aby odtworzyć stan rekordów, które musisz przywrócić do stanu sprzed wystąpienia błędu.
Wykonaj wszystkie operacje na oddzielnej, samodzielnej kopii danych - dopiero po sprawdzeniu, czy wszystko zostało poprawnie odtworzone, możesz przenieść poprawione dane do swojego systemu produkcyjnego.
Aby móc to zrobić, wymagana jest najnowsza kopia kopii zapasowej (załóżmy, że kopia zapasowa ma X godzin), a oplog w klastrze musi zawierać więcej niż X godzin danych. Nie określiłem oplogu którego węzła, ponieważ (a) każdy element zestawu replik ma taką samą zawartość w oplogu i (b) jest możliwe, że rozmiar twojego oploga jest inny na różnych członkach węzła, w takim przypadku chcesz sprawdzić „największy”.
Załóżmy więc, że twoja najnowsza kopia zapasowa ma 52 godziny, ale na szczęście masz oplog, który przechowuje 75 godzin danych (tak).
Już zdałeś sobie sprawę, że wszystkie twoje węzły (główne i drugorzędne) mają „złe” dane, więc to, co byś zrobił, to przywrócenie tej ostatniej kopii zapasowej do nowego mongoda. W tym miejscu przywrócisz te rekordy do stanu, w jakim były tuż przed nieprawidłową aktualizacją - a następnie możesz po prostu przenieść je do bieżącego podstawowego, skąd zostaną zreplikowane do wszystkich pomocniczych.
Podczas przywracania kopii zapasowej utwórz mongodump swojej kolekcji oplog za pomocą tego polecenia:
mongodump -d local -c oplog.rs -o oplogD
Przenieś oplog do własnego katalogu, zmieniając jego nazwę na oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Teraz musisz znaleźć „obraźliwą” operację. Możesz zrzucić oploga do postaci czytelnej dla człowieka, używając bsondump polecenie w pliku oplogR/oplog.bson (a następnie użyj grep lub what-not, aby znaleźć „złą” aktualizację). Alternatywnie możesz zapytać o oryginalny oplog w zestawie replik za pomocą use local i db.oplog.rs.find() poleceń w powłoce.
Twoim celem jest znalezienie tego wpisu i zanotowanie jego ts pole.
Może to wyglądać tak:
"ts" : Timestamp( 1361497305, 2789 )
Zauważ, że mongorestore polecenie ma dwie opcje, jedną o nazwie --oplogReplay i drugi o nazwie oplogLimit . Odtworzysz teraz ten oplog na przywróconym serwerze autonomicznym, ALE zatrzymasz się przed tą nieprawidłową operacją aktualizacji.
Polecenie to (host i port to miejsce, w którym znajduje się nowo przywrócona kopia zapasowa):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
Spowoduje to przywrócenie każdej operacji z pliku oplog.bson w katalogu oplogR, zatrzymując się tuż przed wpisem z wartością ts Timestamp(1361497305, 2789).
Przypomnijmy,że powodem, dla którego robiłeśto na osobnej instancji jest możliwość weryfikacji przywracania i odtwarzania utworzonych poprawnych danych - po ich zweryfikowaniu możesz zapisaćprzywrócone rekordy w odpowiednim miejscu w rzeczywistym podstawowym (i zezwolić na propagowanie replikacji poprawione rekordy do wtórnych).
