Mongoose: { useUnifiedTopology: true } conduit à une erreur de connexion MongoDB : MongoTimeoutError : la sélection du serveur a expiré après 30000 ms

Quelle image de docker utilisez-vous ? De plus, avez-vous une trace de pile pour le message « La sélection du serveur a expiré » ?

Salut, je viens juste d'entrer ici pour signaler que j'ai eu le même problème.

Je n'utilise moi-même ni Docker ni aucune vm. A noter également que cela ne semble pas se produire tout le temps, mais aujourd'hui, je n'ai pu récupérer aucune de mes données en raison de délais d'attente (30k), et le problème a été immédiatement résolu lors de la suppression du drapeau useUnifiedTopology .

Je me connecte à un cluster Atlas.

Mangouste est 5.7.1
MongoDb est 3.3.2
Le nœud est 12.9.1

Connexion comme ceci :

mongoose.createConnection(uri,
    {
        useCreateIndex: true,
        useNewUrlParser: true,
        useUnifiedTopology: true, // commented out currently
        dbName: db_name
    });

Le modèle est créé comme ceci :

import mongoose from 'mongoose';
import * as db_conns from '../db-connections'; // this is an object of connections generated via createConnection

// ... schema definition, for a model called 'article' from a collection called 'article'

// `site_content` is the name of a connection
export default db_conns.connections.site_content.model(`article`, schema, `article`);

Ensuite, il est récupéré comme ceci :

// ...
await query.model.find(query_expr).limit(30); // query_expr can change, however even an empty expression ({}) will cause the same issue
// ...

L'appel find se bloque et génère l'erreur de délai d'attente.

@vkarpov15 J'utilise la dernière image mongo qui fournit MongoDB v4.2.0.
https://hub.docker.com/_/mongo

J'obtiens également la même erreur après avoir ajouté { useUnifiedTopology: true } , bien que l'erreur se produise de manière aléatoire. Il y a définitivement quelque chose qui ne va pas. J'utilise la dernière image mongo.

mangouste
.connect(process.env.MONGO_URI, {
useUnifiedTopology : vrai,
useNewUrlParser : vrai,
})
.then(() => console.log('DB Connected!'))
.catch(err => {
console.log(Erreur, err.message);
});
Quand il démarre, j'obtiens à la console:
[Fonction : Erreur] { stackTraceLimit : 16, prepareStackTrace : undefined } connexion 0 à acccluster-shard-00-01-xx47j.mongodb. net : 27017 fermé

Des solutions ? Même moi, je suis confronté à ce problème maintenant...

J'ai le même problème. Je suis un programmeur junior et c'est la première fois que j'utilise nodejs-express-graphql-mongoose-mongodbAtlas.

(nœud : 9392) UnhandledPromiseRejectionWarning : MongoTimeoutError : la sélection du serveur a expiré après 30 000 ms
à Timeout.setTimeout (MyAppPathgraphql2node_modulesmongodblibcoresdamtopology.js:850:16)
à ontimeout (timers.js:436:11)
à tryOnTimeout (timers.js:300:5)
à listOnTimeout (timers.js:263:5)
à Timer.processTimers (timers.js:223:10)
(nœud : 9392) UnhandledPromiseRejectionWarning : rejet de promesse non géré. Cette erreur provenait soit du lancement d'une fonction asynchrone sans bloc catch, soit du rejet d'une promesse qui n'était pas gérée avec .catch(). (identifiant de rejet : 1)
(nœud : 9392) [DEP0018] Avertissement de dépréciation : les refus de promesse non gérés sont dépréciés. À l'avenir, les refus de promesses qui ne sont pas traités mettront fin au processus Node.js avec un code de sortie différent de zéro.
événements.js:174
jeter euh; // Evénement 'erreur' non géré
^

Erreur : lire ECONNRESET
à TLSWrap.onStreamRead (interne/stream_base_commons.js:111:27)
Événement « erreur » émis à :
chez TLSSocket.(MyAppPathnode_modulesmongodblibcoreconnectionconnection.js:321:10)
à Object.onceWrapper (events.js:286:20)
à TLSSocket.emit (events.js:198:13)
àémettreErrorNT (interne/streams/destroy.js:91:8)
àémettreErrorAndCloseNT (interne/streams/destroy.js:59:3)
à process._tickCallback (interne/process/next_tick.js:63:19)

Nous obtenons également la même erreur sur notre serveur de production après avoir activé useUnifiedTopology .

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout [as _onTimeout] (/opt/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

J'ai commencé à rencontrer un autre problème maintenant
MaxListenersExceededWarning : fuite de mémoire EventEmitter possible détectée. 11 topologyDescriptionChanged listeners ajoutés.

Lorsque j'ai recherché cet avertissement, je suis tombé sur ce document mongoDB
https://jira.mongodb.org/browse/NODE-2123

Il indique à la fois les erreurs
"La sélection du serveur a expiré" ainsi que "MaxListenersExceededWarning" et les deux erreurs sont dues au changement de topologie unifiée. Je suppose que c'était un changement décisif qui n'a jamais été mentionné.

Étant donné que je rencontre cette erreur sur mon serveur en direct, je n'ai pas d'autre choix que de définir { useUnifiedTopology: false }. J'espère que quelqu'un de la communauté pourra se concentrer sur ce problème et le résoudre ou fournir des suggestions pour le résoudre.

Je reçois également les deux erreurs (la sélection du serveur a expiré après 30000 ms et MaxListenersExceededWarning: Possible fuite de mémoire EventEmitter détectée. 11 ) lors de l'utilisation de useUnifiedTopology, donc cela arrive à tous ceux qui utilisent cette option, je suppose.

J'ai essayé de le reproduire, mais je n'ai pas pu le reproduire. J'ai essayé quelques options :

1) Tuer le serveur juste avant d'interroger

