Mongoose: No hay servidor primario disponible

Nada salta en este momento. ¿Estás seguro de que ninguno de los servidores de mongodb falla? Además, ¿puede mantener una conexión estable usando el shell?

Ejecutar el comando db.runCommand( { replSetGetStatus : 1 } ) mientras ocurría el error produce "health" : 1, en los 3 nodos. También hay un conjunto primario "stateStr" : "PRIMARY", en uno de los nodos.

¿Se está conectando usando la misma cadena de conexión, usando el DNS? También parece que su almacenamiento está plano después del problema, ¿puede verificar y ver si se ha quedado sin espacio en el disco duro en una de sus máquinas?

¿Se está conectando usando la misma cadena de conexión, usando el DNS?

No estaba usando la misma cadena de conexión. ¿Cree que el uso de direcciones IP EC2 privadas resolvería esto?

No estoy seguro de qué está causando que el almacenamiento se maximice de esa manera, pero incluso después de iniciar nuevas instancias, el problema sin servidores primarios todavía ocurre con mucho espacio disponible.

Las direcciones IP EC2 pueden ayudar, dependiendo de cómo esté configurado su conjunto de réplicas. ¿Puedes mostrarme la salida de rs.status() del shell ?

Este es el rs.status () mientras que las conexiones van en aumento.

{
    "set" : "mongo2",
    "date" : ISODate("2015-12-04T23:39:32.520Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 6,
            "name" : "mongo-8.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 444053,
            "optime" : Timestamp(1449272372, 32),
            "optimeDate" : ISODate("2015-12-04T23:39:32Z"),
            "lastHeartbeat" : ISODate("2015-12-04T23:39:32.507Z"),
            "lastHeartbeatRecv" : ISODate("2015-12-04T23:39:31.442Z"),
            "pingMs" : 0,
            "syncingTo" : "mongo-9.loc.0600.mongodbdns.com:27000",
            "configVersion" : 29
        },
        {
            "_id" : 7,
            "name" : "mongo-9.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 444056,
            "optime" : Timestamp(1449272372, 39),
            "optimeDate" : ISODate("2015-12-04T23:39:32Z"),
            "electionTime" : Timestamp(1449097485, 1),
            "electionDate" : ISODate("2015-12-02T23:04:45Z"),
            "configVersion" : 29,
            "self" : true
        },
        {
            "_id" : 8,
            "name" : "mongo-10.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 444053,
            "optime" : Timestamp(1449272371, 111),
            "optimeDate" : ISODate("2015-12-04T23:39:31Z"),
            "lastHeartbeat" : ISODate("2015-12-04T23:39:31.904Z"),
            "lastHeartbeatRecv" : ISODate("2015-12-04T23:39:30.903Z"),
            "pingMs" : 2,
            "syncingTo" : "mongo-8.loc.0600.mongodbdns.com:27000",
            "configVersion" : 29
        }
    ],
    "ok" : 1
}

Nada fuera de lo común en el conjunto de réplicas. ¿Tiene alguna otra muestra de código relevante, por ejemplo, tiene algún código que reaccione a eventos de conexión de mangosta?

Otro problema potencial que vale la pena considerar, ¿está utilizando un nuevo agente reliquia actualizado? Intentaría correr sin una nueva reliquia y ver si esto todavía sucede, la nueva reliquia parchea el controlador mongodb para que a veces pueda conducir a un comportamiento inesperado.

Hemos estado generando los eventos de conexión de mangosta:

['connecting', 'connected', 'open', 'disconnecting', 'disconnected', 'close', 'reconnected', 'error', 'fullsetup'].forEach(function(name) {
  mongoose.connection.on(name, function() {
    notifySlack('Mongoose event: ' + name);
  });
});

Así es como se ven algunos de los registros

​[4:30] Mongoose event: fullsetup
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: open
​[4:30] Mongoose event: connected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: fullsetup
​[4:30] Mongoose event: connected
​[4:30] Mongoose event: open
​[4:30] 
{
 "err": {
   "name": "MongoError",
   "message": "no primary server available"
 }
}

