Impossible de se connecter au serveur 127.0.0.1:27017

Je reçois l’erreur suivante:

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:/$ 

C’est ce qui arrive quand j’essaie de lancer mongodb:

 * Starting database mongodb [fail] 

J’ai déjà essayé le mongo --repair

J’ai créé chown et chmod en var, lib, data / db et log mongodb.

Je ne sais pas quoi faire d’autre. Aucune suggestion?

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 

MODIFIER:

J’ai enlevé la serrure puis réparé mongod et j’ai eu cette erreur:

 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 

alors je l’ai fait avec 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 

Mais ayant toujours le même problème.

Le journal indique que mongodb se termine car il existe un ancien fichier de locking.

Si vous ne travaillez pas avec la journalisation, supprimez-le, exécutez la réparation et redémarrez mongodb.

Si vous utilisez ou étiez en cours d’exécution avec la journalisation activée, consultez le document Mongo DB correspondant . Notez qu’ils disent “Si vous utilisez la journalisation, vous ne devez pas effectuer de réparation pour restaurer un état cohérent.” Donc, si vous journalisiez, la réparation a peut-être empiré les choses.

 Step 1: Remove lock file. sudo rm /var/lib/mongodb/mongod.lock Step 2: Repair mongodb. sudo mongod --repair Step 3: start mongodb. sudo start mongodb or sudo service mongodb start Step 4: Check status of mongodb. sudo status mongodb or sudo service mongodb status Step 5: Start mongo console. mongo 

Avez-vous couru mongod avant de courir mongo ?

J’ai suivi les instructions d’installation de mongodb depuis http://docs.mongodb.org/manual/tutorial/install-mongodb-on-os-x/ et j’ai eu la même erreur que lorsque j’ai couru mongo avant de lancer le processus mongo avec mongod . Je pensais que l’installation de mongodb le lancerait également, mais vous devez le lancer manuellement avec mongod avant de faire quoi que ce soit qui nécessite mongodb.

C’est parce que le processus mongod est en panne, vous devez exécuter les commandes ci-dessous afin de lancer le processus mongod:

 sudo service mongodb stop sudo rm /var/lib/mongodb/mongod.lock sudo mongod --repair --dbpath /var/lib/mongodb sudo mongod --fork --logpath /var/lib/mongodb/mongodb.log --dbpath /var/lib/mongodb sudo service mongodb start 

J’espère que cela vous aidera.

Essayer

 sudo service mongodb start 

Cela a résolu mon problème.

Vérifiez l’espace libre de votre système de fichiers et augmentez-le si c’est moins. Cela pourrait également causer le mongo de ne pas démarrer. Vérifiez le fichier /var/log/mongodb/mongodb.log.

 ERROR: Insufficient free space for journal files Please make at least 3379MB available in /var/lib/mongodb/journal or use --smallfiles 

Essayez de courir mongod avant mongo .

sudo /usr/sbin/mongod sur mon opensuse

Cela a résolu mon problème,

vous devez donc d’abord supprimer le fichier mongod.lock par la commande ci-dessous

 sudo rm /var/lib/mongodb/mongod.lock 

puis redémarrez le service mongo en émettant la commande ci-dessous

 sudo service mongod restart 

Vous pouvez vérifier avec netstat -anp | grep 27017 netstat -anp | grep 27017 pour voir si le port est utilisé par un autre processus.

Cela a fonctionné pour moi:

 sudo rm /var/lib/mongodb/mongod.lock sudo service mongodb restart 

Dans Windows, exécutez cmd en tant qu’administrateur:

  1. Créer le répertoire:

    mkdir c: \ mongo \ data \ db

  2. Service d’installation:

    mongod.exe –install –logpath c: \ mongo \ logs –logappend –bind_ip 127.0.0.1 –dbpath c: \ mongo \ data \ db –directoryperdb

  3. Démarrer MongoDB:

    net start MongoDB

4. Démarrer Mongo Shell:

 c:\mongo\bin\mongo.exe 

Cette solution fonctionne bien pour moi

J’ai suivi le document à l’ adresse http://docs.mongodb.org/manual/tutorial/install-mongodb-on-red-hat/ .

Après avoir configuré et redémarré, j’ai exécuté sudo service mongod start et obtenu ... [FAILED] .