2) Interrogation avec une connexion déconnectée

3) Exécution réussie d'une requête

Je n'ai pas encore vu ce message d'erreur dans tous les cas. Pouvez-vous modifier le script ci-dessous pour illustrer ce problème ?

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017/test');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));

  console.log('Query...');
  await Model.findOne();
  console.log('Done');
}

Ou au moins fournissez des informations sur la version de Mongoose que vous utilisez ; que vous utilisiez un serveur autonome, un jeu de réplicas ou un cluster partitionné ; et si vous utilisez Mongoose directement ou via un autre module npm ?

Je suis assez convaincu que ce n'est pas un problème avec la mangouste, mais avec la Mongo elle-même.

@vkarpov15 , s'il vous plaît voir mon commentaire , j'y ai décrit mon environnement. J'utilise directement la mangouste.

@vkarpov15 pour moi, ce problème apparaît de manière aléatoire tous les 2-3 jours lorsque le serveur est en cours d'exécution, donc même si je vous fournis le code, vous devrez surveiller le serveur en continu.

Quelqu'un a-t-il contourné ce problème ?

Quelqu'un a-t-il contourné ce problème ?

Vous ne pouvez tout simplement pas utiliser ce drapeau pour le moment. Mongo vous avertira qu'il sera désactivé à l'avenir ou quelque chose du genre, mais pour le moment, il semble résoudre totalement ce problème.

Quelqu'un a-t-il contourné ce problème ?

Vous ne pouvez tout simplement pas utiliser ce drapeau pour le moment. Mongo vous avertira qu'il sera désactivé à l'avenir ou quelque chose du genre, mais pour le moment, il semble résoudre totalement ce problème.

quand je n'utilise pas le drapeau useUnifiedTopology: true , j'ai cette erreur et l'application s'est arrêtée,
mangouste veriosn: 5.7.4

Peut confirmer que commenter useUnifiedTopology résout le problème dans ma version. Se produisant également de manière (apparemment) aléatoire.

@rpedroni Malheureusement, ce n'est pas pour nous...

Se passe aussi ici. Notre serveur de production répond avec le message ci-dessous. Je suppose que je vais commenter useUnifiedTopology pour le moment

Options de connexion MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Journal du serveur

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Nous avons également ce problème et nous n'utilisons pas de mangouste. Il semble que ce soit un problème avec le pilote MongoDB pour Node.js lui-même. Le problème a également été signalé ici https://jira.mongodb.org/browse/NODE-2249
La version 3.3.3 du pilote qui a été publiée aujourd'hui devrait ajouter plus de détails au MongoTimeoutError . Il est également recommandé de mettre à jour le pilote en raison d'une correction de bogue.

Cette erreur est le résultat de l'incapacité du pilote à se connecter à un serveur satisfaisant la préférence de lecture d'une opération donnée (ou connexion initiale). Cela peut être dû à un certain nombre de raisons, notamment l'invalidité de votre chaîne de connexion ou l'arrêt des nœuds de votre cluster. Si vous effectuez la mise à jour vers la dernière version 3.3.3 du pilote, nous incluons un nouveau champ de raison avec MongoTimeoutError qui nous aidera à approfondir votre enquête. De plus, cette version inclut un correctif de bogue qui entraînerait une erreur de délai d'attente lors de la connexion initiale si un membre d'un jeu de réplicas n'était pas disponible. Veuillez mettre à jour votre pilote et nous faire savoir si vous continuez à rencontrer ce problème.

Cité de https://jira.mongodb.org/browse/NODE-2249?focusedCommentId=2485028&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment -2485028

Idem ici, se produit à la fois dans le développement et la production, en se connectant à Mongo Atlas :(

Vous avez également ce problème de connexion à l'atlas mongodb. Cela se produit généralement après qu'atlas ait redémarré ou mis à jour le serveur ou quelque chose du genre.

Je ne peux donc toujours pas reproduire cela localement avec un jeu de répliques. Le script ci-dessous continue d'exécuter les requêtes avec succès même avec le basculement du jeu de réplicas ou la suppression du principal. N'obtenez aucune erreur de délai d'attente de sélection de serveur :

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017,localhost:27018,localhost:27019/test?replicaSet=rs');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));


  while (true) {
    console.log(new Date(), 'Query...');
    await Model.findOne();
    await new Promise(resolve => setTimeout(resolve, 5000));
  }
} 

Ma meilleure supposition est que l'explication de [email protected] (que j'enverrai dans quelques heures) et voyez si ce problème persiste.

De plus, quelqu'un sait-il s'il existe un moyen de déclencher un redémarrage dans Atlas ? Peut-être que ce problème ne se produit que si vous utilisez Atlas ?