Estuve en el evento mongodb days esta semana, donde pude programar algo de tiempo y mostrar este problema a uno de los ingenieros superiores de MongoDB, y no estaban seguros de cuál era el problema. Mencionaron agregar el conjunto de replicación y el tamaño máximo del grupo a la cadena de conexión, lo que desafortunadamente no ha resuelto este problema.

También intentamos deshabilitar el mantener vivo y establecerlo en un valor menor en las instancias, pero eso tampoco pareció resolver esto.

Estamos usando newrelic versión 1.24.0 , y mongo-express-patch versión 0.21.1 . Intentaré ejecutar sin newrelic para ver si eso resuelve esto.

Hmm, sí, parece que la mangosta se está volviendo a conectar por alguna razón. ¿Puede mostrarme la salida de npm list | grep "mongoose" y npm list | grep "mongo" ?

$ npm list | grep "mongoose"
├─┬ [email protected]

$ npm list | grep "mongo"
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
├─┬ [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]

¿Para qué estás usando mongodb-core ? Además, ¿está ejecutando con mongo-express habilitado en prod?

Actualmente no se usa mongodb-core para nada. ¿Cree que la falta de coincidencia de versiones entre la dependencia de mangosta puede estar causando problemas?

Tenemos mongo-express habilitados en producción.

No que yo sepa. Solo estoy tratando de ver si hay otras conexiones con mongodb que podrían estar contribuyendo a este problema. He buscado un poco en Google: ¿está usando los mismos nombres DNS para su cadena de conexión que los que aparecen en rs.status() ? De acuerdo con esto , es posible que vea problemas similares si usa un DNS diferente para la cadena de conexión de lo que piensa su conjunto de réplicas.

Este error ocurrirá cuando se use el mismo DNS en la cadena de conexión que el atributo "syncingTo" en rs.status() . También ocurre cuando se usa la IP ec2 interna en la cadena de conexión.

Lo único que aún no he probado es configurar connectWithNoPrimary en true .

También intentaría ejecutar con mongo-express descuento también. Eso podría estar causando problemas ...

Nos encontramos con el mismo problema. Tenemos un sitio que está experimentando una carga sostenida de alrededor de 100 RPM con picos en las 500-700 rpm +. Parece que vemos esto durante todo el proceso, incluso durante períodos relativamente tranquilos.

Ambiente:
Heroku - 75 2x dynos - Node.JS 5.1.1
Base de datos - MongoLabs Dedicated Cluster M4 - Versión 3.0.7

Cadena de conexión:
mongodb: // _: * _ @ ds043294-a0.mongolab. com: 43294 , ds043294-a1.mongolab. com: 43294 / heroku_hf8q79dt? replicaSet = rs-ds043294

NPM:

npm list | grep "mongoose"
├─┬ [email protected]
├── [email protected]
├── [email protected]
├─┬ [email protected]

Connection.js

// Mongoose import
var mongoose = require('mongoose');
var options = {
    server: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    },
    replset: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    }
};

mongoose.connect((process.env.MONGOLAB_URI || "mongodb://localhost/test"), options, function(error) {
    if (error) {
        console.log(error);
    }
});

module.exports = {
    mongoose: mongoose
};

Inicio sesión:
Hemos habilitado una buena cantidad de monitoreo para tratar de depurar esto, así que incluí nuestros rastros de pila Raygun en el sentido de que esto ayudaría a depurar. _Nota: _ Este es exactamente el mismo número de línea que @ChrisZieba mostró en la traza anterior.