Enfin, j’ai trouvé que mongod avait commencé. Je pense que le yum install ajouté au démarrage automatique.

Pour vérifier si votre mongod est en cours d’exécution: service mongod status .

J’espère que cela peut aider quelqu’un a le même problème.

Après de fréquentes tentatives, j’ai finalement résolu le problème …

 Step 1: ps aux | grep mongo Step 2: sudo rm /var/lib/mongodb/mongod.lock Step 3: sudo mongod --repair Step 4: mongo 

Cette erreur peut être causée par le paramètre IP de liaison de MongoDB. Vous pouvez vérifier le fichier de configuration de MongoDB par

 $ sudo vi /etc/mongodb.conf 

Dans mon cas, l’adresse IP de liaison est définie sur l’adresse intranet du serveur, comme suit:

 bind_ip = 10.10.1.14 #port = 27017 

J’ai donc donné à mongo un paramètre IP pour se connecter à shell par type:

 $ mongo 10.10.1.14 

N’oubliez pas de redémarrer le service mongodb si vous avez modifié la configuration.

J’ai mongo version 3.2.1 et j’ai dû supprimer le fichier de locking de /data/db/ et après cela, a lancé mongod et il a démarré avec succès.

 >rm /data/db/mongod.lock >mongod 

Pour référence future, suivez ces étapes pour éviter des erreurs similaires:

1.Téléchargez MondoDB https://www.mongodb.com/

2.Ouvrez un terminal et un CD dans votre dossier de téléchargements ou dans le dossier que vous avez enregistré lors de votre téléchargement de mondodb (assurez-vous d’extraire votre dossier mongodb avant d’y rentrer)

 cd Downloads 

3.Déplacer mongodb sur votre chemin usr / local

 sudo mv mongodb-osx-... /usr/local/mongodb 

4.cd dans votre dossier local

 cd /usr/local/mongodb 

5. créer un nouveau répertoire

 sudo mkdir -p /data/db 

6.cd dans le nouveau répertoire créé ci-dessus

 cd /data/db 

7.give mongo permisions

 sudo chown YourMacUserName /data/db 

8. Puis allez / ouvrez votre fichier .bash_profile

Pour ce faire, procédez comme suit:

Dans votre nouveau terminal

1 . cd 2 .pwd 3 . ls -l

Vérifiez si le fichier .bash_profile apparaît dans votre liste de fichiers sur votre terminal

sinon créer le -bash_profile

Création de .bash_profile:

Dans votre terminal

touchez .bash_profile

// ignore cette étape si vous avez déjà un fichier .bash_profile

Step8:

Suivant dans votre terminal:

 open .bash_profile 

Et dans votre fichier bash qui s’ouvre, ajoutez ce qui suit:

 MONGO_PATH=/usr/local/mongodb export PATH=$PATH:$MONGO_PATH/bin 

Et puis enregistrez (Fichier Enregistrer ou commander S / CMD + S)

Step9: retour dans votre terminal :

 source .bash_profile 

Ouvrez maintenant deux terminaux. L’un pour votre démon mondo l’autre pour votre mongo .

Terminal 1: dans votre type de terminal: mongod

 mongodb 

Sortie: Terminal Mongod

Terminal 2:

 mongo 

Sortie: Terminal Mongo

Assurez-vous également que vous ne faites pas la faute de frappe suivante au démarrage de votre mongod dans votre terminal: Ceci est incorrect

 mongo d 

émet l’ erreur suivante: Échec de la connexion à 127.0.0.1:27017, dans (vérification du socket pour erreur après sondage), raison: connexion refusée

C’est correct:

 mongod 