@ vkarpov15 Je pense que vous devez mettre en pause/reprendre le cluster pour déclencher un redémarrage. Ce n'est possible que sur les tailles M10+.
Je me demande aussi si cela pourrait être un problème d'Atlas à la place. Je n'ai pas encore pu tester le pilote MongoDB mis à jour, mais je ferai un rapport ici une fois que je le ferai.

J'ai également le même problème aujourd'hui avec le niveau gratuit d'Atlas, quel que soit l'indicateur useUnifiedTopology. Erreur : MongoTimeoutError: Server selection timed out after 30000 ms

Je peux obtenir une connexion en utilisant un autre service MongoDB tel que mLab.

J'avais le même problème et cela a fini par être quelque chose d'un peu stupide, mais je le partagerai quand même car cela peut aider quelqu'un qui se retrouve ici aussi.

J'ai vérifié le champ "raison" dans MongoTimeoutError et il a dit "MongoError: bad auth Authentication failed".
C'est à ce moment-là que j'ai réalisé que j'utilisais le mot de passe mongoDB dans ma chaîne de connexion et non le mot de passe utilisateur.
Maintenant ça marche bien.

Si vous utilisez MongoDB Atlas, vous devez ajouter votre adresse IP à la liste blanche.

Accédez à Accès réseau, modifiez l'adresse IP actuelle et cliquez sur Autoriser l'accès depuis n'importe où.

Je suis uniquement confronté à ce problème lors de l'utilisation d'Atlas. J'ai essayé d'ajouter 0.0.0.0/0 IP dans la liste blanche mais cela n'a pas non plus fonctionné.

J'utilise:

• mangouste : 5.7.6
• nœud : v10.16.3
• Niveau gratuit d'Atlas

Impossible de se reproduire sur le serveur mongodb local. Là, chaque requête fonctionne avec succès.

Cela n'a rien à voir avec l'accès. J'ai un accès 0/0/0/0 et cela se produit
chaque fois que le serveur redémarre sur atlas. Vous pouvez reproduire en créant un multi-nœud
cluster (m10+) et en définissant l'heure de maintenance planifiée. Puis courez longtemps
service en cours d'exécution et il devrait produire l'erreur lorsqu'il redémarre.

Le mercredi 23 octobre 2019, 7h42 Mohammad Mazedul Islam, <
[email protected]> a écrit :

Je suis uniquement confronté à ce problème lors de l'utilisation d'Atlas. j'ai essayé d'ajouter
0.0.0.0/0 IP dans la liste blanche mais cela ne fonctionnait pas non plus.

J'utilise:

• mangouste : 5.7.6
• nœud : v10.16.3
• Niveau gratuit d'Atlas

Impossible de se reproduire sur le serveur mongodb local. Là, chaque requête fonctionne
avec succès.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
Https://github.com/Automattic/mongoose/issues/8180?email_source=notifications&email_token=AAUHUCYYQIQ5U42IBYT7CQTQQA2B7A5CNFSM4IYQ3ZB2YY3PNVWWK3TUL52HS4DFVREXG43VMHJZW63LNMVDC540
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAUHUCY5SNFGGCPTGW6GH5DQQA2B7ANCNFSM4IYQ3ZBQ
.

J'avais aussi ce problème. Mais maintenant, après avoir mis à la fois 0.0.0.0/0 et mon adresse IP sur la liste blanche d'atlas, le problème est résolu.

https://jira.mongodb.org/browse/NODE-2147

~Ce n'est qu'un problème avec MongoDB Atlas.~

J'ai un problème avec MongoDB Atlas.

J'ai le même problème avec MongoDB normal.

J'ai réussi à reproduire la condition qui provoque "MongoTimeoutError: La sélection du serveur a expiré après 30000" à l'aide de docker-compose.
https://github.com/anzairyo0127/mongodb-connection-bug

Commencez par démarrer cette application

$ docker-compose up -d
$ docker-compose exec a mongo /tmp/conf/init.js
$ docker-compose exec node sh
$ npm i && npm run build
$ npm run start

> 0times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> 1times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> xtimes
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> ......



md5-cc5c53b3c0322ef988c85b63b4bb6c4e



$ docker-compose restart a b c



md5-788ff0ed4e46daf35b1b8594351b929f



> xtimes
> waiting ....
> (node: 4360) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms
> at Timeout.setTimeout [as _onTimeout] (/var/work/node_modules/mongodb/lib/core/sdam/topology.js:878:9)
> at ontimeout (timers.js: 436: 11)
> at tryOnTimeout (timers.js: 300: 5)
> at listOnTimeout (timers.js: 263: 5)
> at Timer.processTimers (timers.js: 223: 10)
> (node: 4360) UnhandledPromiseRejectionWarning: Unhandled promise rejection.This error originated either by throwing inside of an> async function without a catch block, or by rejecting a promise which was not handled with .catch (). (rejection id: 1)
> (node: 4360) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that
> are not handled will terminate the Node.js process with a non-zero exit code.

@anzairyo0127 pouvez-vous essayer la même chose avec la dernière bibliothèque mongodb 3.3.3 ?

@rvanmil je peux le reproduire dans la ver3.3.3.

