Mongoose: {useUnifiedTopology: true} genera un error de conexión de MongoDB: MongoTimeoutError: la selección del servidor agotó el tiempo de espera después de 30000 ms

¿Qué imagen de la ventana acoplable usas? Además, ¿tiene un seguimiento de pila para el mensaje 'Se agotó el tiempo de espera de la selección del servidor'?

Oye, solo asomando aquí para informar que tuve el mismo problema.

Yo mismo no estoy usando Docker ni ninguna máquina virtual. También hay que tener en cuenta que esto no parece suceder todo el tiempo, sin embargo, hoy no pude recuperar ninguno de mis datos debido a tiempos de espera (30k), y el problema se resolvió de inmediato al eliminar la bandera useUnifiedTopology .

Me estoy conectando a un clúster Atlas.

Mangosta es 5.7.1
MongoDb es 3.3.2
El nodo es 12.9.1

Conectando así:

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

El modelo se crea así:

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`);

Entonces se busca así:

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

La llamada find cuelga y emite el error de tiempo de espera.

@ vkarpov15 Estoy usando la última imagen mongo que proporciona MongoDB v4.2.0.
https://hub.docker.com/_/mongo

También recibo el mismo error después de agregar {useUnifiedTopology: true}, aunque el error se produce de forma aleatoria. Definitivamente hay algo mal. Estoy usando la última imagen de Mongo.

mangosta
.connect (process.env.MONGO_URI, {
useUnifiedTopology: true,
useNewUrlParser: verdadero,
})
.luego (() => console.log ('DB Connected!'))
.catch (err => {
console.log (Error, mensaje err.);
});
Cuando comienza, llego a la consola:
[Función: Error] {stackTraceLimit: 16, prepareStackTrace: undefined} conexión 0 a acccluster-shard-00-01-xx47j.mongodb. neto: 27017 cerrado

¿Alguna solución? Incluso yo estoy enfrentando este problema ahora ...

Tengo el mismo problema. Soy un programador junior y es la primera vez que uso nodejs-express-graphql-mongoose-mongodbAtlas.

(nodo: 9392) UnhandledPromiseRejectionWarning: MongoTimeoutError: la selección del servidor agotó el tiempo de espera después de 30000 ms
en Timeout.setTimeout (MyAppPathgraphql2node_modulesmongodblibcoresdamtopology.js: 850: 16)
en el tiempo de espera (timers.js: 436: 11)
en tryOnTimeout (timers.js: 300: 5)
en listOnTimeout (timers.js: 263: 5)
en Timer.processTimers (timers.js: 223: 10)
(nodo: 9392) UnhandledPromiseRejectionWarning: Rechazo de promesa no manejado. Este error se originó al lanzar dentro de una función asíncrona sin un bloque de captura, o al rechazar una promesa que no se manejó con .catch (). (id de rechazo: 1)
(nodo: 9392) [DEP0018] DeprecationWarning: Los rechazos de promesa no gestionados están obsoletos. En el futuro, los rechazos de promesas que no se manejan terminarán el proceso de Node.js con un código de salida distinto de cero.
events.js: 174
lanzador // Evento de 'error' no controlado
^

Error: leer ECONNRESET
en TLSWrap.onStreamRead (internal / stream_base_commons.js: 111: 27)
Evento de 'error' emitido en:
en TLSSocket.(MyAppPathnode_modulesmongodblibcoreconnectionconnection.js: 321: 10)
en Object.onceWrapper (events.js: 286: 20)
en TLSSocket.emit (events.js: 198: 13)
en emitErrorNT (internal / streams / destroy.js: 91: 8)
en emitErrorAndCloseNT (internal / streams / destroy.js: 59: 3)
en process._tickCallback (internal / process / next_tick.js: 63: 19)

También recibimos el mismo error en nuestro servidor de producción después de habilitar 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)

Empecé a encontrarme con otro problema ahora
MaxListenersExceededWarning: Posible fuga de memoria EventEmitter detectada. Se agregaron 11 detectores topologyDescriptionChanged.

Cuando busqué esta advertencia, encontré este documento mongoDB
https://jira.mongodb.org/browse/NODE-2123

Dice tanto los errores
"Se agotó el tiempo de espera de la selección del servidor", así como "MaxListenersExceededWarning" y ambos errores se deben al cambio de topología unificada. Supongo que este fue un cambio radical que nunca se mencionó.

Dado que me encuentro con este error en mi servidor en vivo, no tengo más remedio que configurar {useUnifiedTopology: false}. Espero que alguien de la comunidad pueda concentrarse en este problema y resolverlo o brindar algunas sugerencias para resolverlo.

También recibo ambos errores (la selección del servidor agotó el tiempo de espera después de 30000 ms y MaxListenersExceededWarning: Posible fuga de memoria EventEmitter detectada. 11 ) cuando uso useUnifiedTopology, por lo que esto le está sucediendo a todos los que usan esta opción, supongo.

He intentado reproducir esto, pero no he podido hacerlo. Probé algunas opciones:

1) Matar el servidor justo antes de realizar la consulta

2) Consultando con una conexión desconectada

3) Ejecutar una consulta con éxito

En cualquier caso, todavía tengo que ver este mensaje de error. ¿Puede modificar el siguiente script para demostrar este problema?

'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');
}

O al menos proporcione alguna información sobre qué versión de Mongoose está utilizando; si está utilizando un servidor independiente, un conjunto de réplicas o un clúster fragmentado; y si está utilizando Mongoose directamente o mediante otro módulo npm?

Estoy bastante convencido de que esto no es un problema con la mangosta, sino con el propio Mongo.

@ vkarpov15 , por favor vea mi comentario , describí mi entorno allí. Estoy usando mangosta directamente.

@ vkarpov15 para mí, este problema aparece aleatoriamente cada 2-3 días cuando el servidor está funcionando, así que incluso si le proporciono el código, tendrá que monitorear el servidor continuamente.

¿Alguien ha solucionado este problema?

¿Alguien ha solucionado este problema?

Simplemente no puede usar esta bandera por el momento. Mongo le advertirá que se desactivará en el futuro o algo así, pero por el momento parece resolver totalmente este problema.

¿Alguien ha solucionado este problema?

Simplemente no puede usar esta bandera por el momento. Mongo le advertirá que se desactivará en el futuro o algo así, pero por el momento parece resolver totalmente este problema.

cuando no uso la bandera useUnifiedTopology: true, tengo este error y la aplicación se detuvo,
veriosn de mangosta: 5.7.4

Puedo confirmar que comentar useUnifiedTopology out resuelve el problema en mi compilación. También sucede de una manera (aparentemente) aleatoria.

@rpedroni Lamentablemente, no es así para nosotros ...

También está sucediendo aquí. Nuestro servidor de producción responde con el siguiente mensaje. Supongo que comentaré useUnifiedTopology por ahora

Opciones de conexión de MongoDB

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

Registro del servidor

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) 

También estamos teniendo este problema y no usamos mangostas. Parece ser un problema con el controlador MongoDB para Node.js. El problema también se ha informado aquí https://jira.mongodb.org/browse/NODE-2249
La versión 3.3.3 del controlador que se publicó hoy debería agregar más detalles al MongoTimeoutError . También se recomienda actualizar el controlador debido a una corrección de errores.

Este error es el resultado de que el controlador no puede conectarse a un servidor que satisfaga la preferencia de lectura de una operación determinada (o conexión inicial). Esto podría deberse a varios motivos, como que su cadena de conexión no sea válida o los nodos de su clúster estén inactivos. Si actualiza a la última versión v3.3.3 del controlador, incluimos un nuevo campo de motivo con MongoTimeoutError que nos ayudará a investigar más a fondo su problema. Además, esta versión incluye una corrección de errores que daría lugar a un error de tiempo de espera en la conexión inicial si algún miembro de un conjunto de réplicas no estuviera disponible. Actualice su controlador y avísenos si continúa experimentando este problema.

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

Lo mismo sucede tanto en el desarrollo como en la producción, conectándose a Mongo Atlas :(

También tengo este problema al conectarse al atlas de mongodb. Normalmente ocurre después de que atlas reinicia o actualiza un servidor o algo por el estilo.

Así que todavía no puedo reproducir esto localmente con un conjunto de réplicas. El siguiente script continúa ejecutando consultas con éxito incluso con la conmutación por error del conjunto de réplicas o eliminando el primario. No obtenga ningún error de tiempo de espera de selección de servidor:

'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));
  }
} 

Mi mejor suposición es que la explicación de @rvanmil es correcta. Intente actualizar a [email protected] (que enviaré en un par de horas) y vea si este problema persiste.

Además, ¿alguien sabe si hay una forma de activar un reinicio en Atlas? ¿Quizás este problema solo ocurre si está usando Atlas?

@ vkarpov15 Creo que tienes que pausar / reanudar el clúster para activar un reinicio. Solo es posible en tamaños M10 +.
También me pregunto si esto podría ser un problema de Atlas. Todavía no he podido probar el controlador MongoDB actualizado, pero informaré aquí una vez que lo haga.

También tengo el mismo problema hoy con el nivel gratuito de Atlas, independientemente de la marca useUnifiedTopology. Error: MongoTimeoutError: Server selection timed out after 30000 ms

Puedo obtener una conexión usando otro servicio MongoDB como mLab.

Estaba teniendo el mismo problema y terminó siendo algo un poco estúpido, pero lo compartiré de todos modos porque puede ayudar a alguien que también termine aquí.

Revisé el campo 'motivo' en MongoTimeoutError y decía 'MongoError: error de autenticación de autenticación incorrecta'.
Fue entonces cuando me di cuenta de que estaba usando la contraseña de mongoDB en mi cadena de conexión y no la contraseña de usuario.
Ahora funciona bien.

Si está utilizando MongoDB Atlas, debe incluir su dirección IP en la lista blanca.

Vaya a Acceso a la red, edite la dirección IP actual y haga clic en Permitir acceso desde cualquier lugar.

Solo estoy enfrentando este problema mientras uso Atlas. Intenté agregar 0.0.0.0/0 IP en la lista blanca, pero tampoco funcionó.

Estoy usando:

• mangosta: 5.7.6
• nodo: v10.16.3
• Nivel gratuito de Atlas

No se pudo reproducir en el servidor mongodb local. Allí, todas las consultas funcionan correctamente.

Esto no tiene nada que ver con el acceso. Tengo acceso 0/0/0/0 y esto ocurre
cada vez que el servidor se reinicia en atlas. Puede reproducir haciendo un nodo múltiple
cluster (m10 +) y estableciendo el tiempo de mantenimiento programado. Entonces corre un largo
servicio en ejecución y debería producir el error cuando se reinicia.

El miércoles 23 de octubre de 2019 a las 7:42 am Mohammad Mazedul Islam, <
[email protected]> escribió:

Solo estoy enfrentando este problema mientras uso Atlas. He intentado agregar
0.0.0.0/0 IP en la lista blanca pero tampoco funcionó.

Estoy usando:

• mangosta: 5.7.6
• nodo: v10.16.3
• Nivel gratuito de Atlas

No se pudo reproducir en el servidor mongodb local. Allí, cada consulta simplemente funciona
exitosamente.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Automattic/mongoose/issues/8180?email_source=notifications&email_token=AAUHUCYYQIQ5U42IBYT7CQTQQA2B7A5CNFSM4IYQ3ZB2YY3PNVWWK3TUL52GHS4DFMVREXWK3TUL52GHS4DFMVREXWK3TUL52GHS4DFMVREX
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAUHUCY5SNFGGCPTGW6GH5DQQA2B7ANCNFSM4IYQ3ZBQ
.

También solía tener ese problema. Pero ahora, después de poner 0.0.0.0/0 y mi dirección IP en la lista blanca de atlas, se resuelve el problema.

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

~ Esto es solo un problema con MongoDB Atlas. ~

Tengo un problema al usar MongoDB Atlas.

Tengo el mismo problema al usar MongoDB normal.

He reproducido con éxito la condición que causa "MongoTimeoutError: la selección del servidor agotó el tiempo de espera después de 30000" usando docker-compose.
https://github.com/anzairyo0127/mongodb-connection-bug

Primero inicie esta aplicación

$ 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 ¿puedes intentar lo mismo con la última biblioteca 3.3.3 mongodb?

@rvanmil Puedo reproducirlo en la versión 3.3.3.

Parece que este error se produce cuando mongoDB está en configuración de replicación y una de las instancias (probablemente la instancia principal) recibe un comando justo antes de que caiga o justo después de su inicio.
Creo que la razón por la que esto sucede con frecuencia en MongoDB Atlas es que MongoDB Atlas envía regularmente consultas al clúster para su monitoreo.

¿Alguna solución? Este problema es ...

El mismo problema desde hace más de 1 mes y aún no está resuelto -_-

La actualización a [email protected] lo resolvió por mí.

@octavioamu ¿Puede proporcionar más detalles? ¿Qué versión de la base de datos de MongoDB [clúster] estaba ejecutando antes de la 4.2? ¿Qué versión de los paquetes npm de mongoose y mongodb estás usando? ¿Los actualizaste? ¿Cuánto tiempo ha estado ejecutando 4.2 para estar seguro de que está resuelto en esta versión?

lo siento, no sé qué versión se instaló, probablemente una muy antigua ya que no trabajé con mongo por un tiempo.
La versión de mangosta está en @ 5.7.7
El mensaje fue permanente para mí y una vez que instalé [email protected] (instalado a través de brew) el mensaje se detuvo.

Si configuro {useUnifiedTopology: false} obtengo un error de autenticación

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

y si configuro {useUnifiedTopology: true} , obtengo un tiempo de espera

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

Definitivamente la contraseña es correcta. Esto se puede reproducir en un sistema local con las últimas versiones de todo y LST Node.js. Sin embargo, el uso de una cadena de conexión sin ningún tipo de autenticación parece funcionar localmente. Entonces, si configuro, por ejemplo, const MONGODB_URI = "mongodb://localhost/fullstack" problema de tiempo

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()

Usé la última imagen de Docker para la configuración de MongoDB.

También está sucediendo aquí. Nuestro servidor de producción responde con el siguiente mensaje. Supongo que comentaré useUnifiedTopology por ahora

Opciones de conexión de MongoDB

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

Registro del servidor

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) 

También está sucediendo aquí. Nuestro servidor de producción responde con el siguiente mensaje. Supongo que comentaré useUnifiedTopology por ahora

Opciones de conexión de MongoDB

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

Registro del servidor

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) 

Estoy usando mongo db atlas y nos enfrentamos al mismo problema.

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

Todo esto sucedió al comentar useUnifiedTopology como sugirió una recomendación

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

usando el atlas de mangosta y mongoDB, asegúrese de que las opciones sean así:
mongoose.connect (DATABASE_URL, {useNewUrlParser: true, useUnifiedTopology: true})

Después de esto, si se agota el tiempo de espera, debe incluir en la lista blanca su dirección IP de mongoDB yendo al acceso a la red en mongoDB

Como otros, este error bloquea mi aplicación cada pocos días y puedo confirmar que no está relacionado con el acceso o la lista blanca de la dirección IP.

Estoy usando:

• mangosta: 5.7.6
• nodo: v10.16.3
• Nivel gratuito de Atlas

Por ahora, también comentaré useUnifiedTopology: true . Parece que puede estar relacionado con Atlas o mongo, como han dicho otros.

Este es un problema con los servidores MongoDB del conjunto de réplicas y los ingenieros de MongoDB están trabajando en una solución aquí.

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

@ vkarpov15 probablemente pueda cerrar este problema porque no tiene nada que ver con Mongoose.

cuando su dirección IP actual cambia por alguna razón, la conexión falla, debe editarla en la lista blanca de IP de acceso a la red y usar la IP actual

¡Hola! Mi nombre es Matt y estoy en el equipo de pilotos de MongoDB. Lamentamos mucho las interrupciones que todos ustedes han estado enfrentando y quería darles una pequeña actualización sobre el problema:

Estamos en el proceso de intentar eliminar gradualmente nuestros tipos de topología heredados, lo que ha resultado ser un proceso muy quirúrgico. La eliminación gradual de estos tipos ayudará a reducir en gran medida la carga de mantenimiento del controlador, y esperamos que eso signifique un controlador más estable y eficiente para nuestros usuarios. En particular, al presentar la "Topología unificada", tampoco introdujimos la reescritura del grupo de conexiones en un esfuerzo por reducir el potencial de error. Resulta que el grupo de conexiones estaba más estrechamente acoplado a los tipos de topología de lo que anticipamos y, como resultado, experimentamos algunas regresiones, particularmente en torno al monitoreo del servidor.

Esta mañana presioné una NODE-2267 , pero no dude en abrir problemas adicionales allí si los experimenta.

Puedo confirmar que 3.3.4-rc0 ha solucionado el problema 👍 Proporcionaré resultados de prueba más detallados más adelante.

después de cambiar mi versión de mongodb en package.json a
"mongodb": "3.3.4-rc0",
Siempre obtengo un error (este error no ocurre cuando la versión de mongodb está en 3.3.3):

===========================================
npm ERR! ruta / tmp / app / node_modules / npm / node_modules / abbrev
npm ERR! código ENOENT
npm ERR! errno -2
npm ERR! cambio de nombre de syscall
npm ERR! enoent ENOENT: no existe tal archivo o directorio, cambie el nombre '/ tmp / app / node_modules / npm / node_modules / abbrev' -> '/tmp/app/node_modules/npm/node_modules/.abbrev.DELETE'
npm ERR! enoent Esto está relacionado con que npm no puede encontrar un archivo.
npm ERR! enoent
npm ERR! Puede encontrar un registro completo de esta ejecución en:
npm ERR! /home/vcap/.npm/_logs/2019-11-06T17_19_55_661Z-debug.log
[31; 1 m ERROR [0 m No se pueden construir dependencias: estado de salida 254
No se pudo compilar la gota: no se pudieron ejecutar todos los scripts de suministro: estado de salida 14
Estado de salida 223

==================================
mi versión npm es npm a las 6.11.3.

¿Este error se relaciona con esta nueva compilación de mongodb v3.3.4-rc0?

@zhenwan, esto parece un problema al descargar el paquete abbrev . Supongo que hay problemas con su package-lock.json , intente eliminar ese archivo y ejecute npm install nuevamente.

Pude reproducir el error y verificar si se resolvió con el controlador v3.3.4-rc0 usando la siguiente configuración:

• El servidor web Node.js expone una simple api http GET /api/todos que consulta una colección todo MongoDB que contiene algunos datos de muestra
• Script que llama a la API cada 500ms ejecutándose localmente en mi máquina
• Una vez que el script se esté ejecutando, active una conmutación por error (reinicie el primario) en MongoDB (en Atlas pude hacer esto en un clúster M10 seleccionando la opción de menú "Probar conmutación por error")

Los resultados de esta prueba fueron los siguientes:

✅ 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

Entonces parece funcionar con v3.3.4-rc0 , el servidor puede recuperar la conexión y reanudar el servicio de datos de MongoDB. Sin embargo, todavía hay dos problemas:

• Parece que falta el evento 'reconectar'
• Un par de solicitudes fallan con un mensaje de error "Lector de caché No se encontraron claves para HMAC que sean válidas por tiempo".

@mbroadst sí, eliminar package-lock.json resolvió el problema de mi archivo faltante.

Pero sigo recibiendo el error:
2019-11-06T12: 52: 10.35-0600 [CELL / 0] El contenedor OUT se volvió saludable
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 throw err
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR ^
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR Error: la selección del servidor agotó el tiempo de espera después de 30000 ms
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR en Timeout.setTimeout [como _onTimeout] (/ home / vcap / app / node_modules / connect-mongo / node_modules / mongodb / lib / core /sdam/topology.js:878:9)
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR en el tiempo de espera agotado (timers.js: 469: 11)
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR en tryOnTimeout (timers.js: 304: 5)
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR en Timer.listOnTimeout (timers.js: 264: 5)
2019-11-06T12: 52: 39.35-0600 [APP / PROC / WEB / 0] OUT Estado de salida 1

@zhenwan , parece que podría estar relacionado con no poder conectarse a su clúster en la conexión inicial. Además, su retroceso a topology.js:878 curiosamente no apunta a un lugar donde se genera un error, ni está recibiendo el tipo correcto MongoTimeoutError .

¿Puede abrir un nuevo boleto de jira para que podamos clasificar su caso en particular? Parece que necesitaremos más detalles de los que ha pegado aquí. ¡Gracias!

@mbroadst
Gracias por ayudar a solucionar el problema. Solo quiero decir que usar v3.3.4-rc0 no resuelve mi problema. Sigo recibiendo este mensaje

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)

En mi caso, estoy usando loopback-connector-mongodb , pero configuro mi package.json para forzar el uso de la última versión de mongodb en resolutions siguiente manera

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

mis parámetros de conexión de la siguiente manera

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

a continuación se muestran los parámetros de mi entorno

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

Gracias por adelantado

actualizar
También intenté agregar useUnifiedTopology: true a los parámetros de conexión, pero obtuve el mismo resultado.

Otra confirmación aquí, de alguien que usa mangosta directamente, que useUnifiedTopology: false funciona para mí.

@mbroadst gracias por la actualización del final de MongoDB. Disculpe mi ignorancia, pero ¿la solución mencionada anteriormente en mongodb v3.3.4-rc0 caerá en cascada hasta la mangosta en algún momento? Un poco incómodo con la idea de adoptar funciones obsoletas como solución en un entorno de producción.

@mmmmoj similar a la pregunta de @zhenwan anterior, su seguimiento de pila parece indicar que de hecho no está ejecutando v3.3.4-rc0. ¿Quizás intente eliminar su package-lock.json ? ¿Puede presentar un boleto de jira para que podamos profundizar en los detalles de su caso?

@bigsee (¡a GitHub no le gusta completar automáticamente tu nombre!) Me alegra saber que funciona para ti, y eres bienvenido a la actualización: nuestra comunidad es muy importante para nosotros. Dejaré que

@mbroadst
¡hecho! Gracias
NODO-2313

@mbroadst ha! ¡perdón por el nombre extraño!

resulta que podría haber hablado demasiado pronto, tal vez dada la naturaleza aleatoria del error que aparece. En un inicio en frío de mi aplicación, junto con la advertencia de desaprobación esperada, ahora veo este error un poco más aterrador en los registros:

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)]: {} }

Solía ​​ser MongoTimeoutError pero ahora es MongoNetworkError ... ... ¿alguna idea?

@bigsee, ese error indicaría que _no_ está utilizando la topología unificada. Habilítelo pasando useUnifiedTopology: true a su MongoClient

@mbroadst eso es correcto, que creo que es el punto de este problema. Disculpas si me equivoco en eso.

Cuando paso useUnifiedTopology: true la advertencia de desaprobación desaparece, pero mi aplicación se bloquea aleatoriamente con el error de título de este problema MongoTimeoutError: Server selection timed out after 30000 ms .

Al igual que con @ vkarpov15 y otros anteriores, no he podido reproducir este problema de manera consistente. El error ocurre varias veces al día, lo que resulta en errores 502 y horribles UX de vez en cuando. Parece ser un tema nuevo.

Como se informó anteriormente, la solución alternativa de configurar useUnifiedTopology: false (o comentar) evita el error en este problema, pero restaura la advertencia de desaprobación y ahora el MongoNetworkError un poco más aterrador anterior. Por otro lado, esto en realidad no mata mi aplicación, pero me preocupa que lo haga para un usuario en algún momento.

@bigsee, el MongoNetworkError que está experimentando no es nuevo, y significa que el controlador no pudo realizar una conexión inicial con un clúster (por cierto, si algún tipo de condición de carrera entre el inicio de su aplicación y el inicio del clúster está causando esto, entonces la topología unificada debería ayudar aquí también).

El punto de este problema es que las personas seguían la guía para usar la topología unificada y, cuando lo hacían, experimentaban errores de tiempo de espera espurios. v3.3.4-rc0 se lanzó para abordar ese problema específico, por lo que la guía actual es usar esa versión que debería eliminar el aviso de obsolescencia y corregir los problemas de tiempo de espera espurios que la gente ha encontrado.

También debería decir: esta versión no evitará _todos_ los errores de tiempo de espera. Ese error se debe a la incapacidad del controlador para realizar una conexión inicial a un clúster, lo que indicaría algún tipo de configuración (cadena de conexión) o error de red de su parte. Con la topología unificada, esto se mostrará como MongoTimeoutError con un campo reason indica el error de red que provocó el tiempo de espera en la conexión inicial.

@mbroadst No MongoNetworkError fuera nuevo en mi último comentario, así que disculpas si así es como se lee. Es el `MongoTimeoutError que es nuevo. Para ser más claro, este ha sido mi proceso:

1. la aplicación tiene configuración con useUnifiedTopology: true - todo funciona como se esperaba
2. La aplicación comienza a fallar aleatoriamente y presenta un MongoTimeoutError coincide con el título de este problema, así como las primeras líneas de un seguimiento de pila presentado anteriormente.
3. una búsqueda de Google / SO finalmente me trae aquí
4. Yo uso useUnifiedTopology: false solución alternativa sugerida
5. el error MongoTimeoutError desaparece junto con el bloqueo de la aplicación. sin embargo, inicialmente se reemplaza por la advertencia de obsolescencia. luego, más tarde, por MongoNetworkError adicionales que no se ven en la aplicación antes de configurar useUnifiedTopology: false

Tal vez, como sugiere, esto sea una correlación más que una causalidad. Me parecía una pistola humeante. Al menos la aplicación no falla ahora. Solo me preocupa dejar una opción que está obsoleta.

@bigsee ¡Ah! Lo siento, leí mal tu comentario original en el sentido de que estabas confirmando que las v3.3.4-rc0 correcciones de errores resolvieron tus problemas de v3.3.3 . ¿Ha tenido la oportunidad de probar la nueva versión?

Esta es mi primera prueba en Mongodb y tengo este error. leí los comentarios y cambié mi base de datos a v3.3.4-rc0 y aún no solucionó el error