Mensaje: no hay servidor primario disponible
Object.pickServer en /app/node_modules/mongodb-core/lib/topologies/replset.js:860
ReplSet.ReplSet.command en /app/node_modules/mongodb-core/lib/topologies/replset.js:437
ReplSet.ReplSet.command en /app/node_modules/mongodb/lib/replset.js:392
Object.executeCommand en /app/node_modules/mongodb/lib/db.js:281
Db.Db.command en /app/node_modules/mongodb/lib/db.js:305
Object.wrapped en /app/node_modules/newrelic/lib/instrumentation/mongodb.js:185
Object.findAndModify en /app/node_modules/mongodb/lib/collection.js:2327
Collection.Collection.findAndModify en /app/node_modules/mongodb/lib/collection.js:2265
Objeto envuelto en /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.wrappedQuery en /app/node_modules/newrelic/lib/instrumentation/mongodb.js:218
Object.wrapped en [como findAndModify] (/app/node_modules/newrelic/lib/instrumentation/mongodb.js:188
NativeCollection.NativeCollection. (Función anónima) [como findAndModify] (/app/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:136
NodeCollection.NodeCollection.findAndModify en /app/node_modules/mquery/lib/collection/node.js:79
Query.Query._findAndModify en /app/node_modules/mongoose/lib/query.js:1833
Query.Query._findOneAndUpdate en /app/node_modules/mongoose/lib/query.js:1621
desconocido. [anónimo] en /app/node_modules/kareem/index.js:156
desconocido. [anónimo] en /app/node_modules/kareem/index.js:18
Objeto envuelto en /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.doNTCallback0 en node.js: 430
process.process._tickCallback en node.js: 359

Supervisión:

Ese rastro de pila realmente solo me dice que 1) está usando una nueva reliquia (lo cual es muy cuestionable, ya que la nueva reliquia hace muchos parches de mono del controlador mongodb), y 2) el controlador mongodb cree que no hay una reliquia primaria disponible, pero no estoy seguro de por qué.

Intente habilitar el modo de depuración del controlador mongodb agregando replset: { loggerLevel: 'debug' } a sus opciones de conexión, es decir:

var options = {
    server: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    },
    replset: {
        loggerLevel: 'debug',
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    }
};

Esto registrará una gran cantidad de datos de depuración del controlador en stdout y nos ayudará a descubrir qué está fallando. ¿Puede capturar estos datos cuando ocurra este error "No se encontró servidor primario"?

Gracias @ vkarpov15 ,

Hemos agregado eso e informaremos tan pronto como tengamos otro activado.

Salud,
Roy

No creo que newrelic sea el problema aquí. Intentamos ejecutar sin él y este problema persiste. Recopilará algunos datos de registro de loggerLevel: 'debug' y los publicará aquí.

Gracias, avíseme si logra captar más detalles sobre el error.

Otro dato: Mongoose activa el evento "reconectado" una y otra vez a medida que aumenta el número de conexiones.

Los errores de "no hay servidor primario disponible" generalmente se activan _después_ de que el recuento de conexiones ya ha comenzado a aumentar.

Nosotros también hemos experimentado este problema. Con tener una aplicación Node alojada en Heroku con MongoLab.
La semana pasada perdimos repentinamente la conexión con la base de datos y seguimos recibiendo el mensaje Error no primary server available . Reiniciar nuestra aplicación resolvió el problema.
Tanto Heroku como MonogLab no vieron nada en sus registros.
Espero que alguien encuentre una solución para esto.

Bump: estamos viendo esto en node v4.2.3 mongoose v4.1.5 en una implementación de producción grande. Es difícil resolver este problema ya que:

• no comete errores consistentemente, lo que nos impide tomar medidas (reiniciar el proceso / eliminar el nodo)
• ocurre al azar y parece no estar correlacionado con el estado de respuesta de mongo

@sansmischevia, ¿estás usando mongolab + heroku también?

^ Estamos experimentando este problema en una gran implementación de producción en AWS EC2 con servidores mongodb autohospedados a través de Cloud Manager.

Hola,

También nos gustaría intervenir.
Estamos ejecutando node v0.12.8 , mongo v2.6.11 con mongoose v4.1.11 .