Il semble que cette erreur se produise lorsque le mongoDB est en configuration de réplication et que l'une des instances (probablement l'instance principale) reçoit une commande juste avant de s'arrêter ou juste après son démarrage.
Je pense que la raison pour laquelle cela se produit fréquemment sur MongoDB Atlas est que MongoDB Atlas envoie régulièrement des requêtes au cluster pour surveillance.

Des solutions ? Ce problème est....

Le même problème depuis plus d'1 mois et ce n'est pas encore résolu -_-

La mise à jour vers [email protected] l'a résolu pour moi.

@octavioamu Pouvez-vous fournir plus de détails ? Quelle version de la base de données MongoDB [cluster] exécutiez-vous avant la 4.2 ? Quelle version des packages mongoose et mongodb npm utilisez-vous et les avez-vous mis à niveau ? Depuis combien de temps utilisez-vous 4.2 pour être sûr qu'il est résolu dans cette version ?

désolé je ne sais pas quelle version a été installée, probablement une très ancienne car je n'ai pas travaillé avec mongo pendant un moment.
La version mangouste est sur @5.7.7
Le message était permanent pour moi et une fois que j'ai installé [email protected] (installé via brew), le message s'est arrêté.

Si je définis {useUnifiedTopology: false} j'obtiens un échec d'authentification

(node:19948) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoError: Authentication failed.]

et si je mets {useUnifiedTopology: true} , j'obtiens un délai d'attente

(node:20213) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms

Le mot de passe est définitivement correct. Cela peut être reproduit sur un système local avec les dernières versions de tout et LST Node.js. Cependant, l'utilisation d'une chaîne de connexion sans aucun type d'authentification semble fonctionner localement. Donc, si je définis par exemple const MONGODB_URI = "mongodb://localhost/fullstack" problème de délai d'attente disparaît. Peut-être que ce problème a quelque chose à voir avec l'authentification ? Voici MWE qui reproduit le problème sur ma configuration locale :

const mongoose = require('mongoose')
// const url = 'mongodb://fullstack:fullstack@localhost/fullstack'
const url = 'mongodb://localhost/fullstack'
console.log('Connection url = ', url, 'connecting')
mongoose.connect(url, { useNewUrlParser: true, useUnifiedTopology: true })
console.log('Connected.')
mongoose.connection.close()

J'ai utilisé la dernière image Docker pour la configuration de MongoDB.

Se passe aussi ici. Notre serveur de production répond avec le message ci-dessous. Je suppose que je vais commenter useUnifiedTopology pour le moment

Options de connexion MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Journal du serveur

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Se passe aussi ici. Notre serveur de production répond avec le message ci-dessous. Je suppose que je vais commenter useUnifiedTopology pour le moment

Options de connexion MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Journal du serveur

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

J'utilise mongo db atlas et nous sommes confrontés au même problème.

dub-tools-jobs: orders - error MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 29 13:16:30 app/worker.1:      at Timeout.setTimeout [as _onTimeout] (/app/node_modules/mongoose/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 29 13:16:30 app/worker.1:     at ontimeout (timers.js:436:11) 
Oct 29 13:16:30 app/worker.1:     at tryOnTimeout (timers.js:300:5) 
Oct 29 13:16:30 app/worker.1:     at listOnTimeout (timers.js:263:5) 
Oct 29 13:16:30 app/worker.1:     at Timer.processTimers (timers.js:223:10) +2m

tout cela s'est produit en commentant useUnifiedTopology comme une recommandation suggérée

// mongodb connections
var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    // useUnifiedTopology: true,      
    promiseLibrary: global.Promise
};

en utilisant mongoose et mongoDB atlas, assurez-vous que les options sont comme ça :
mongoose.connect(DATABASE_URL, { useNewUrlParser : true, useUnifiedTopology : true })

Après cela, si le délai d'attente arrive, vous devez ajouter votre adresse IP à la liste blanche de mongoDB en accédant à l'accès réseau dans mongoDB

Comme d'autres, cette erreur fait planter mon application tous les quelques jours et je peux confirmer que cela n'est pas lié à l'accès ou à la liste blanche de l'adresse IP.

J'utilise:

• mangouste : 5.7.6
• nœud : v10.16.3
• Niveau gratuit d'Atlas

Pour l'instant, je commenterai également useUnifiedTopology: true . Il semble que cela puisse être lié à Atlas ou à mongo, comme d'autres l'ont dit.

Il s'agit d'un problème avec les serveurs MongoDB du jeu de réplicas et une solution est en cours d'élaboration ici par les ingénieurs de MongoDB

https://jira.mongodb.org/browse/NODE-2267

@ vkarpov15 peut probablement clore ce problème car il n'a rien à voir avec Mongoose.

lorsque votre adresse IP actuelle change pour une raison quelconque, la connexion échoue, vous devez la modifier dans la liste blanche des adresses IP d'accès au réseau et utiliser l'adresse IP actuelle

Salut! Je m'appelle Matt et je fais partie de l'équipe des pilotes de MongoDB. Nous sommes vraiment désolés pour les pannes auxquelles vous avez tous été confrontés, et je voulais faire une petite mise à jour sur le problème :