DeprecationWarning: el motor actual de detección y supervisión de servidores está obsoleto y se eliminará en una versión futura. Para usar el nuevo motor Server Discover and Monitoring, pase la opción {useUnifiedTopology: true} al constructor MongoClient.
MongoNetworkError: no se pudo conectar al servidor [cluster0-shard-00-00-rhdve.mongodb. net: 27017 ] en la primera conexión [MongoNetworkError: conexión 3 a cluster0-shard-00-00-rhdve.mongodb. neto: 27017 cerrado
en TLSSocket.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js: 356: 9)
en Object.onceWrapper (events.js: 297: 20)
en TLSSocket.emit (events.js: 209: 13)
en net.js: 588: 12
en TCP.done (_tls_wrap.js: 479: 7) {
nombre: 'MongoNetworkError',
errorLabels: [Matriz],
}]
en la piscina.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoretopologiesserver.js: 433: 11)
en Pool.emit (events.js: 209: 13)
en C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js: 562: 14
en C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js: 999: 9
en la devolución de llamada (C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 109: 5)
en C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 129: 7
en Connection.errorHandler (C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 321: 5)
en Object.onceWrapper (events.js: 297: 20)
en Connection.emit (events.js: 209: 13)
en TLSSocket.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js: 354: 12) {
nombre: 'MongoNetworkError',
errorLabels: ['TransientTransactionError'],
}
TypeError: no se puede leer la propiedad 'encontrar' de indefinido
en C: laragonwwwVue-express-mongodbserverroutesapiposts.js: 12: 26