$ npm list | grep "mongo"
├─┬ [email protected]
│ └─┬ [email protected]
│   ├─┬ [email protected]
├─┬ [email protected] 
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
└─┬ [email protected]
  └─┬ [email protected]
    ├─┬ [email protected]

$ npm list | grep "mongoose"
├─┬ [email protected]

A menudo es reproducible durante una operación que inicia la base de datos, lo que implica muchas consultas. Nuestra aplicación parece no verse afectada después de que esto ocurra. No hay errores en el registro de mongo y nuestro conjunto de réplicas de tres nodos está en buen estado durante este tiempo.

Intentaremos loggerLevel: 'debug' e informaremos.

@ vkarpov15 estamos en mongolab replsets + ec2 directamente

También estoy experimentando este problema en mongolab.

También estamos experimentando este problema en MongoLab y Modulus.

Eche un vistazo a https://jira.mongodb.org/browse/NODE-622 y si alguien puede proporcionar un conjunto completo de registros, sería extremadamente útil para que podamos reproducirlo.

Vamos a sonar aquí, no estamos usando mongoose, sino el cliente nativo de MongoDB. Obteniendo el mismo error no primary server available aquí. Estamos ejecutando un conjunto de réplicas en una instancia EC2 dentro de una VPC privada, nuestra cadena de conexión son las direcciones IP privadas de las instancias. MongoDB v3.0.3 . Me parece que esto sucede cuando hay un alto rendimiento de consultas, ya que en el uso general no se produce el error.

            serverOpts = {
                server: {
                    sslValidate: false,
                    sslCA: ca,
                    socketOptions: {
                        connectTimeoutMS: 30000,
                        socketTimeoutMS: 180000
                    }
                },
                replSet: {
                    connectWithNoPrimary: false,
                    sslValidate: false,
                    sslCA: ca,
                    socketOptions: {
                        connectTimeoutMS: 30000,
                        socketTimeoutMS: 180000
                    }
                }
            };

Parece que hay una solución para esto en las próximas versiones de controladores: NODE-622

¡Nunca es demasiado temprano para los regalos! :)

La versión fija ya se publicó en NPM https://www.npmjs.com/package/mongodb.

Puedo confirmar que ya no recibimos el error. : tada:

PR para mongodb 2.1.2 aquí: https://github.com/Automattic/mongoose/pull/3712

Sigo viendo este error después de actualizar mongoose a 4.3.4 , que usa mongo core 2.1.2 . https://jira.mongodb.org/browse/NODE-622 ha sido reabierto

+1 Acabo de notar que esto también sucede en nuestro servidor de producción. No veo ningún patrón de por qué. Usando el nodo 4.2.4 con mongoose 4.3.4 y mongodb 3.0.8. Utilizo los servicios MMS de mongodb para monitorear mi clúster y no he visto ninguna alerta durante el tiempo en que obtengo: MongoError: no hay servidor primario disponible

@ amit777 ¿Puedes publicar tu cadena de conexión y opciones? Además, ¿ocurrió esto durante una carga de trabajo inusualmente pesada, por ejemplo, muchas escrituras en la base de datos?

Chris, definitivamente sucede durante las operaciones de escritura, aunque no diría que nuestra carga es particularmente pesada. Tenemos un par de nodos en un clúster donde cada nodo escribirá independientemente en mongo.

Así es como nos conectamos:

var mongoose = require('mongoose');
var mongodb = {};

var connect = function () {
mongodb.db = "mongodb://node1:27017,node2:27017,node3:27017/myapp";
mongodb.dbOptions = {
      "db": {"native_parser": true},
      "replSet": {
        "rs_name": "mongocluster",
        "socketOptions": { "keepAlive": 1, "connectTimeoutMS": 30000, "socketTimeoutMS": 60000 }
        }
    };
  mongoose.connect(config.get('mongodb.db'), config.get('mongodb.dbOptions'));
};
connect();

También me di cuenta de que mis registros de mongod se están llenando muy rápido con mensajes de conexión y desconexión:

2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700536] end connection 192.168.1.50:33189 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700534] end connection 192.168.1.50:33187 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700540] end connection 192.168.1.50:33193 (5557 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700538] end connection 192.168.1.50:33191 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700542] end connection 192.168.1.50:33195 (5557 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700532] end connection 192.168.1.50:33185 (5556 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700533] end connection 192.168.1.50:33186 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700535] end connection 192.168.1.50:33188 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700537] end connection 192.168.1.50:33190 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700541] end connection 192.168.1.50:33194 (5551 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700543] end connection 192.168.1.50:33196 (5551 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700539] end connection 192.168.1.50:33192 (5552 connections now open)
2016-01-13T13:32:15.548-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36754 #91705950 (5548 connections now open)
2016-01-13T13:32:15.549-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36755 #91705951 (5549 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36756 #91705952 (5550 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36757 #91705953 (5551 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36758 #91705954 (5552 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36760 #91705955 (5553 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36759 #91705956 (5554 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36762 #91705957 (5555 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36761 #91705958 (5556 connections now open)
2016-01-13T13:32:15.553-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36763 #91705959 (5557 connections now open)
2016-01-13T13:32:15.553-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36764 #91705960 (5558 connections now open)
2016-01-13T13:32:15.554-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36765 #91705961 (5559 connections now open)

Aquí hay información adicional que puede ayudar a depurar. Estoy empezando a pensar que puede haber algún error relacionado con la agrupación de conexiones. Después de reiniciar los procesos de mi nodo, veo que aparecen un montón de nuevas conexiones en mongod.log. Luego, después de aproximadamente un minuto, veo un montón de mensajes de conexión final en mongod.log.

Parece que la conexión / desconexión se amplifica cada vez más rápido con el tiempo (aunque todavía estoy tratando de confirmarlo).

la situación típica que causa esto es algo así como.

Replicaset contiene hosts que el controlador no puede resolver. Cuando el controlador se conecta, utiliza el conjunto de réplicas como fuente canónica para todas las conexiones. Las reconexiones utilizarán esas direcciones. El conductor DEBE poder resolverlos.

También debe evitar el uso de direcciones IP, ya que son una fuente de muchos problemas como este, use nombres de host completamente calificados (sin nombres cortos)

@christkv si el sistema operativo puede resolver los hosts (es decir, haciendo ping), ¿significa esto que el controlador también debería poder resolverlo?

debería ser así, pero siempre puede usar el puerto de nombre de host telnet para verificar.

sí, puedo hacer telnet al host y al puerto ... (todos los hosts de la base de datos tienen entradas / etc / hosts en los servidores de aplicaciones).

Una vez que se inicia nuestra aplicación y se crea el grupo de conexiones, ¿debería haber desconexiones y reconexiones si no hay problemas de red? ¿O hay un tiempo de espera de conexión normal y reconexión que veré en los registros de mongodb?