Nous sommes en train d'essayer de supprimer progressivement nos types de topologie hérités, ce qui s'est avéré être un processus très chirurgical. L'élimination progressive de ces types contribuera à réduire considérablement la charge de maintenance du pilote, et nous espérons que cela signifie un pilote plus stable et efficace pour nos utilisateurs. En particulier, lors de l'introduction de la "topologie unifiée", nous n'avons pas également introduit la réécriture du pool de connexions dans le but de réduire le potentiel d'erreur. Il s'avère que le pool de connexions était plus étroitement lié aux types de topologie que nous ne l'avions prévu et, par conséquent, nous avons connu quelques régressions, en particulier autour de la surveillance des serveurs.

Ce matin, j'ai poussé une v3.3.4-rc0 du pilote qui devrait résoudre les problèmes auxquels vous avez été confronté. Nous vous serions extrêmement reconnaissants si vous pouviez essayer cette version et nous faire part de votre expérience. J'ai laissé des commentaires sur chacun des tickets existants liés à ce problème sur NODE-2267 , mais n'hésitez pas à y ouvrir des problèmes supplémentaires si vous en rencontrez.

Je peux confirmer que la 3.3.4-rc0 a résolu le problème 👍 Je fournirai des résultats de test plus détaillés plus tard.

après avoir changé ma version mongodb dans package.json en
"mongodb": "3.3.4-rc0",
J'obtiens toujours une erreur (cette erreur ne se produit pas lorsque la version mongodb est sur 3.3.3) :

==============================================
npm ERR ! chemin /tmp/app/node_modules/npm/node_modules/abbrev
npm ERR ! code ENOENT
npm ERR ! errno -2
npm ERR ! renommer l'appel système
npm ERR ! enoent ENOENT : aucun fichier ou répertoire de ce type, renommez '/tmp/app/node_modules/npm/node_modules/abbrev' -> '/tmp/app/node_modules/npm/node_modules/.abbrev.DELETE'
npm ERR ! enoent Ceci est lié au fait que npm ne parvient pas à trouver un fichier.
npm ERR ! énonce
npm ERR ! Un journal complet de cette course peut être trouvé dans:
npm ERR ! /home/vcap/.npm/_logs/2019-11-06T17_19_55_661Z-debug.log
[31;1m ERREUR [0m Impossible de créer des dépendances : état de sortie 254
Échec de la compilation du droplet : échec de l'exécution de tous les scripts d'approvisionnement : état de sortie 14
État de sortie 223

===================================
ma version npm est npm à 6.11.3.

Cette erreur est-elle liée à cette nouvelle version de mongodb v3.3.4-rc0 ?

@zhenwan cela ressemble à un problème de téléchargement du package abbrev . Je suppose qu'il y a des problèmes avec votre package-lock.json , veuillez essayer de supprimer ce fichier et d'exécuter à nouveau npm install .

J'ai pu reproduire l'erreur et vérifier si elle a été résolue avec le pilote v3.3.4-rc0 en utilisant la configuration suivante :

• Serveur Web Node.js exposant une simple api http GET /api/todos qui interroge une collection MongoDB todo qui contient des exemples de données
• Script qui appelle l'api toutes les 500ms s'exécutant localement sur ma machine
• Une fois le script en cours d'exécution, déclenchez un failover (redémarrez le primaire) sur MongoDB (sur Atlas j'ai pu le faire sur un cluster M10 en sélectionnant l'option de menu "Test Failover")

Les résultats de ce test étaient les suivants :

✅ Mongodb Node.js 3.3.2 useUnifiedTopology false

> MongoDB failover triggered
> MongoDB 'reconnect' event
> A few http calls with +/- 5000ms response times
> MongoDB failover finished
> Everything back to normal

❌ Mongodb Node.js 3.3.2 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'close' event
> Many MongoNetworkError errors
    {
      "name": "MongoNetworkError",
      "stack": "Error: connect ECONNREFUSED <ip_redacted>:27017
          at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1128:14)",
      "errorLabels": [
        "TransientTransactionError"
      ]
    }
> EventEmitter memory leak warning
    (node:18) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 topologyDescriptionChanged listeners added to [NativeTopology]. Use emitter.setMaxListeners() to increase limit
> Many MongoTimeoutError errors
    {
      "name": "MongoTimeoutError",
      "stack": "MongoTimeoutError: Server selection timed out after 30000 ms
          at Timeout._onTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
          at listOnTimeout (internal/timers.js:531:17)
          at processTimers (internal/timers.js:475:7)"
    }
> MongoDB failover finished
> Server unable to recover MongoDB connection
> Server restarted manually
> Everything back to normal

⚠️ Mongodb Node.js 3.3.4-rc0 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'reconnect' event expected but not seen
> A few http calls with +/- 5000ms response times
> A couple failed http calls:
    {
      "name": "MongoError",
      "stack": "MongoError: Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585
          at Connection.<anonymous> (/app/node_modules/mongodb/lib/core/connection/pool.js:451:61)
          at Connection.emit (events.js:210:5)
          at processMessage (/app/node_modules/mongodb/lib/core/connection/connection.js:368:10)
          at TLSSocket.<anonymous> (/app/node_modules/mongodb/lib/core/connection/connection.js:537:15)
          at TLSSocket.emit (events.js:210:5)
          at addChunk (_stream_readable.js:308:12)
          at readableAddChunk (_stream_readable.js:289:11)
          at TLSSocket.Readable.push (_stream_readable.js:223:10)
          at TLSWrap.onStreamRead (internal/stream_base_commons.js:182:23)",
      "ok": 0,
      "errmsg": "Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585",
      "code": 211,
      "codeName": "KeyNotFound"
    }
> MongoDB failover finished
> Everything back to normal

Il semble donc que cela fonctionne avec v3.3.4-rc0 , le serveur est capable de récupérer la connexion et de reprendre le service des données de MongoDB. Il reste cependant deux problèmes :

• L'événement 'reconnect' semble être manquant
• Quelques requêtes échouent avec un message d'erreur "Lecteur de cache Aucune clé trouvée pour HMAC valide pour le temps"

@mbroadst oui, la suppression de package-lock.json a résolu mon problème de fichier manquant.

Mais j'ai toujours l'erreur :
2019-11-06T12:52:10.35-0600 [CELL/0] OUT Le conteneur est devenu sain
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR /home/vcap/app/node_modules/connect-mongo/src/index.js:135
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR lancer err
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR ^
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] Erreur ERR : la sélection du serveur a expiré après 30000 ms
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR à Timeout.setTimeout [as _onTimeout] (/home/vcap/app/node_modules/connect-mongo/node_modules/mongodb/lib/core /sdam/topologie.js:878:9)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR à ontimeout (timers.js:469:11)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR à tryOnTimeout (timers.js:304:5)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR à Timer.listOnTimeout (timers.js:264:5)
2019-11-06T12:52:39.35-0600 [APP/PROC/WEB/0] OUT Sortie état 1

