Dlaczego Mongo utknęło w STARTUP2?

Mam Mongozestaw repliki z kilkoma pomocniczymi. Skrzynka, w której znajduje się druga instancja, uległa awarii i utraciła bazę danych.

Uruchomiłem drugą Mongoinstancję ponownie i teraz utknęła w STARTUP2 na ponad 12 godzin. Czy jest sens ? Dokumenty mówią, że Mongopowinien być w STARTUP2 przez krótki czas, zanim wejdzie w stan ODZYSKIWANIA

Co dokładnie oznacza STARTUP2? Czy kopiuje bazę danych z podstawowego? Jak mogę to zweryfikować (zakładając, że Mongo działa w systemie Linux)?

Odpowiedź eoinbrazil jest częściowo niepoprawna. Nowy Węzeł może znajdować się w STARTUP2 przez długi czas. Link opublikowany mówi:

Każdy członek zestawu replik wchodzi w stan STARTUP2, gdy tylko mongod zakończy ładowanie konfiguracji tego członka, w którym to czasie staje się aktywnym członkiem zestawu replik. Następnie członek decyduje, czy przeprowadzić pierwszą synchronizację. Jeśli członek rozpocznie pierwszą synchronizację, pozostaje w STARTUP2, dopóki wszystkie dane nie zostaną skopiowane i nie zostaną zbudowane wszystkie indeksy. Następnie członek przechodzi do ODZYSKIWANIA.

Administruję kolekcją 700 GB, a kiedy dodam nowy węzeł, stan STARTUP2 pozostaje dobrze przez ponad 24 godziny. Ale nadal możesz sprawdzić, czy coś się dzieje, obserwując, czy baza danych rośnie. Możesz zobaczyć rozmiar bazy danych w nowym węźle za pomocą

show databases

lub możesz również obserwować katalog danych, aby zobaczyć, czy wciąż rośnie. (w systemie Linux z poleceniami ls, df, du, iotop itp.)

Stan STARTUP2 oznacza, że ​​węzeł nie może głosować. Członek RS wchodzi w ten stan, gdy proces MongoD zakończy ładowanie swojej konfiguracji. W tym stanie członek utworzył wątki do obsługi wewnętrznych operacji replikacji, ale nie zmienił jeszcze stanu na Odzyskiwanie i dalej z tego na Pomocniczy (patrz [stan i ich szczegóły w dokumentacji]) .

Jeśli twój węzeł znajduje się w tym stanie dłużej niż przez krótki czas, napotykasz dziwne zachowania. Jest to prawie niemożliwe do przeanalizowania bez dzienników, aby ustalić, dlaczego utknął. Uruchomienie rs.status () i db.printSlaveReplicationInfo () da ci trochę szczegółów na temat lokalnego obrazu w węźle.

Normalnym rozwiązaniem tego problemu byłoby zamknięcie węzła, wyczyszczenie jego plików danych (tych plików w ścieżce dbpath) i zrestartowanie go. Spowoduje to ponowne uruchomienie procesu początkowej synchronizacji i powinno zostać przeniesione do WTÓRNEJ. Jeśli ponownie utknie w STARTUP2, musisz spojrzeć na dzienniki, aby zebrać więcej informacji o tym, dlaczego - istnieje wiele przyczyn, ale jedną z nich może być niestabilna sieć lub konflikt zasobów lokalnych.

Należy zauważyć, że podczas początkowej synchronizacji węzeł pozostanie w STARTUP2, więc w zależności od ilości synchronizowanych danych może to być znaczny czas (potencjalnie dni).

Jedną z możliwych przyczyn jest to, że drugorzędne stają się „nieaktualne”, jak podano tutaj .

Podczas resynchronizacji elementu upewnij się, że RS nie jest obciążony.

Stan STARTUP2 może wynikać z niewystarczającej ilości miejsca na dysku. Ponieważ nie ma miejsca do synchronizacji, może pozostać tylko stan @ STARTUP2.