El problema es que es imposible correlacionar estas cosas para intentar comprender y reproducir el problema sin un conjunto completo de registros (consulte mi último comentario en https://jira.mongodb.org/browse/NODE-622)

si no tiene suficientes operaciones en la ventana de tiempo de espera del socket para ejercitar todas las conexiones, el grupo se cerrará y se volverá a conectar. por lo tanto, si tiene una ventana de 30 segundos y 10 conexiones, pero solo 5 operaciones, se producirá un evento de reconexión cada 30 segundos.

¿Cerrará todas las conexiones a la piscina? o solo las conexiones que no se han ejercido? Si ejercitamos todas las conexiones en 30 segundos, ¿se realizará la misma verificación en la ventana de 30 segundos siguientes?

Intentaré obtener los registros que solicitas en el boleto de mongodb ... gracias por ayudar.

Todos. Si logra ejercitar todas las conexiones en el grupo en la ventana socketTimeout, node.js no agotará el tiempo de espera de los sockets y no se cerrarán forzando una reconexión del grupo.

Un consejo: muchas conexiones solo son útiles si tiene muchas operaciones de ejecución lenta en paralelo; de lo contrario, es más adecuado para un grupo más pequeño, ya que MongoDB usa un hilo por socket, lo que significa que miles de conexiones requieren más memoria asignada en el servidor y provocar más cambios de contexto de CPU.

La próxima revisión importante de mongodb-core cambiará el grupo para que esté creciendo, así como algunos otros cambios fundamentales para minimizar los problemas de trenes lentos. Sin embargo, eso es dentro de varios meses y probablemente estará vinculado con el trabajo de MongoDB 3.4.

¿Cree que es posible / probable que las cantidades masivas de desconexión / reconexión puedan causar intermitentemente el problema de que no hay servidor primario disponible?

sí, ya que habrá un breve período en el que podría no haber servidores en el conjunto

@christkv He estado esperando hasta que esto vuelva a suceder para enviarte algunos registros en ese otro ticket. Nuestro clúster se ha mantenido estable durante las últimas semanas y no hemos visto este error.

@ChrisZieba es curioso cómo siempre parece suceder eso lol: +1: Dejaré el boleto abierto en jira por ahora y veré qué podemos averiguar.

@christkv Hola Christian, tengo curiosidad por saber si tienes alguna sugerencia sobre soluciones en el caso de menos tráfico. Estaba pensando en reducir el tamaño de la piscina y en aumentar los tiempos de espera.

si ayuda a alguien más, eliminé el tiempo de espera del socket y aumenté keepAlive a 200 y también reduje el tamaño de la piscina a 3 ... parece que tengo muchas menos desconexiones / reconexiones ... sin embargo, de vez en cuando sucede.

Si ayuda a alguien, eliminamos casi todas las configuraciones de mongoose, incluidos socketTimeout y connectionTimeout y keepAlive y las conexiones comenzaron a ser estables. Nuestro poolSize es 200.
No estoy seguro de que sea el enfoque recomendado, pero ahora funciona. Todavía lo estamos monitoreando para asegurarnos de que se mantenga.

mangosta v4.4.2
Nodo 4
Mongo 3.0

¿Tiene una gran cantidad de operaciones lentas? Si no lo hace, no creo que note ninguna diferencia entre un grupo de 20 sockets y 500.

Lo siento ... son 200. Se corrigió el comentario.

Y sí, tienes razón. No sentimos mucha diferencia, pero preferimos que el tamaño de la piscina sea más grande que más pequeño.

El verdadero problema cuando las conexiones se mantienen abiertas y no cerradas. Esto solía suceder hasta que eliminamos todos los ajustes de tiempo de espera de mangosta y keepAlive. Me pregunto por qué estos son manejados por mongoose / mongo-driver y no dejan que el sistema operativo lo haga.

Bien 2.1.7 y superior tiene un grupo rediseñado que evita esto. Si configura socketTimeout 0, lo delega en el sistema operativo, pero eso podría ser hasta 10 minutos de conexiones colgadas.

Okay. interesante. Entonces, ahora que eliminé las configuraciones de keepAlive y socketTimeout, ¿cuáles son las configuraciones predeterminadas?

Depende, no estoy seguro de si Mongoose estableció alguna configuración específica como predeterminada. si usa el método MongoClient.connect en el controlador, son 30 segundos para los tiempos de espera de conexión y de socket.

Usamos connect pero cuando configuramos 30 segundos manualmente, las conexiones comienzan a acumularse.

Bueno, con 500 conexiones, necesita al menos 500 operaciones dentro del período de socketTimeout para mantener la piscina abierta; de lo contrario, se cerrará y forzará una reconexión. Sin embargo, esto cambia en 2.1.7 ya que el grupo es un modelo de crecimiento / reducción.

Tengo el mismo problema con mongodb 3.2.6 y mongoose 4.3.4. ¿Alguna ayuda en esto?

@ 15astro intente eliminar la configuración de socketTimeout y connectionTimeout y vea si ayuda.

@refaelos Ok ... lo intentaré ... Lo intenté con keepAlive = 6000 pero eso no ayudó. Solo quería saber cómo ayudará eliminar socketTimeout y connectionTimeout .

Sí, lo probamos con diferentes valores y solo cuando eliminamos por completo estas configuraciones, las cosas comenzaron a funcionar bien.

@refaelos : No encontré suerte al eliminar estas configuraciones. ¿Alguna otra cosa que me falte?

@ 15astro ningún hombre. Lo siento. Así es como se ve nuestra configuración hoy:

mongo   : {
    uri    : process.env.MNG_URL || 'mongodb://localhost/myDB',
    options: {
      user   : process.env.MNG_USER,
      pass   : process.env.MNG_PASS,
      replset: {
        poolSize: 200
      }
    }

  }

En mi caso, estaba relacionado con la falta de IP para el enlace de nombres en / etc / hosts.

Si ha configurado un conjunto de réplicas con nombres en lugar de IP y tiene algo como esto en / etc / hosts de los nodos de MongoDB:

10.10.10.10 mongodb-2gb-fra1-02 10.10.10.11 mongodb-2gb-fra1-01 10.10.10.12 mongodb-2gb-fra1-03

Luego, también debe colocarlo en / etc / hosts de todos los servidores de su aplicación.

Pensé que node-mongo se conecta de acuerdo con lo que puse en el URI, pero no es el caso.

Parece que node-mongo se conecta por IP o nombre de Mongo URI, luego obtiene los nombres de host de otros miembros de réplica del primer nodo de MongoDB que respondió a la solicitud. Obtiene, por ejemplo, mongodb-2gb-fra1-03 y lo pasa al sistema operativo para su resolución. Si el sistema operativo no sabe nada sobre mongodb-2gb-fra1-03 , arroja "Error no hay servidor primario disponible".

Espero que ayude.

@adriank sí, eso es correcto, basa sus conexiones de las que obtiene de la configuración del conjunto de réplicas. La razón es que esta es la fuente canónica de la verdad sobre un conjunto de réplicas. Esta es también la razón por la que el controlador debe poder resolver todas las direcciones en la configuración del conjunto de réplicas para que el controlador realice la conmutación por error correctamente y pueda detectar servidores que se agregan y eliminan del conjunto. Los controladores anteriores no implementaron la especificación SDAM y eran más laxos. Sin embargo, esto causaría problemas en los entornos de producción.

@christkv Sin embargo, es una pesadilla para herramientas como nuestro MongoSpector . Por eso, tenemos problemas para conectarnos de forma segura a más de una réplica de un host. DigitalOcean genera automáticamente nombres en gotas que casi nadie cambia y el efecto es que muchos clientes tienen mongodb-2gb-fra1-01 como su PRIMARIO. :) Espero que podamos resolver algo.

Estamos rastreando un ticket de servidor aquí https://jira.mongodb.org/browse/SERVER-1889. Me encantaría que algo así fuera posible.

También deberíamos presentar un ticket a DigitalOcean señalando el error que están cometiendo y cómo está afectando a sus usuarios.

por cierto, puede eliminar y volver a agregar los miembros del conjunto de réplicas con sus nuevos nombres como ips

Al tener un problema similar, después de aproximadamente 12-24 horas de estar conectado, aparece un error "No hay servidor primario disponible".

El reinicio generalmente soluciona el problema.

conexión:
{ "url": "mongodb://user:password@cluser-shard-00-00, cluser-shard-00-01, cluster-shard-00-02/settings?ssl=true&replicaSet=primarycluster-shard-0&authSource=admin&retryWrites=true", "options": { "db": { "w": 1, "wtimeout": 3000, "fsync": true }, "authSource": "admin", "server": { "poolSize": 3, "socketOptions": { "autoReconnect": true, "keepAlive": 60000, "connectTimeoutMS": 7000, "socketTimeoutMS": 15000 } } }, "password": "password", "username": "username" }