@zhenwan, il semble que cela puisse être lié à l'impossibilité de se connecter à votre cluster lors de la connexion initiale. De plus, votre backtrace vers topology.js:878 ne pointe curieusement pas vers un endroit où une erreur est générée, et vous ne recevez pas non plus le type correct MongoTimeoutError .

Pouvez-vous s'il vous plaît ouvrir un nouveau ticket jira afin que nous puissions trier votre cas particulier. Il semble que nous aurons besoin de plus de détails que ce que vous avez collé ici. Merci!

@diffusion
Merci d'avoir aidé à résoudre le problème. Je veux juste dire que l'utilisation de la v3.3.4-rc0 ne résout pas mon problème. je reçois toujours ce message

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout (api/node_modules/mongodb/lib/core/sdam/topology.js:899:9)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

Dans mon cas, j'utilise loopback-connector-mongodb , mais j'ai configuré mon package.json pour forcer l'utilisation de la dernière version de mongodb dans resolutions comme suit

"resolutions": {
    "mongodb": "^3.3.4-rc0"
  }

mes paramètres de connexion comme suit

"host": "127.0.0.1",
 "port": 27017,
"database": "***",
"password": "***",
"user": "***",
"authSource": "***",
"useNewUrlParser": true,
"enableGeoIndexing": true

ci-dessous mes paramètres d'environnement

MongoDB server version: 3.6.3 on localhost
yarn v1.19.1
node v8.16.2 

Merci d'avance

mettre à jour
J'ai également essayé d'ajouter useUnifiedTopology: true aux paramètres de connexion, mais j'ai obtenu le même résultat.

Une autre confirmation ici, de la part de quelqu'un qui utilise directement la mangouste, que useUnifiedTopology: false fonctionne pour moi.

@mbroadst merci pour la mise à jour de la fin de MongoDB. Excusez mon ignorance, mais le correctif susmentionné dans mongodb v3.3.4-rc0 va-t-il se transformer en mangouste à un moment donné? Légèrement mal à l'aise avec l'idée d'adopter des fonctionnalités obsolètes comme solution de contournement dans un environnement de prod.

@mmmmoj similaire à la question de package-lock.json ? Pouvez-vous s'il vous plaît déposer un ticket jira afin que nous puissions approfondir les détails de votre cas.

@bigsee (man GitHub n'aime _pas_ la saisie semi-automatique de votre nom !) Heureux d'apprendre que cela fonctionne pour vous, et vous êtes le bienvenu pour la mise à jour - notre communauté est très importante pour nous. Je laisserai @vkarpov15 parler du moment de la sortie, mais nous travaillons en étroite collaboration et je suis sûr qu'il souhaite résoudre ce problème pour vous tous :)

@diffusion
terminé! Merci
NOEUD-2313

@diffusion ha ! désolé pour le nom maladroit!

il s'avère que j'ai peut-être parlé trop tôt, peut-être étant donné la nature aléatoire de l'erreur apparaissant. Lors d'un démarrage à froid de mon application, avec l'avertissement de dépréciation attendu, je vois maintenant cette erreur légèrement plus effrayante dans les journaux :

Unhandled rejection: { MongoNetworkError: failed to connect to server [myserver.mlab.com:55841] on first connect [{ MongoNetworkError: connection 0 to myserver.mlab.com:55841 timed out
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:335:7)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:420:8)
    at ontimeout (timers.js:482:11)
    at tryOnTimeout (timers.js:317:5)
    at Timer.listOnTimeout (timers.js:277:5) name: 'MongoError', [Symbol(mongoErrorContextSymbol)]: {} }]
    at Pool.<anonymous> (/var/task/node_modules/mongodb/lib/core/topologies/server.js:431:11)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at connect (/var/task/node_modules/mongodb/lib/core/connection/pool.js:580:14)
    at callback (/var/task/node_modules/mongodb/lib/core/connection/connect.js:109:5)
    at provider.auth.err (/var/task/node_modules/mongodb/lib/core/connection/connect.js:352:21)
    at _authenticateSingleConnection (/var/task/node_modules/mongodb/lib/core/auth/auth_provider.js:66:11)
    at sendAuthCommand (/var/task/node_modules/mongodb/lib/core/auth/scram.js:177:16)
    at Connection.errorHandler (/var/task/node_modules/mongodb/lib/core/connection/connect.js:321:5)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:333:10)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
  name: 'MongoNetworkError',
  errorLabels: [ 'TransientTransactionError' ],
  [Symbol(mongoErrorContextSymbol)]: {} }