@ Syfon01, el error que está experimentando se debe a algún tipo de error de configuración, el controlador está usando la topología heredada y no puede realizar su conexión inicial a un clúster después de un valor predeterminado de 10 segundos. Verifique su cadena de conexión y configuración de red y verifique que pueda conectarse al clúster (quizás con el shell mongo ). Si aún tiene problemas, abra un ticket de jira para que podamos continuar la conversación allí y no confundir a las personas que miran este problema de GitHub.

Para las personas que tienen este problema, si está utilizando Mongo Atlas Cloud Instance, compruebe si su dirección IP está especificada correctamente en la pestaña Acceso a la red.

Tuve el problema y parece que, dado que mi ISP proporciona nuevas IP cada vez que (DHCP) me vuelvo a conectar a la red, Mongo Atlas solo incluía en la lista blanca la dirección IP especificada anteriormente. Espero que esto ayude a alguien.

actualizar - no funciona

Pude resolver este problema cambiando la estructura de mi código, específicamente la devolución de llamada de la siguiente manera:

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 eso no tiene ningún sentido, básicamente

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 gracias por la corrección. Tienes razón, solo estaba ignorando el error en lugar de abordarlo. De hecho, tuve un problema con mi ruta de base de datos.

Estaba enfrentando el mismo problema, actualicé el paquete npm de mongoose de 5.6.9 a 5.7.6 y el problema desapareció.

