Otrzymuję następujący błąd:
alex@alex-K43U:/$ mongo
MongoDB shell version: 2.2.0
connecting to: test
Thu Oct 11 11:46:53 Error: couldn't connect to server 127.0.0.1:27017 src/mongo/shell/mongo.js:91
exception: connect failed
alex@alex-K43U:/$
Oto, co się dzieje, gdy próbuję uruchomić mongodb:
* Starting database mongodb [fail]
Już próbowałem mongo --repair
Zrobiłem chown i chmod do var, lib oraz data / db i log mongodb.
Nie wiem, co jeszcze zrobić. Jakieś sugestie?
mongodb.log:
***** SERVER RESTARTED *****
Thu Oct 11 08:29:40
Thu Oct 11 08:29:40 warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.
Thu Oct 11 08:29:40
Thu Oct 11 08:29:41 [initandlisten] MongoDB starting : pid=1052 port=27017 dbpath=/var/lib/mongodb 32-bit host=alex-K43U
Thu Oct 11 08:29:41 [initandlisten]
Thu Oct 11 08:29:41 [initandlisten] ** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
Thu Oct 11 08:29:41 [initandlisten] ** see http://blog.mongodb.org/post/137788967/32-bit-limitations
Thu Oct 11 08:29:41 [initandlisten] ** with --journal, the limit is lower
Thu Oct 11 08:29:41 [initandlisten]
Thu Oct 11 08:29:41 [initandlisten] db version v2.2.0, pdfile version 4.5
Thu Oct 11 08:29:41 [initandlisten] git version: f5e83eae9cfbec7fb7a071321928f00d1b0c5207
Thu Oct 11 08:29:41 [initandlisten] build info: Linux domU-12-31-39-01-70-B4 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 BOOST_LIB_VERSION=1_49
Thu Oct 11 08:29:41 [initandlisten] options: { config: "/etc/mongodb.conf", dbpath: "/var/lib/mongodb", logappend: "true", logpath: "/var/log/mongodb/mongodb.log" }
Thu Oct 11 08:29:41 [initandlisten] Unable to check for journal files due to: boost::filesystem::basic_directory_iterator constructor: No such file or directory: "/var/lib/mongodb/journal"
**************
Unclean shutdown detected.
Please visit http://dochub.mongodb.org/core/repair for recovery instructions.
*************
Thu Oct 11 08:29:41 [initandlisten] exception in initAndListen: 12596 old lock file, terminating
Thu Oct 11 08:29:41 dbexit:
Thu Oct 11 08:29:41 [initandlisten] shutdown: going to close listening sockets...
Thu Oct 11 08:29:41 [initandlisten] shutdown: going to flush diaglog...
Thu Oct 11 08:29:41 [initandlisten] shutdown: going to close sockets...
Thu Oct 11 08:29:41 [initandlisten] shutdown: waiting for fs preallocator...
Thu Oct 11 08:29:41 [initandlisten] shutdown: closing all files...
Thu Oct 11 08:29:41 [initandlisten] closeAllFiles() finished
Thu Oct 11 08:29:41 dbexit: really exiting now
EDYTOWAĆ:
Usunąłem blokadę, a następnie zrobiłem mongod naprawę i otrzymałem ten błąd:
Thu Oct 11 12:05:37 [initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /data/db/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating
więc zrobiłem to z sudo:
alex@alex-K43U:~$ sudo mongod --repair
Thu Oct 11 12:05:42
Thu Oct 11 12:05:42 warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.
Thu Oct 11 12:05:42
Thu Oct 11 12:05:42 [initandlisten] MongoDB starting : pid=5129 port=27017 dbpath=/data/db/ 32-bit host=alex-K43U
Thu Oct 11 12:05:42 [initandlisten]
Thu Oct 11 12:05:42 [initandlisten] ** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
Thu Oct 11 12:05:42 [initandlisten] ** see http://blog.mongodb.org/post/137788967/32-bit-limitations
Thu Oct 11 12:05:42 [initandlisten] ** with --journal, the limit is lower
Thu Oct 11 12:05:42 [initandlisten]
Thu Oct 11 12:05:42 [initandlisten] db version v2.2.0, pdfile version 4.5
Thu Oct 11 12:05:42 [initandlisten] git version: f5e83eae9cfbec7fb7a071321928f00d1b0c5207
Thu Oct 11 12:05:42 [initandlisten] build info: Linux domU-12-31-39-01-70-B4 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 BOOST_LIB_VERSION=1_49
Thu Oct 11 12:05:42 [initandlisten] options: { repair: true }
Thu Oct 11 12:05:42 [initandlisten] Unable to check for journal files due to: boost::filesystem::basic_directory_iterator constructor: No such file or directory: "/data/db/journal"
Thu Oct 11 12:05:42 [initandlisten] finished checking dbs
Thu Oct 11 12:05:42 dbexit:
Thu Oct 11 12:05:42 [initandlisten] shutdown: going to close listening sockets...
Thu Oct 11 12:05:42 [initandlisten] shutdown: going to flush diaglog...
Thu Oct 11 12:05:42 [initandlisten] shutdown: going to close sockets...
Thu Oct 11 12:05:42 [initandlisten] shutdown: waiting for fs preallocator...
Thu Oct 11 12:05:42 [initandlisten] shutdown: closing all files...
Thu Oct 11 12:05:42 [initandlisten] closeAllFiles() finished
Thu Oct 11 12:05:42 [initandlisten] shutdown: removing fs lock...
Thu Oct 11 12:05:42 dbexit: really exiting now
Ale nadal mam ten sam problem.
sudo service mongod restart
pracował dla mnieOdpowiedzi:
Dziennik wskazuje, że mongodb kończy działanie, ponieważ istnieje stary plik blokady.
Jeśli nie korzystasz z kronikowania, usuń plik blokady, uruchom naprawę i ponownie uruchom mongodb.
Jeśli korzystasz lub działałeś z włączonym rejestrowaniem, zapoznaj się z odpowiednią dokumentacją Mongo DB . Zauważ, że mówią „Jeśli korzystasz z kronikowania, nie powinieneś wykonywać naprawy, aby przywrócić spójny stan”. Więc gdybyś rejestrował, naprawa mogła pogorszyć sytuację.
źródło
źródło
/data/db/mongod.lock
zamiast/var/lib/mongodb/mongod.lock
Czy biegałeś
mongod
przed biegiemmongo
?Postępowałem zgodnie z instrukcjami instalacji dla mongodb z http://docs.mongodb.org/manual/tutorial/install-mongodb-on-os-x/ i miałem ten sam błąd co ty tylko wtedy, gdy uruchomiłem
mongo
przed uruchomieniem procesu mongo zmongod
. Myślałem, że zainstalowanie mongodb również by go uruchomiło, ale musisz uruchomić go ręcznie,mongod
zanim zrobisz cokolwiek innego, co wymaga mongodb.źródło
mongo.exe
powinien być tym, który uruchamia DB.Dzieje się tak, ponieważ proces mongod jest wyłączony, musisz uruchomić poniższe polecenia, aby uruchomić proces mongod:
Mam nadzieję, że to ci pomoże.
źródło
sudo service mongod stop
isudo service mongodb stop
przed pierwszym poleceniem, ponieważ niektórzy ludzie mogą nadal mieć je uruchomione.Próbować
To rozwiązało mój problem.
źródło
sudo service mongod start
isudo service mongodb start
Sprawdź wolne miejsce w systemie plików i zwiększ je, jeśli jest mniejsze. Może to również spowodować, że mongo się nie uruchomi. Sprawdź plik /var/log/mongodb/mongodb.log.
źródło
Spróbuj biegać
mongod
wcześniejmongo
.sudo /usr/sbin/mongod
na moim opensuseTo rozwiązało mój problem,
źródło
więc najpierw musisz usunąć plik mongod.lock za pomocą poniższego polecenia
a następnie uruchom ponownie usługę mongo, wydając poniższe polecenie
źródło
Możesz sprawdzić,
netstat -anp | grep 27017
czy port jest używany przez inny proces.źródło
W systemie Windows uruchom cmd jako administrator:
Utworzyć katalog:
mkdir c: \ mongo \ data \ db
Zainstaluj usługę:
mongod.exe --install --logpath c: \ mongo \ logs --logappend --bind_ip 127.0.0.1 --dbpath c: \ mongo \ data \ db --directoryperdb
Uruchom MongoDB:
net start MongoDB
4. Uruchom powłokę Mongo:
To rozwiązanie działa dobrze dla mnie
źródło
To zadziałało dla mnie:
źródło
Na przyszłość wykonaj następujące kroki, aby uniknąć podobnych błędów:
1.Pobierz MondoDB https://www.mongodb.com/
2.Otwórz terminal i cd do folderu pobierania lub innego folderu, w którym zapisałeś swoje pobieranie mondodb (upewnij się, że wypakowałeś folder mongodb przed włożeniem do niego dysku CD)
3. Przenieś mongodb na ścieżkę usr / local
4.cd do folderu lokalnego
5. utwórz nowy katalog
6.cd do nowo utworzonego katalogu
7. nadaj uprawnienia mongo
8. Następnie przejdź do / otwórz swój .bash_profile
Aby to zrobić, wykonaj następujące kroki:
W swoim nowym terminalu
1 .
cd
2.pwd
3 .ls -l
Sprawdź, czy .bash_profile pojawia się na liście plików na Twoim terminalu
jeśli nie, utwórz -bash_profile
Tworzenie .bash_profile:
W twoim terminalu
dotknij .bash_profile
// pomiń ten krok, jeśli masz już plik .bash_profile
Krok 8:
Następnie w terminalu:
W pliku bash, który się otworzy, dodaj:
A następnie zapisz . (Plik Zapisz lub polecenie S / CMD + S)
Krok 9: z powrotem w terminalu :
Teraz otwórz dwa terminale. Jeden będzie dla twojego demona mondo, drugi dla twojego mongo .
Terminal 1: w terminalu wpisz: mongod
Wynik:
Terminal 2:
Wynik:
Upewnij się również, że nie popełnisz następującego błędu literowego podczas uruchamiania mongod w terminalu: To jest nieprawidłowe
daje następujący błąd : Nie można połączyć się z 127.0.0.1:27017, w (sprawdzanie gniazda pod kątem błędu po sondowaniu), przyczyna: Odmowa połączenia
To jest poprawne:
(Pomiędzy słowami mongo i d .. mondod nie powinno być spacji
Na koniec zawsze pamiętaj, że przed uruchomieniem mongo na terminalach musisz uruchomić mondod .
źródło
Śledziłem dokument pod adresem http://docs.mongodb.org/manual/tutorial/install-mongodb-on-red-hat/ .
Po skonfigurowaniu i ponownym uruchomieniu uruchomiłem
sudo service mongod start
i otrzymałem... [FAILED]
.W końcu okazało się, że
mongod
to się zaczęło. Myślę, żeyum install
dodałem go do automatycznego startu.Aby sprawdzić, czy
mongod
działa:service mongod status
.Mam nadzieję, że to pomoże komuś, kto ma ten sam problem.
źródło
Po częstych próbach w końcu udało mi się rozwiązać problem ...
źródło
Ten błąd może być spowodowany ustawieniem adresu IP powiązania bazy danych MongoDB. Możesz sprawdzić plik konfiguracyjny MongoDB przez
W moim przypadku adres IP wiązania jest ustawiony na adres intranetowy serwera, tak jak poniżej:
Więc dałem mongo parametr IP, aby połączyć się z powłoką według typu:
Nie zapomnij zrestartować usługi mongodb, jeśli zmieniłeś config.
źródło
Mam mongo w wersji 3.2.1 i musiałem usunąć plik blokady,
/data/db/
a następnie uruchomiłemmongod
i uruchomiono się pomyślnie.źródło
W terminalu uruchom te polecenia
1)
2)
źródło
Po usunięciu mongod.lock, który znajdował się w katalogu danych w moim systemie operacyjnym Windows, nadal wyświetlał ten sam komunikat o błędzie. Musiałem uruchomić mongod z --dbpath, aby polecenie mongo działało bez błędów.
źródło
Chociaż otrzymałem odpowiedzi, chciałbym omówić błędy sieciowe w
MongoDB
.Określenie obaw dotyczących bezpiecznego zapisu nie jest metodą pełnego sprawdzenia, czy jesteśmy bezpieczni. Załóżmy, że ustawione są
w=1
&j=true
, co się stanie, jeśli potwierdzenie zapisu nie zostanie odebrane z serwera? Cóż, prawdopodobnie tak się nie stało, ale mogło się wydarzyć. Powodem, dla którego mogło się to zdarzyć, są błędy sieciowe - są powody, dla których możemy nie otrzymać odpowiedzi twierdzącej. Możemy więc wysłać żądanie z aplikacji za pośrednictwem sterownika w wybranym języku.mongod
można go pomyślnie zakończyć, a następnie może nastąpić reset TCP, a sieć faktycznie może zostać zresetowana w taki sposób, że nigdy nie otrzymamy odpowiedzi. Mogliśmy więc otrzymać błąd, a po błędzie możemy założyć, że wystąpił błąd. To się nie wydarzyło, ale może się zdarzyć.W przypadku wkładki można się przed nią ustrzec. Jest to możliwe, ponieważ jeśli pozwolimy kierowcy stworzyć
_id
plik i zrobimy wstawkę - wtedy moglibyśmy to wstawić wiele razy i byłoby to szkodliwe. Ponieważ, jeśli zrobimy to pierwszy raz i otrzymamy błąd i nie jesteśmy pewni, czy ta wstawka została zakończona, ponieważ jest to błąd sieci, możemy to zrobić ponownie. I pod warunkiem, że wykonamy to ponownie, możesz wykonać to dokładnie_id
. Najgorszym scenariuszem jest to, że podczas próby wstawienia otrzymamy zduplikowany błąd klucza.Jednak aktualizacja jest miejscem, w którym występuje problem. Zwłaszcza aktualizacja, która nie jest potężna, na przykład obejmowała
$ink
polecenie. Więc mówimy bazie danych, aby zwiększyła określone pole. W takim przypadku, jeśli otrzymamy błąd sieciowy i nie wiemy, czy aktualizacja nastąpiła. Teraz może wiemy wystarczająco dużo o wartościach, abyśmy mogli z nimi sprawdzić, czy nastąpiła aktualizacja, co jest w porządku. Ale jeśli nie znamy wartości początkowej w bazie danych dla tego pola, nie możemy wiedzieć, czy wystąpił, czy nie, w przypadku błędu sieci. Tego rodzaju problemy są niezwykle rzadkie w przypadku dobrej sieci.A jeśli naprawdę musimy tego uniknąć za wszelką cenę, to co musimy zrobić, to włączyć wszystkie nasze aktualizacje we wstawkach, odczytując pełną wartość dokumentu z bazy danych, a następnie potencjalnie usuwając go i wstawiając ponownie lub po prostu wstawiając nowy.
Powody, dla których aplikacja może otrzymać zwrotny błąd, nawet jeśli zapis się powiódł:
MongoDB
Serwer kończy między otrzymania zapisu i reagowania na nią.źródło
To działa dla mnie, aby zatrzymać używanie mongodb:
Aby ponownie uruchomić:
źródło
Spróbuj:
źródło
Dodanie bin do PATH w zmiennych środowiskowych pomogło.
GOTO Installation Path i skopiuj ../bin do zmiennych PATH w zmiennych środowiskowych w Windows
źródło
wpisz windows + r i wprowadź następujące polecenie
teraz wpisz „mongo” w cmd w odpowiedniej ścieżce, w której znajduje się plik mongo.exe, zacznie działać.
źródło
1. utwórz nowy folder na dysku d D: / data / db
2. otwórz terminal na D: / data / db
3. Wpisz mongod i wprowadź.
4. Wpisz mongo i wprowadź.
a twój mongodb zawarł ............
źródło
Wystarczy uruchomić
mongod --repair
zC:\Program Files\MongoDB\Server\4.0\bin
Oto dokument https://docs.mongodb.com/manual/tutorial/recover-data-following-unexected-shutdown/
źródło
źródło
Wystąpił podobny błąd, ale główna przyczyna była inna. Po zainstalowaniu mongodb przy użyciu homebrew. https://docs.mongodb.com/manual/installation/ Muszę uruchomić usługę „mongod” przed wydaniem polecenia „mongo” na terminalu.
źródło
Jeśli używasz systemów OS X, nie ma żadnych
service
poleceń. Więc nie będziesz w stanie wykonaćsudo service mongod start
.Sprawdź tę odpowiedź https://unix.stackexchange.com/a/155746, aby uzyskać dodatkową pomoc!
źródło
Błąd: nie można połączyć się z serwerem 127.0.0.1:27017
To rozwiązanie dla użytkowników WINDOWS wprowadź kod tutaj 1. Utwórz katalog:
mongod.exe --install --logpath
Uruchom MongoDB:
net start MongoDB
4. Uruchom powłokę Mongo:
idź do aż bin i wejdź
mongo
Uwaga: Otwórz terminal w trybie administratora
źródło
Ubuntu 18.04LTS: Problem pojawia się, gdy całkowicie odinstalowałem poprzednią wersję i zainstalowałem 4.2.6
Po godz. Googlowania rozwiązałem kolejny problem
MongoDB Failing to Start - *** przerywanie po awarii fassert ()
Byłem beznadziejny, że problem nie mógł połączyć się z serwerem , ponieważ wszystko wydaje się w porządku.
W końcu zdecydowałem się zrestartować system operacyjny i zgadnij co ... BINGO
źródło