Avant c'était MongoTimeoutError mais maintenant c'est MongoNetworkError ... ...des idées ?

@bigsee cette erreur indiquerait que vous n'utilisez _pas_ la topologie unifiée. Veuillez l'activer en passant useUnifiedTopology: true à votre MongoClient

@mbroadst c'est correct, ce qui, je crois, est l'objet de ce problème. Excusez-moi si je me trompe là-dessus.

Lorsque je passe useUnifiedTopology: true l'avertissement de dépréciation disparaît mais mon application se bloque de manière aléatoire avec l'erreur de titre de ce numéro MongoTimeoutError: Server selection timed out after 30000 ms .

Comme avec @vkarpov15 et d'autres ci-dessus, je n'ai pas été en mesure de reproduire ce problème de manière cohérente. L'erreur se produit plusieurs fois par jour, ce qui entraîne parfois des erreurs 502 et horribles UX. Il semble que ce soit un nouveau problème.

Comme indiqué ci-dessus, la solution de contournement consistant à définir useUnifiedTopology: false (ou à commenter) empêche l'erreur dans ce problème, mais restaure l'avertissement de dépréciation et maintenant le MongoNetworkError légèrement plus effrayant ci-dessus. Soit dit en passant, cela ne tue pas réellement mon application, mais cela m'inquiète que ce soit le cas pour un utilisateur à un moment donné.

@bigsee le MongoNetworkError vous rencontrez n'est pas nouveau, et cela signifie que le pilote n'a pas pu établir une connexion initiale à un cluster (incidemment si une sorte de condition de concurrence entre le démarrage de votre application et le démarrage de votre cluster provoque ceci, alors la topologie unifiée devrait aider ici aussi).

Le point important de ce problème est que les utilisateurs suivaient les instructions pour utiliser la topologie unifiée, et lorsqu'ils le faisaient, ils rencontraient de fausses erreurs de délai d'attente. v3.3.4-rc0 été publié pour résoudre ce problème spécifique, donc le conseil actuel est d'utiliser cette version qui devrait supprimer l'avis de dépréciation et corriger les faux problèmes de délai d'attente que les gens ont rencontrés.

Je devrais également dire : cette version n'empêchera pas _toutes_ les erreurs de délai d'attente. Cette erreur est causée par l'incapacité du pilote à établir une connexion initiale à un cluster, ce qui indiquerait une sorte de configuration (chaîne de connexion) ou une erreur réseau de votre part. Avec la topologie unifiée, cela apparaîtra sous la forme d'un MongoTimeoutError avec un champ reason indiquant l'erreur réseau qui a causé le délai d'attente lors de la connexion initiale.

@mbroadst Je ne voulais pas suggérer que le MongoNetworkError était nouveau dans mon dernier commentaire, alors désolé si c'est ainsi qu'il se lit. C'est le `MongoTimeoutError qui est nouveau. Pour être plus clair, espérons-le, voici mon processus :

1. l'application a une configuration avec useUnifiedTopology: true - tout fonctionne comme prévu
2. l'application commence à planter au hasard et présente un MongoTimeoutError correspondant au titre de ce numéro, ainsi que les premières lignes d'une trace de pile présentée ci-dessus
3. une recherche Google / SO m'amène finalement ici
4. J'utilise useUnifiedTopology: false solution
5. l'erreur MongoTimeoutError disparaît avec le plantage de l'application. cependant, il est initialement remplacé par l'avertissement d'obsolescence. puis, plus tard, par un MongoNetworkError supplémentaire non vu dans l'application avant de définir useUnifiedTopology: false

Peut-être, comme vous le suggérez, est-ce une corrélation plutôt qu'une causalité. Cela m'a semblé être une arme fumante. Au moins, l'application ne plante pas maintenant. Je suis juste inquiet de laisser une option obsolète.

@bigsee Ah ! Désolé, j'ai mal lu votre commentaire original pour signifier que vous confirmiez que les correctifs de v3.3.4-rc0 résolu vos problèmes de v3.3.3 . Avez-vous eu l'occasion d'essayer la nouvelle version ?

C'est mon premier essai sur Mongodb et j'ai cette erreur. lu les commentaires et changé ma base de données en v3.3.4-rc0 et cela n'a toujours pas corrigé l'erreur

