mongodb connection timed out erreur

J'ai utilisé la base de données mongodb et node.js v12.0.10 pour le raccordement et la mise à jour de collection mongodb.
code de connexion est la suivante:

 async.parallel({
        RE5: function (cb) {
            MongoClient.connect(config.riskEngineDB, function (err, r5DB) {
                cb(err, r5DB);
            })
        },
        MDB: function (cb) {
            MongoClient.connect(config.monitoringDB, function (err, mDB) {
                cb(err, mDB);
            })
        }
    },
    function (err, DBs) {
        assert.equal(null, err);
        console.log("Connected correctly to Dbs");
        //..doing updates..

 })

après un certain temps d'exécution, le script imprimé le message d'erreur suivant:

  { [MongoError: connection 39 to 127.0.0.1:27017 timed out]
  name: 'MongoError',
  message: 'connection 39 to 127.0.0.1:27017 timed out' }

Pour votre information, j'ai utilisé de différentes options de connexions de mongodb, mais elle n'a pas de sens.

OriginalL'auteur Armen Chakhalyan | 2016-10-24

  1. 7

    J'ai eu une expérience similaire, en raison d'une requête qui a pris trop de temps à répondre

    vous avez 2 configurable délais d'attente dans le nœud de mongo pilote:

    connectTimeoutMS et socketTimeoutMS, à la fois en défaut de 30sec ( http://mongodb.github.io/node-mongodb-native/2.2/reference/connecting/connection-settings/ )

    si votre requête est plus de 30sec à envoyer son premier résultat, il en terminerai avec une connection timed out erreur.

    si votre requête prend plus de 30sec entre les deux résultats, il va probablement fin à cette connexion de fermeture en raison de rétrécissement de groupe.

    Vous souhaiterez peut-être augmenter les délais d'attente, ou assurez-vous que votre requête est assez rapide ( créer un index par exemple). Je vous conseille d'accélérer la requête, car l'augmentation de délais d'attente peuvent avoir des performances des inconvénients.

    Est-il possible d'avoir quelques informations sur les requêtes qui ont été trop long? Dans mes logs, je n'ai que le message d'erreur indiquant que le délai de connexion mais je ne trouve pas lequel. Merci!!!!
    Je suis tout simplement de la manipulation de l'erreur côté client et de la journalisation de la requête ici.
    Ohh ok! Merci!!!!

    OriginalL'auteur Charly Koza

  2. 0

    J'ai voulu donner cette réponse comme il est venu dans une mongodb examen de la question à la ligne gratuit mongodb université. Il est complet et fournit de la documentation.

    J'ai pensé à elle et va nettoyer la confusion causée principalement par un manque d'explication dans les leçons. Je ne suis pas critique, mais une explication supplémentaire est nécessaire pour bien répondre à cette question.

    Tout d'abord, lors de la connexion à mongodb par le biais d'une application, vous serez à l'aide d'un pilote. Ce pilote a barriors elle doit passer à travers pour faire quelque chose avec le serveur mongodb. Quand vous comprenez ce barrior concept vous sera alors comprendre cette question.

    Chaque connexion qui est en fait une liste de choses doivent se produire afin de passer devant les obstacles et en fin de compte mener une écriture ou en lecture operaton.

    Visuellement, vous pouvez la considérer comme ceci:

    IO /demande d'écriture se produit ==> || 1er barrière --> (serveur de sélection - (err -> serverSelectionTimeoutMS ) ) ==> || 2e barrière --> connexion au serveur (err -> 'connectionTimeoutMS') ==> || 3ème barrière --> socket de connexion (err -> 'socketTimeoutMS') ==****Écrire Préoccupation Options Obstacles**==> || 4e barrière --> "ecrire préoccupation spécification { w: <valeur>, j: <boolean>, wtimeout: <nombre> }' ==> || 5e barrière --> une réussite en écriture /lecture

    ******* Remarque: n'importe où le long de cette canalisation un falure se base sur la logique d'une écriture réussie /opération de lecture peut ne pas se produire.

    Nous pouvons penser à des barrières 1 - 3 que d'un réseau de barrières de connectivité. Si le réseau est en panne ou d'avoir des problèmes ce sont les problèmes que l'on aurait un avis par le biais des délais d'attente et la gestion des exceptions de ces délais d'attente. Ce qu'on a à comprendre, c'est que vous ne pouvez pas effectuer une opération d'écriture à écrire des préoccupations si vous ne pouvez pas vous connecter au serveur en premier lieu. La leçon pourrait ont illustré ces points.

    La première série d'obstacles à une écriture ou de lecture de fonctionnement sont d'avoir établi une connexion au serveur... Ceci est illustré ci-dessus par barries 1 - 3.

    Puis, après vous avez une connexion au serveur par l'intermédiaire d'un cluster et ou jeu de réplicas de clusters ensuite, vous pouvez définir écrire préoccupations.

    Après, nous avons établi une connexion à une écriture ne peut pas se produire pour des raisons autres que la connectivité réseau. Ceux-ci peuvent être les collisions de données ou d'une extrême ventilation de l'écrit à cause de DDOS ou de piratage ou en général pas assez d'espace sur un serveur pour que les données soient écrites sur le serveur. Le Point est, quelque chose d'autre peut provoquer une réaction à l'écriture, à la préoccupation et donc le contrôle par le biais d'options pour gérer écrire préoccupation des erreurs.

    J'espère que cette aide, car il m'a fait comprendre la question et la bonne réponse en conséquence. Surtout, nous n'étions pas vraiment taugh ce donc j'espère que cela aide les autres à apprendre et à comprendre cette boucle de rétroaction.

    Voici quelques articles que j'ai lu pour m'aider à arriver à cette réponse /conclusion. Si quelqu'un a une meilleure ou d'amélioration sur mes explications, n'hésitez pas à fournir de la rétroaction.

    https://scalegrid.io/blog/understanding-mongodb-client-timeout-options/

    https://scalegrid.io/blog/mongodb-write-concern-3-must-know-caveats/

    https://docs.mongodb.com/manual/reference/write-concern/

    https://www.mongodb.com/blog/post/server-selection-next-generation-mongodb-drivers

    OriginalL'auteur Christian Matthew