Niekończące się odzyskiwanie stanu wtórnego

Problem (najprawdopodobniej)

Ostatnia operacja na podstawowym pochodzi z „2015-05-15T02:10:56Z”, podczas gdy ostatnia operacja, która ma być drugorzędna, pochodzi z „2015-05-14T11:23:51Z”, co stanowi różnicę w przybliżeniu 15 godzin. To okno może znacznie przekraczać twoje okno oplog replikacji (różnica między czasem pierwszej i ostatniej operacji w twoim oplogu). Mówiąc prościej, na podstawowej jest zbyt wiele operacji, aby drugorzędna mogła nadrobić zaległości.

Nieco bardziej rozbudowane (choć uproszczone):podczas początkowej synchronizacji dane, z których synchronizuje się wtórna, są danymi z danego punktu w czasie. Po zsynchronizowaniu danych z tego punktu w czasie urządzenie pomocnicze łączy się z oplog i stosuje zmiany wprowadzone między wspomnianym punktem w czasie a teraz zgodnie z wpisami oplog. Działa to dobrze, o ile oplog przechowuje wszystkie operacje między wspomnianym punktem w czasie. Ale oplog ma ograniczony rozmiar (jest to tak zwana kolekcja ograniczona ). Jeśli więc na podstawowym dzieje się więcej operacji, niż oplog może pomieścić podczas początkowej synchronizacji, najstarsze operacje „zanikają”. Drugorzędny rozpoznaje, że nie wszystkie operacje są dostępne, aby „zbudować” te same dane, co podstawowe i odmawia ukończenia synchronizacji, pozostając w RECOVERY tryb.

Rozwiązanie(-a)

Problem jest znany i nie jest błędem, ale wynika z wewnętrznego działania MongoDB i kilku założeń dotyczących bezpieczeństwa popełnionych przez zespół programistów. Dlatego istnieje kilka sposobów radzenia sobie z tą sytuacją. Niestety, ponieważ masz tylko dwa węzły przenoszące dane, wszystkie wiążą się z przestojem.

Opcja 1:Zwiększ rozmiar oploga

To moja preferowana metoda, ponieważ rozwiązuje problem raz na zawsze (w pewnym sensie). Jest to jednak nieco bardziej skomplikowane niż inne rozwiązania. Z perspektywy wysokiego poziomu są to kroki, które podejmujesz.

1. Wyłącz główny
2. Utwórz kopię zapasową oploga, korzystając z bezpośredniego dostępu do plików danych
3. Uruchom ponownie mongod w trybie samodzielnym
4. Skopiuj bieżący oplog do tymczasowej kolekcji
5. Usuń bieżący oplog
6. Odtwórz oploga w żądanym rozmiarze
7. Skopiuj z powrotem wpisy oploga z tymczasowej kolekcji do nowego, błyszczącego oploga
8. Uruchom ponownie mongod jako część zestawu replik

Nie zapomnij zwiększyć oploga pomocniczego przed wykonaniem początkowej synchronizacji, ponieważ w przyszłości może on stać się podstawowym!

Aby uzyskać szczegółowe informacje, przeczytaj "Zmień rozmiar oploga" w samouczkach dotyczących konserwacji zestawu replik .

Opcja 2:Wyłącz aplikację podczas synchronizacji

Jeśli opcja 1 jest nieopłacalna, jedynym realnym innym rozwiązaniem jest zamknięcie aplikacji powodującej obciążenie zestawu replik, ponowne uruchomienie synchronizacji i poczekanie na jej zakończenie. W zależności od ilości przesyłanych danych oblicz kilka godzin.

Osobista notatka

Problem z oknem oplog jest dobrze znany. Podczas gdy zestawy replik i klastry shardowane są łatwe do skonfigurowania w MongoDB, do ich prawidłowego utrzymania potrzebna jest spora wiedza i trochę doświadczenia. Nie uruchamiaj czegoś tak ważnego jak baza danych ze złożoną konfiguracją bez znajomości podstaw - w przypadku, gdy wydarzy się coś złego (tm), może to doprowadzić do sytuacji FUBAR.