DeprecationWarning : le moteur actuel de découverte et de surveillance des serveurs est obsolète et sera supprimé dans une future version. Pour utiliser le nouveau moteur de découverte et de surveillance du serveur, transmettez l'option { useUnifiedTopology: true } au constructeur MongoClient.
MongoNetworkError : échec de connexion au serveur [cluster0-shard-00-00-rhdve.mongodb. net:27017 ] lors de la première connexion [MongoNetworkError: connection 3 to cluster0-shard-00-00-rhdve.mongodb. net : 27017 fermé
chez TLSSocket.(C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js:356:9)
à Object.onceWrapper (events.js:297:20)
à TLSSocket.emit (events.js:209:13)
à net.js:588:12
à TCP.done (_tls_wrap.js:479:7) {
nom : 'MongoNetworkError',
errorLabels : [Tableau],
}]
à la piscine.(C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoretopologiesserver.js:433:11)
à Pool.emit (events.js:209:13)
à C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js:562:14
à C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js:999:9
au rappel (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:109:5)
à C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:129:7
à Connection.errorHandler (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:321:5)
à Object.onceWrapper (events.js:297:20)
à Connection.emit (events.js:209:13)
chez TLSSocket.(C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js:354:12) {
nom : 'MongoNetworkError',
errorLabels : [ 'TransientTransactionError' ],
}
TypeError : impossible de lire la propriété 'trouver' d'undefined
à C:laragonwwwVue-express-mongodbserverroutesapiposts.js:12:26

@ Syfon01 l'erreur que vous rencontrez est due à une sorte d'erreur de configuration, le pilote utilise la topologie héritée et ne parvient pas à établir sa connexion initiale à un cluster après une valeur par défaut de 10 s. Veuillez vérifier votre chaîne de connexion et votre configuration réseau et vérifiez que vous pouvez vous connecter au cluster (peut-être avec le shell mongo ). Si vous rencontrez toujours des problèmes, veuillez ouvrir un ticket Jira afin que nous puissions continuer la conversation là-bas, et ne pas confondre les personnes qui consultent ce problème GitHub

Pour les personnes qui rencontrent ce problème, si vous utilisez l'instance Mongo Atlas Cloud, veuillez vérifier si votre adresse IP est correctement spécifiée dans l'onglet Accès réseau.

J'ai eu le problème et il semble que puisque mon FAI donne de nouvelles adresses IP à chaque fois (DHCP) que je me reconnecte au réseau, Mongo Atlas ne faisait que lister en blanc l'adresse IP spécifiée précédemment. J'espère que cela aide quelqu'un.

mise à jour - ne fonctionne pas

J'ai pu résoudre ce problème en modifiant la structure de mon code, en particulier le rappel comme suit :

mongoose.connect(DATABASE_URL, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
}).then(() => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`)
    });
}).catch(err => console.log(err));

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, () => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    });
}).catch(err => console.log(err));

@mtn2bay cela n'a aucun sens, vous avez essentiellement utilisé la fonction de rappel au lieu de la promesse, le résultat est toujours le même, la seule différence est que dans la fonction de rappel, vous obtenez à la fois la connexion et l'erreur dans la fonction de rappel que vous n'enregistrez pas au lieu de vous fier à .then et .catch, de sorte que votre fonction se connecte à la base de données et démarre l'application de toute façon, même s'il y a une erreur. essayez plutôt ceci

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, (err, connection) => {
if(err) {
console.error(err)
return
}    
console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    })

@khaledosman merci pour la correction. Vous avez raison, j'ignorais simplement l'erreur plutôt que de la corriger. En fait, j'ai eu un problème avec mon chemin de base de données.

je faisais face au même problème, j'ai mis à jour le package mongoose npm de 5.6.9 à 5.7.6 et le problème a disparu.

Pour les personnes qui rencontrent ce problème, si vous utilisez l'instance Mongo Atlas Cloud, veuillez vérifier si votre adresse IP est correctement spécifiée dans l'onglet Accès réseau.

J'ai eu le problème et il semble que puisque mon FAI donne de nouvelles adresses IP à chaque fois (DHCP) que je me reconnecte au réseau, Mongo Atlas ne faisait que lister en blanc l'adresse IP spécifiée précédemment. J'espère que cela aide quelqu'un.

résolu mon problème
UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms at Timeout.setTimeout (C:\Users\Umer MIB\Desktop\Chatbots2\mongobot\node_modules\mongodb\lib\core\sdam\topology.js:878:9) at ontimeout (timers.js:436:11) at tryOnTimeout (timers.js:300:5) at listOnTimeout (timers.js:263:5) at Timer.processTimers (timers.js:223:10) (node:4304) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:4304) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code

Je ne sais pas comment cela a résolu un problème, mais j'ai téléchargé Compass et je l'ai connecté à la base de données, j'ai juste copié le lien. Une fois connecté, l'erreur a disparu. La topologie est toujours vraie dans mon code. Peut-être qu'il a configuré certaines options avec Compass qui n'étaient pas correctes avec l'installation habituelle de mongodb. Maintenant, je peux me connecter sans Compass et tout semble fonctionner, je ne l'ai fait qu'une seule fois au début.

J'ai eu le même problème et grâce à ce forum, j'ai réussi à commenter le paramètre useUnifiedTopology. Cependant, j'ai décommenté ce paramètre, mais maintenant cela fonctionne toujours très bien... assez confus...

Mongoose v5.7.11 utilise le nouveau pilote MongoDB 3.3.4, je vais donc clore ce problème. Si vous obtenez un message d'erreur similaire, veuillez ouvrir un nouveau problème et suivre le modèle de problème.