Para las personas que tienen este problema, si está utilizando Mongo Atlas Cloud Instance, compruebe si su dirección IP está especificada correctamente en la pestaña Acceso a la red.

Tuve el problema y parece que, dado que mi ISP proporciona nuevas IP cada vez que (DHCP) me vuelvo a conectar a la red, Mongo Atlas solo incluía en la lista blanca la dirección IP especificada anteriormente. Espero que esto ayude a alguien.

resolvió mi problema
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

No sé cómo eso resolvió un problema, pero descargué Compass y lo conecté a la base de datos, simplemente copié el enlace. Una vez que se conectó, el error desapareció. La topología sigue siendo cierta en mi código. Tal vez configuró algunas opciones con Compass que no estaban bien con la instalación habitual de mongodb. Ahora puedo conectarme sin Compass y todo parece funcionar, solo lo hice una vez al principio.

Tuve el mismo problema y, gracias a este foro, lo logré comentando la configuración de useUnifiedTopology. Sin embargo, luego descomenté esta configuración, pero ahora todavía funciona bien ... bastante confuso ...

Mongoose v5.7.11 usa el controlador MongoDB 3.3.4 recientemente lanzado, así que voy a cerrar este problema. Si recibe un mensaje de error similar, abra un nuevo problema y siga la plantilla de problemas.