2013-04-12 5 views
5

Jestem początkujący w MongoDB i mam problem z wykonaniem tego na serwerze.Proces MongoDB jest zamykany każdego dnia. jak uruchomić mongod na zawsze na serwerze?

Mój projekt jest hostowany na serwerach hostmonster.com, ale nie wspiera mnie w bazach danych MongoDB, chociaż twierdzi, że mogę zainstalować go na własną odpowiedzialność.

Następnie zainstalowałem MongoDB 2.4.1 bez problemów w systemie Linux 64, po, w folderze bin MongoDB (z: mongo, mongod, mongodump ...) Stworzyłem folder o nazwie "data" i "data/db "za wykonanie niektórych testów.

z konsoli, mogę połączyć się z serwerem po drugiej stronie protokołu SSH i biegnę

./mongod --dbpath 'data/db' 

i to działa.

Ale potrzebuję, aby działała automatycznie na zawsze.

śledziłem etapy Mongodb can't start i uruchomić kolejną linię:

./mongod --fork --dbpath 'data/db' --smallfiles --logpath 'data/mongodb.log' --logappend 

Udało się również to, rozpoczęła proces i zamknąłem konsolę, proces ten kontynuował prowadzenie i mogłem zobaczyć moje dane całej mojej domenie .

Problem polega na tym, że zamknięcie procesu zajmuje dzień, tj. Nie widzę danych w domenie, więc muszę ponownie uruchomić mongodę. z:

./mongod --fork --dbpath 'data/db' --smallfiles --logpath 'data/mongodb.log' --logappend 

Nie chcę robić to codziennie, moje pytanie brzmi:

Co może być problemem ?, dlaczego proces mongod umiera każdego dnia?

Jak mogę uruchomić proces na zawsze?

Przepraszamy za mój angielski.

Edytuj: Dodaj ostatni dziennik błędów. Nie rozumiem tego.

Fri Apr 12 03:19:34.577 [TTLMonitor] query local.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:0 keyUpdates:0 locks(micros) r:141663 nreturned:0 reslen:20 141ms 
Fri Apr 12 03:19:34.789 [TTLMonitor] query users.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:3 keyUpdates:0 locks(micros) r:211595 nreturned:0 reslen:20 211ms 
Fri Apr 12 03:20:57.869 [PeriodicTask::Runner] task: DBConnectionPool-cleaner took: 18215ms 
Fri Apr 12 03:20:57.931 [PeriodicTask::Runner] task: WriteBackManager::cleaner took: 8ms 
Fri Apr 12 03:22:14.155 [PeriodicTask::Runner] task: DBConnectionPool-cleaner took: 32ms 
Fri Apr 12 03:22:14.215 [PeriodicTask::Runner] task: WriteBackManager::cleaner took: 14ms 
Fri Apr 12 03:22:30.670 [TTLMonitor] query actarium.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:2 keyUpdates:0 locks(micros) r:430204 nreturned:0 reslen:20 430ms 
Fri Apr 12 03:23:14.825 [PeriodicTask::Runner] task: DBConnectionPool-cleaner took: 7ms 
Fri Apr 12 03:23:31.133 [TTLMonitor] query actarium.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:2 keyUpdates:0 locks(micros) r:179175 nreturned:0 reslen:20 168ms 
Fri Apr 12 03:25:19.201 [PeriodicTask::Runner] task: WriteBackManager::cleaner took: 505ms 
Fri Apr 12 03:25:23.370 [TTLMonitor] query local.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:0 keyUpdates:0 locks(micros) r:3604735 nreturned:0 reslen:20 3604ms 
Fri Apr 12 03:25:25.294 [TTLMonitor] query users.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:3 keyUpdates:0 numYields: 1 locks(micros) r:3479328 nreturned:0 reslen:20 1882ms 
Fri Apr 12 03:26:26.647 [TTLMonitor] query actarium.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:2 keyUpdates:0 numYields: 1 locks(micros) r:1764712 nreturned:0 reslen:20 1044ms 
Fri Apr 12 04:09:27.804 [TTLMonitor] query actarium.system.indexes query: { expireAfterSeconds: { $exists: true } } ntoreturn:0 ntoskip:0 nscanned:2 keyUpdates:0 locks(micros) r:200919 nreturned:0 reslen:20 200ms 
Fri Apr 12 04:43:54.002 got signal 15 (Terminated), will terminate after current cmd ends 
Fri Apr 12 04:43:54.151 [interruptThread] now exiting 
Fri Apr 12 04:43:54.151 dbexit: 
Fri Apr 12 04:43:54.157 [interruptThread] shutdown: going to close listening sockets... 
Fri Apr 12 04:43:54.160 [interruptThread] closing listening socket: 9 
Fri Apr 12 04:43:54.160 [interruptThread] closing listening socket: 10 
Fri Apr 12 04:43:54.160 [interruptThread] closing listening socket: 11 
Fri Apr 12 04:43:54.160 [interruptThread] removing socket file: /tmp/mongodb-27017.sock 
Fri Apr 12 04:43:54.160 [interruptThread] shutdown: going to flush diaglog... 
Fri Apr 12 04:43:54.160 [interruptThread] shutdown: going to close sockets... 
Fri Apr 12 04:43:54.176 [interruptThread] shutdown: waiting for fs preallocator... 
Fri Apr 12 04:43:54.176 [interruptThread] shutdown: lock for final commit... 
Fri Apr 12 04:43:54.176 [interruptThread] shutdown: final commit... 
Fri Apr 12 04:43:54.176 [interruptThread] shutdown: closing all files... 
Fri Apr 12 04:43:54.212 [interruptThread] closeAllFiles() finished 
Fri Apr 12 04:43:54.220 [interruptThread] journalCleanup... 
Fri Apr 12 04:43:54.246 [interruptThread] removeJournalFiles 
Fri Apr 12 04:43:54.280 [interruptThread] error removing journal files 
boost::filesystem::directory_iterator::construct: No such file or directory: "/home2/anuncio3/bin/mongodb-linux-x86_64-2.4.1/bin/data/db/journal" 
Fri Apr 12 04:43:54.280 [interruptThread] error couldn't remove journal file during shutdown boost::filesystem::directory_iterator::construct: No such file or directory: "/home2/anuncio3/bin/mongodb-linux-x86_64-2.4.1/bin/data/db/journal" 
Fri Apr 12 04:43:54.285 shutdown failed with exception 
Fri Apr 12 04:43:54.285 dbexit: really exiting now 
+0

