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 se passe lorsque j'essaie de démarrer mongodb:
* Starting database mongodb [fail]
J'ai déjà essayé mongo --repair
J'ai créé chown et chmod dans var, lib et 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é le 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 toujours avoir le même problème.
Le journal indique que mongodb se termine car il existe un ancien fichier de verrouillage.
Si vous n’exécutez pas et n’exécutez pas de journalisation, supprimez le fichier de verrouillage, effectuez la réparation et redémarrez mongodb.
Si vous êtes ou étiez en train d'exécuter avec la journalisation activée, voir les documents Mongo DB correspondants . Notez qu'ils disent "Si vous utilisez la journalisation, vous ne devez pas effectuer de réparation pour restaurer l'état cohérent". Donc, si vous utilisiez la journalisation, la réparation aurait pu aggraver 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 exécuté mongod avant d'exécuter mongo?
J'ai suivi les instructions d'installation pour mongodb à partir de http://docs.mongodb.org/manual/tutorial/install-mongodb-on-os-x/ et j'ai eu la même erreur que lorsque j'ai exécuté mongo auparavant lancer le processus mongo avec mongod. Je pensais que l’installation de mongodb le lancerait aussi, mais vous devez le lancer manuellement avec mongod avant de faire autre chose qui nécessite mongodb.
C'est parce que le processus mongod est en panne, vous devez exécuter les commandes ci-dessous pour obtenir 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 aide.
Essayer
Sudo service mongodb start
Cela a résolu mon problème.
Essayez de lancer mongod avant mongo.
Sudo /usr/sbin/mongod sur mon opensuse
Cela a résolu mon problème,
Vérifiez l'espace libre de votre système de fichiers et augmentez-le s'il est moins. Cela pourrait aussi empêcher le mongo de commencer. Consultez 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
vous devez donc commencer par supprimer le fichier mongod.lock avec la commande ci-dessous
Sudo rm /var/lib/mongodb/mongod.lock
puis redémarrez le service Mongo en lançant la commande ci-dessous
Sudo service mongod restart
Vous pouvez vérifier avec netstat -anp | grep 27017 pour voir si le port est utilisé par un autre processus.
Pour référence future, procédez comme suit pour éviter des erreurs similaires:
1.Télécharger MondoDBhttps://www.mongodb.com/
2.Ouvrez un terminal et créez un cd dans vos téléchargementsdossier _ _ ou quel que soit le dossier dans lequel vous avez sauvegardé votre téléchargement mondodb (assurez-vous d'extraire votre dossier mongodb avant de vous y enregistrer)
cd Downloads
3.Mongodb dans 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.Alors, ouvrez/ouvrez votre .bash_profile
Pour ce faire, procédez comme suit:
Dans votre un nouveau terminal
1 .cd2.pwd3 .ls -l
Vérifiez si le fichier .bash_profile figure dans votre liste de fichiers sur votre terminal
si pas créer le -profil_bash
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 ensuite save. (Fichier Enregistrer ou commande S/CMD + S)
Step9: retour dans votre terminal:
source .bash_profile
Maintenant ouvrez deux terminaux .On va pour votre démon mondo l'autre pour votre mongo.
Terminal 1: Dans votre type de terminal: mongod
mongodb
Sortie: 
Terminal 2:
mongo
Sortie: 
Veillez également à ne pas commettre l'erreur de frappe suivante lors du démarrage de votre lecteur de disque sur votre terminal: Ceci est incorrect
mongo d
dégage le suivant error: Échec de la connexion à 127.0.0.1:27017, dans (vérification de la socket après erreur dans le socket), 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.
Dans Windows, exécutez cmd en tant qu'administrateur:
Créer le répertoire:
mkdir c:\mongo\data\db
Installer le service:
mongod.exe --install --logpath c:\mongo\logs --logappend --bind_ip 127.0.0.1 --dbpath c:\mongo\data\db --directoryperdb
Démarrer MongoDB:
net start MongoDB
4. Démarrer Mongo Shell:
c:\mongo\bin\mongo.exe
Cette solution fonctionne bien pour moi
Cela a fonctionné pour moi:
Sudo rm /var/lib/mongodb/mongod.lock
Sudo service mongodb restart
Cette erreur peut être due au paramètre IP de liaison de MongoDB. Vous pouvez vérifier le fichier de configuration de MongoDB en
$ 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 je devais supprimer le fichier de verrouillage de /data/db/ et après cela, j'ai lancé mongod et tout a commencé avec succès.
>rm /data/db/mongod.lock
>mongod
J'ai suivi la doc sur http://docs.mongodb.org/manual/tutorial/install-mongodb-on-red-hat/ .
Après la configuration et le redémarrage, j'ai exécuté Sudo service mongod start et obtenu ... [FAILED].
Enfin, j'ai découvert que mongod avait commencé. Je pense que le yum install l'a ajouté pour démarrer automatiquement.
Pour vérifier si votre mongod est en cours d'exécution: service mongod status.
J'espère que cela peut aider quelqu'un qui a le même problème.
Après des tentatives fréquentes, j'ai enfin 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
Bien que les réponses soient reçues, j'aimerais discuter des erreurs de réseau dans MongoDB.
Définir les problèmes d'écriture sécurisée n'est pas la méthode de preuve complète pour assurer la sécurité. Supposons que w=1 & j=true soient définis, que se passe-t-il si l'accusé de réception en écriture n'a pas été reçu du serveur? Eh bien, il est probable que cela ne soit pas arrivé, mais cela aurait pu arriver. La cause de ce problème est peut-être due à des erreurs de réseau. Il est possible que nous ne recevions pas de réponse affirmative. Ainsi, nous pouvons envoyer la demande de l'application via un pilote de la langue de choix. mongod peut le terminer avec succès. Une réinitialisation TCP peut ensuite avoir lieu. Le réseau peut en fait ê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. Ce n'est pas arrivé, mais cela peut arriver.
Pour un insert, il est possible de s'en prémunir. C'est possible parce que si nous laissons le pilote créer le _id et que nous effectuons un insert - nous pourrions le faire plusieurs fois, ce qui serait préjudiciable. Parce que si nous faisons cela 1st le temps et nous obtenons une erreur et nous ne sommes pas sûrs si l'insertion est terminée parce que c'est une erreur de réseau, alors nous pourrions le faire à nouveau. Et à condition que nous l'exécutions à nouveau, tyr l'exécutera avec le _id exact. Le pire des scénarios est que nous obtenons une erreur de clé en double lorsque nous essayons de l'insérer.
Cependant, une mise à jour est où le problème se produit. En particulier, la mise à jour qui n’est pas un élément puissant, qui incluait par exemple une commande $ink. Nous demandons donc à la base de données d’incrémenter un certain champ. Eh bien dans ce cas, si nous obtenons une erreur réseau et que nous ne savons pas si la mise à jour a eu lieu ou non. Maintenant, nous en savons peut-être assez sur les valeurs pour 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 base de données pour ce champ, il nous sera alors impossible de savoir si cela s'est produit ou non en cas d'erreur réseau. Ce type de problème est extrêmement rare avec un bon réseau.
Et si nous devons vraiment l'éviter à tout prix, nous devons transformer toutes nos mises à jour en insertions, en lisant toute la valeur du document dans la base de données, puis éventuellement en le supprimant et en l'insérant à nouveau ou simplement en l'insérant. un nouveau.
Les raisons pour lesquelles une application peut recevoir un message d'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
MongoDBse termine entre la réception de l'écriture et la réponse à celle-ci. - Le réseau tombe en panne entre le moment de l'écriture et le moment où le client reçoit une réponse à l'écriture.
Après avoir supprimé mongod.lock qui se trouvait dans le répertoire de données de mon système d'exploitation Windows, le même message d'erreur était toujours affiché. J'ai dû exécuter mongod avec --dbpath pour que la commande mongo s'exécute sans erreur.
Cela fonctionne pour moi. Pour arrêter l'utilisation de mongodb:
use admin
db.shutdownServer()
Et pour redémarrer:
Sudo service mongod restart
L'ajout du bac à PATH dans les variables d'environnement a aidé.
GOTO Installation Path et copiez le ../bin dans les variables PATH dans les variables d’environnement dans Windows
Il suffit d'exécuter mongod --repair à partir de C:\Program Files\MongoDB\Server\4.0\bin
Voici la doc https://docs.mongodb.com/manual/tutorial/recover-data-following-unexpected-shutdown/
Dans le terminal
1) Sudo service mongod start
2) mongo
1.Créez un nouveau dossier dans le lecteur D:/data/db
2.Open terminal on D:/data/db
3. Tapez Mongod et entrez.
4. Tapez mongo et entrez.
et votre mongodb a commencé ............
tapez windows + r et entrez les informations suivantes:
services.msc
démarrer MongoDB
maintenant, tapez "mongo" dans cmd dans le chemin respectif où mongo.exe est présent, il commencera à fonctionner.