(Il ne devrait y avoir aucun espace entre les mots mongo et d .. mondod

Enfin, gardez toujours à l’esprit que vous devez exécuter mondod avant de lancer mongo sur vos terminaux .

Après avoir supprimé mongod.lock qui se trouvait dans le répertoire de données de mon système d’exploitation Windows, il affichait toujours le même message d’erreur. J’ai dû exécuter mongod avec –dbpath pour que la commande mongo soit exécutée sans erreurs.

Bien que les réponses soient reçues, je souhaiterais discuter des erreurs de réseau dans MongoDB .

Erreurs réseau MongoDB

Définir les problèmes d’écriture sécurisée n’est pas la méthode de preuve complète pour vous assurer que nous sums en sécurité. Supposons que w=1 & j=true soit défini, et si l’accusé de réception en écriture n’a pas été reçu du serveur? Eh bien, la probabilité est que cela ne s’est pas produit, mais cela aurait pu arriver. La raison pour laquelle cela a pu se produire est qu’il existe des erreurs de réseau – il y a des raisons pour lesquelles nous pourrions ne pas recevoir de réponse affirmative. Nous pouvons donc envoyer la demande depuis l’application via un pilote de langue de choix. mongod peut le terminer avec succès, puis il peut y avoir une réinitialisation TCP et le réseau peut être réinitialisé de manière à ne jamais recevoir de réponse. Donc, nous pourrions avoir une erreur et sur l’erreur, nous pourrions supposer que nous avons eu une erreur. Cela n’est pas arrivé, mais cela peut arriver.

Pour un insert, il est possible de s’en protéger. C’est possible parce que si nous laissons le pilote créer le _id et que nous faisons un insert, alors nous pourrions le faire plusieurs fois et cela nuirait. Parce que si nous faisons cette 1 ère fois et que nous obtenons une erreur et que nous ne sums pas sûrs que cette insertion se soit terminée parce que c’est une erreur de réseau, alors nous pourrions simplement recommencer. Et à condition que nous l’exécutions à nouveau, tyr pour l’exécuter avec le _id exact. Dans le pire des cas, nous obtiendrons une erreur de clé en double lorsque nous essayons de l’insérer.

Cependant, une mise à jour est l’endroit où le problème se produit. En particulier, la mise à jour qui n’est pas un élément puissant, par exemple une commande $ink . Nous disons donc à la firebase database d’incrémenter un certain champ. Eh bien dans ce cas, si nous obtenons une erreur de réseau et que nous ne soaps pas si la mise à jour a eu lieu ou non. Maintenant, peut-être que nous en soaps assez sur les valeurs que nous pouvons vérifier avec eux que la mise à jour a eu lieu, ce qui est bien. Mais si nous ne connaissons pas la valeur de départ dans la firebase database pour ce champ, il ne nous est pas possible de savoir si elle s’est produite ou non en cas d’erreur de réseau. Ce genre de problèmes est extrêmement rare avec un bon réseau.

Et si nous devons vraiment l’éviter à tout prix, nous devons activer toutes nos mises à jour en insérant la valeur totale du document dans la firebase database, puis en la supprimant et en l’insérant de nouveau ou en insérant simplement un nouveau.

Les raisons pour lesquelles une application peut recevoir une erreur même si l’écriture a réussi:

  • La connexion réseau TCP entre l’application et le serveur a été réinitialisée après que le serveur a reçu une écriture, mais avant qu’une réponse puisse être envoyée.
  • Le serveur MongoDB termine entre recevoir l’écriture et y répondre.
  • Le réseau tombe en panne entre l’heure de l’écriture et l’heure à laquelle le client reçoit une réponse à l’écriture.

L’ajout du bac à PATH dans les variables d’environnement a aidé.

Chemin d’installation de GOTO et copiez le fichier ../bin vers les variables PATH dans les variables d’environnement de Windows

Jeu 11 octobre 12:05:42 [initandlisten] Impossible de vérifier les fichiers journaux en raison de: boost :: fileystem :: basic_directory_iterator constructeur: Aucun fichier ou répertoire de ce type: “/ data / db / journal” jeu 11 octobre 12:05: 42 [initandlisten] a fini de vérifier les dbs

Cette ligne pas un tel fichier ou répertoire alors créez le dossier / data / db sur root, puis essayez “mongod” en espérant que cela fonctionnera

tapez windows + r et entrez les informations suivantes

services.msc

commencer MongoDB

Maintenant, tapez “mongo” dans cmd dans le chemin respectif où mongo.exe est présent, il va commencer à fonctionner.

1.Créez un nouveau dossier dans le lecteur D: / data / db

2. Ouvrir le terminal sur D: / data / db

3. Tapez mongod et entrez.

4. Tapez mongo et entrez.

et votre mongodb a fait des efforts …………