Sprawdź logi serwera/mongo dla komunikatów o błędach? –

+0

gotowy, dodałem informacje o dzienniku błędów. – edwinfmesa

+0

Wygląda na to, że monitor TTL mógł napotkać błąd – Sammaye

Odpowiedz

4

Twoja odpowiedź jest tutaj:

Fri Apr 12 04:43:54.002 got signal 15 (Terminated), will terminate after current cmd ends 
Fri Apr 12 04:43:54.151 [interruptThread] now exiting 

Twój proces jest sygnał 15, który jest domyślnym kill sygnał odbioru. Możliwe, że ich systemy automatycznie zabijają długo działające procesy lub coś podobnego. Jeśli tak właśnie jest, to twój gospodarz musiałby to rozwiązać.

Dodatkowo, te błędy:

Fri Apr 12 04:43:54.280 [interruptThread] error removing journal files 
boost::filesystem::directory_iterator::construct: No such file or directory: "/home2/anuncio3/bin/mongodb-linux-x86_64-2.4.1/bin/data/db/journal" 
Fri Apr 12 04:43:54.280 [interruptThread] error couldn't remove journal file during shutdown boost::filesystem::directory_iterator::construct: No such file or directory: "/home2/anuncio3/bin/mongodb-linux-x86_64-2.4.1/bin/data/db/journal" 

wskazują, że coś jest nie tak z instalacji użytkownika katalogu danych. Pliki dziennika albo nie istnieją, albo zaginą; jeśli jakiś proces w systemie próbuje oczyścić, to nie zdziwiłoby mnie, gdyby coś nukowało twoje pliki dziennika.

0

Wiem, że to stare pytanie, ale moje doświadczenie może być pomocne dla innych recenzentów. W oparciu o moje testy, pozwalają one tylko uruchomić program przez 5 minut (czasami więcej niż to) przed zabiciem go, więc zainstalowanie MongoDB jest dość bezużyteczne, chyba że masz dedykowane IP.

Powiązane problemy