web-dev-qa-db-fra.com

MongoDB ne démarre pas après un crash du serveur

Mon ordinateur Ubuntu était tombé en panne et lorsque je l'ai redémarré, MongoDB ne fonctionnait pas. J'ai essayé les commandes suivantes et obtenu le résultat suivant:

$ mongo
Error: couldn't connect to server 127.0.0.1:27017 src/mongo/Shell/mongo.js:91
exception: connect failed

$ service mongodb status
mongodb stop/waiting

$ service mongodb restart
stop: Unknown instance: 
start: Rejected send message, 1 matched rules; type="method_call",
       sender=":1.57" (uid=1000 pid=2227 comm="start mongodb ")
       interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)"
       requested_reply="0"
       destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")

$ tail /var/log/mongodb/mongodb.log
[initandlisten] exception in initAndListen: 12596 old lock file, terminating
dbexit: 
[initandlisten] shutdown: going to close listening sockets...
[initandlisten] shutdown: going to flush diaglog...
[initandlisten] shutdown: going to close sockets...
[initandlisten] shutdown: waiting for fs preallocator...
[initandlisten] shutdown: closing all files...
[initandlisten] closeAllFiles() finished
dbexit: really exiting now

(Sortie reformatée pour correspondre à la disposition du site Web.)

Qu'est-il arrivé? Comment puis-je le réparer?

mongodbubuntuadministration
72
Hosam Aly

Le fichier journal vous indique que vous avez un "ancien fichier de verrouillage". MongoDB conserve un fichier verrouillé pendant son exécution. Il crée ce fichier quand il est démarré et le supprime quand il est arrêté. Lorsque l'ordinateur se bloque (ou que MongoDB se bloque, par exemple via kill), ce fichier n'est pas supprimé et la base de données ne démarre donc pas. L'existence de ce fichier indique un arrêt impur de MongoDB.

Deux choses peuvent être faites:

  1. S'il s'agit d'une machine de développement et que vous n'utilisez pas votre base de données (ni aucun de vos programmes), vous pouvez supprimer le fichier manuellement. Pour MongoDB 2.2.2 exécuté sur Ubuntu 12.10, il s'agit de /var/lib/mongodb/mongod.lock. Pour les autres versions, le fichier peut se trouver dans un chemin différent ou s'appeler mongo.lock.

  2. La voie la plus sûre consiste à suivre le guide Durabilité et réparation de MongoDB. En résumé, pour une machine avec la configuration ci-dessus, vous devez exécuter les commandes suivantes:

    Sudo -u mongodb mongod --repair --dbpath /var/lib/mongodb/
Sudo service mongod start
169
Hosam Aly

tout ce que j'avais à faire était de courir: Sudo mongod --repair

puis:

Sudo Mongod

3
edencorbin

Sur la base de mon expérience, je supprime généralement le fichier "mongod.lock" qui se trouve dans le dossier de la base de données - Dans mon cas:

* Je navigue jusqu’à l’emplacement de la base de données sur mon dossier Ubuntu, c’est-à-dire "data" (cd data); lister les fichiers (ls) * Ensuite, je vais supprimer le fichier "mongod.lock" qui a été créé automatiquement lorsque la base de données s'est écrasée, en créant le fichier "rm mongod.lock".

Après quoi, je vais émettre "./mongod" pour démarrer le dongon mongo ou mongo pour lancer le shell mongo. Et tout ira bien.

2
samson ojo

Vérifiez si vous avez assez d’espace libre sur votre serveur. S'il ne reste plus de place, mongodb ne commencera pas. 

0
Jeremy Lynch

Merci les gars. Nous avons également rencontré un problème où MongoDB redémarrait encore et encore et se plaignait de old lock file . J'ai arrêté MongoDB à partir de la liste de services Windows, puis j'ai supprimé le fichier mongod.lock. Après cela, j'ai pu démarrer le service MongoDB correctement et cela a bien fonctionné.

0
Keijo

Ce n'est probablement pas la meilleure solution, mais si vous êtes désespéré, vous pouvez l'essayer. Il semblait que seul le journal était un problème pour moi, alors j'ai pris les mesures suivantes:

  1. Crée un nouveau répertoire de données . Peut-être/var/lib/mongodb2
  2. Mettez à jour votre fichier mongod.conf pour qu'il pointe vers le nouveau répertoire de données.
  3. Démarrer mongoDB. 
  4. S'il démarre avec succès, vous pouvez arrêter de nouveau mongo et continuer, sinon vous pouvez arrêter de lire ici. 
  5. Recherchez votre répertoire de données précédent et copiez les fichiers de votre/vos base (s) de base de données dans votre nouveau répertoire de données (par exemple, admin.0 admin.1 admin.ns, etc.)
  6. Démarrer mongoDB encore (toujours en utilisant le nouveau répertoire de données)

Une fois ces étapes terminées (moins de 5 minutes), j’étais opérationnel et toutes les données semblaient bien fonctionner.

0
Jage

Supprimer le fichier .lock du répertoire de données mongo dbpath fonctionne pour moi.

par exemple Sudo sudo rm {data-directory}/mongod.lock

0
Hemant Thorat

Si vous n'avez pas utilisé d'outils de surveillance tels que Bluepill ou Monit etc, vous devrez faire face à ce problème car après une panne du serveur pour une raison quelconque, mongo n'a pas démarré son démon automatiquement, vous devez le faire fonctionner manuellement. comme Sudo service mongod restart J'ai pensé à ce problème, mais il a besoin de quelques tâches supplémentaires, assurez-vous que votre chemin d'accès est bien à /etc/mongod.conf avant de démarrer votre démon mongo.

Pour moi c'était 

storage:
  dbPath: /var/lib/mongodb

Lorsque je saisis la commande mongod, il me montre MongoDB starting : pid=10795 port=27017 dbpath=/data/db 64-bit Host=xyz.com assurez-vous que votre chemin d'accès est le même que celui mentionné dans /etc/mongod.conf

Pour ce faire, vous pouvez taper Sudo mongod --dbpath /var/lib/mongodb puis utiliser la commande mongod pour démarrer votre processus mongo sur le dbpath souhaité.

FYI: démarrer votre processus mongo avec la commande mongod

0
Touseef Murtaza