Mam usługę REST wbudowaną w node.js z Restify i Mongoose oraz mongoDB z kolekcją około 30 000 dokumentów o normalnym rozmiarze. Mam usługę węzła działającą przez pmx i pm2.
Wczoraj nagle węzeł zaczął wyrzucać błędy komunikatem „MongoError: Topology was zniszczona”, nic więcej. Nie mam pojęcia, co to oznacza i co mogło to spowodować. nie ma też wiele do znalezienia podczas wyszukiwania w Google. Więc pomyślałem, że zapytam tutaj.
Po dzisiejszym ponownym uruchomieniu usługi węzła błędy przestały pojawiać się. Jeden z nich również mam uruchomione w środowisku produkcyjnym i przeraża mnie, że może się to zdarzyć w dowolnym momencie w dość istotnej części instalacji, która tam działa ...
Używam następujących wersji wspomnianych pakietów:
- mangusta: 4.0.3
- restify: 3.0.3
- węzeł: 0.10.25
Odpowiedzi:
Wygląda na to, że połączenie serwera węzłowego z instancją MongoDB zostało przerwane podczas próby zapisu do niej.
Spójrz na kod źródłowy Mongo, który generuje ten błąd
Wygląda na to, że nie ma to związku z problemem Sails wymienionym w komentarzach, ponieważ nie zainstalowano żadnych aktualizacji, aby przyspieszyć awarię lub „naprawić”
źródło
Wiem, że odpowiedź Jasona została zaakceptowana, ale miałem ten sam problem z Mongoose i stwierdziłem, że usługa hostująca moją bazę danych zalecała zastosowanie następujących ustawień , aby utrzymać połączenie Mongodb w środowisku produkcyjnym:
Mam nadzieję, że ta odpowiedź może pomóc innym osobom mającym błędy „Topologia została zniszczona”.
źródło
Ten błąd jest spowodowany przerwaniem połączenia przez sterownik mongo z dowolnego powodu (na przykład awaria serwera).
Domyślnie mongoose spróbuje połączyć się ponownie przez 30 sekund, a następnie przestanie ponawiać próby i na zawsze wyrzuci błędy, aż do ponownego uruchomienia.
Możesz to zmienić, edytując te 2 pola w opcjach połączenia
dokumentacja opcji połączeń
źródło
server: {
itp.W moim przypadku ten błąd był spowodowany przez
db.close();
sekcję „await” w „async”źródło
db.close
dothen
bloku, prawda?db.close
dothen
bloku działało świetnie z natywnym sterownikiem MongoDB Node.js.To tylko niewielki dodatek do odpowiedzi Gaafara, dało mi to ostrzeżenie o dezaprobacie. Zamiast w obiekcie serwera, na przykład:
Może wejść na obiekt najwyższego poziomu. Po prostu wyjmij go z obiektu serwera i umieść w obiekcie opcji w następujący sposób:
źródło
„Topologia została zniszczona” może być spowodowana odłączeniem się mangusty przed utworzeniem indeksów dokumentów mongo, zgodnie z tym komentarzem
Aby upewnić się, że wszystkie modele mają utworzone indeksy przed odłączeniem, możesz:
źródło
Komentarz Sebastiana do odpowiedzi Adriena wymaga więcej uwagi, pomógł mi, ale może być czasem zignorowany, więc oto rozwiązanie :
źródło
Ja też miałem ten sam błąd. W końcu odkryłem, że mam jakiś błąd w moim kodzie. Używam równoważenia obciążenia dla dwóch serwerów nodejs, ale po prostu aktualizuję kod jednego serwera.
Zmieniam serwer mongod
from standalone to replication
, ale zapomniałem wykonać odpowiednią aktualizację parametrów połączenia, więc napotkałem ten błąd.autonomiczne parametry połączenia: parametry
mongodb://server-1:27017/mydb
połączenia replikacji:mongodb://server-1:27017,server-2:27017,server-3:27017/mydb?replicaSet=myReplSet
szczegóły tutaj :[dokument mongo dotyczący parametrów połączenia]
źródło
Spotkałem to w środowisku kubernetes / minikube + nodejs + mongoose. Problem polegał na tym, że usługa DNS działała z pewnym opóźnieniem. Sprawdzanie, czy DNS jest gotowy, rozwiązało mój problem.
(liczby w opcji db_options są arbitralne w przypadku stackoverflow i podobnych witryn)
źródło
Tutaj to, co zrobiłem, działa dobrze. Problem zniknął po dodaniu poniższych opcji.
źródło
Musisz ponownie uruchomić mongo, aby rozwiązać błąd topologii, a następnie po prostu zmienić niektóre opcje mangusty lub mongoclienta, aby rozwiązać ten problem:
źródło
Otrzymałem ten błąd podczas tworzenia nowej bazy danych w społeczności MongoDb Compass. Problem był z moim Mongodem, nie działał. Aby rozwiązać problem, musiałem uruchomić polecenie Mongod jak poprzednio.
Po uruchomieniu tego polecenia udało mi się stworzyć bazę danych.
Mam nadzieję, że to pomoże.
źródło
Od jakiegoś czasu się z tym zmagałem - jak widać na podstawie innych odpowiedzi, problem może być bardzo różny.
Najłatwiejszym sposobem, aby dowiedzieć się, co powoduje, jest włączenie
loggerLevel: 'info'
w opcjachźródło
W moim przypadku ten błąd był spowodowany przez identyczną instancję serwera, która już działa w tle.
Dziwne jest to, że kiedy uruchomiłem swój serwer bez powiadomienia, jeden już działa, konsola nie wyświetlała niczego w stylu „coś używa portu xxx”. Mógłbym nawet wrzucić coś na serwer. Tak więc zlokalizowanie tego problemu zajęło mi dość dużo czasu.
Co więcej, po zamknięciu wszystkich aplikacji, które mogę sobie wyobrazić, nadal nie mogłem znaleźć procesu używającego tego portu w monitorze aktywności mojego Maca. Muszę użyć
lsof
do śledzenia. Sprawca nie był zaskakujący - to proces węzłowy. Jednak z PID pokazanym na terminalu stwierdziłem, że numer portu na monitorze różni się od tego używanego przez mój serwer.Podsumowując, zabicie wszystkich procesów węzłów może bezpośrednio rozwiązać ten problem.
źródło
Rozwiązałem ten problem poprzez:
źródło