Mongoose: Aucun serveur principal disponible

Rien ne saute pour le moment. Êtes-vous sûr qu'aucun des serveurs mongodb ne plante? En outre, pouvez-vous maintenir une connexion stable à l'aide du shell?

L'exécution de la commande db.runCommand( { replSetGetStatus : 1 } ) pendant que l'erreur se produisait produit "health" : 1, sur les 3 nœuds. Il existe également un ensemble primaire "stateStr" : "PRIMARY", sur l'un des nœuds.

Vous connectez-vous en utilisant la même chaîne de connexion, en utilisant le DNS? Ressemble également à votre stockage à plat après le problème, pouvez-vous vérifier et voir si vous n'avez plus d'espace disque sur l'une de vos machines?

Vous connectez-vous en utilisant la même chaîne de connexion, en utilisant le DNS?

Je n'utilisais pas la même chaîne de connexion. Pensez-vous que l'utilisation des adresses IP privées EC2 résoudrait ce problème?

Je ne sais pas ce qui cause le maximum de stockage comme ça, mais même après le démarrage de nouvelles instances, le problème sans serveur principal se produit toujours avec beaucoup d'espace disponible.

Les adresses IP EC2 peuvent être utiles, selon la configuration de votre jeu de réplicas. Pouvez-vous me montrer la sortie de rs.status() du shell ?

C'est le rs.status () alors que les connexions sont à la hausse.

{
    "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
}

Rien d'extraordinaire dans le jeu de répliques. Avez-vous d'autres exemples de code pertinents, par exemple, avez-vous du code qui réagit aux événements de connexion mangouste?

Un autre problème potentiel à considérer, utilisez-vous un nouvel agent de relique à jour? J'essaierais de courir sans nouvelle relique et voir si cela se produit toujours, de nouvelles reliques monkey corrigent le pilote mongodb afin que cela puisse parfois conduire à un comportement inattendu.

Nous avons sorti les événements de connexion mangouste:

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

Voici à quoi ressemblent certains des journaux

​[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"
 }
}

J'étais à l'événement des jours de mongodb cette semaine, où j'ai pu programmer un peu de temps et montrer ce problème à l'un des ingénieurs principaux de MongoDB, et ils n'étaient pas sûrs du problème. Ils ont mentionné d'ajouter le jeu de réplication et la taille maximale du pool à la chaîne de connexion, ce qui n'a malheureusement pas résolu ce problème.

Nous avons également essayé de désactiver le maintien en vie et de le définir sur une valeur plus petite sur les instances, mais cela ne semblait pas non plus résoudre ce problème.

Nous utilisons newrelic version 1.24.0 , et mongo-express-patch version 0.21.1 . J'essaierai de courir sans newrelic pour voir si cela résout le problème.

Hmm ouais, il semble que la mangouste se reconnecte pour une raison quelconque. Pouvez-vous me montrer la sortie de npm list | grep "mongoose" et 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]

Pourquoi utilisez-vous mongodb-core ? De plus, utilisez-vous avec mongo-express activé dans prod?

N'utilise actuellement pas mongodb-core pour quoi que ce soit. Pensez-vous que la non-concordance de version entre la dépendance mangouste peut causer des problèmes?

Nous avons activé mongo-express en production.

Pas que je sache de. J'essaie simplement de voir s'il existe d'autres connexions à mongodb qui pourraient contribuer à ce problème. J'ai fait un peu de recherche sur Google - utilisez-vous les mêmes noms DNS pour votre chaîne de connexion que ceux qui apparaissent dans rs.status() ? Selon cela , vous pouvez rencontrer des problèmes similaires si vous utilisez un DNS différent pour la chaîne de connexion que votre jeu de réplicas pense.

Cette erreur se produira lors de l'utilisation du même DNS dans la chaîne de connexion que l'attribut "syncingTo" dans rs.status() . Cela se produit également lors de l'utilisation de l'adresse IP interne ec2 dans la chaîne de connexion.

La seule chose que je n'ai pas encore essayée est de régler connectWithNoPrimary sur true .

J'essaierais également de courir avec mongo-express réduction. Cela pourrait causer des problèmes ...

Nous rencontrons le même problème. Nous avons un site qui connaît une charge soutenue d'environ 100 tr / min avec des pics dans le 500-700 tr / min +. Il semble que nous voyons cela tout au long du processus, même pendant des périodes relativement calmes.

Environnement:
Heroku - 75 2x dynos - Node.JS 5.1.1
Base de données - MongoLabs Dedicated Cluster M4 - Version 3.0.7

Chaîne de connexion:
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
};

Enregistrement:
Nous avons activé une bonne quantité de surveillance pour essayer de déboguer cela, donc j'ai inclus nos traces de pile Raygun dans le même que cela aiderait au débogage. _Note: _ C'est exactement le même numéro de ligne que @ChrisZieba a montré dans la trace ci-dessus.

Message: aucun serveur principal disponible
Object.pickServer dans /app/node_modules/mongodb-core/lib/topologies/replset.js:860
ReplSet.ReplSet.command dans /app/node_modules/mongodb-core/lib/topologies/replset.js:437
ReplSet.ReplSet.command dans /app/node_modules/mongodb/lib/replset.js:392
Object.executeCommand dans /app/node_modules/mongodb/lib/db.js:281
Db.Db.command dans /app/node_modules/mongodb/lib/db.js:305
Object.wrapped dans /app/node_modules/newrelic/lib/instrumentation/mongodb.js:185
Object.findAndModify dans /app/node_modules/mongodb/lib/collection.js:2327
Collection.Collection.findAndModify dans /app/node_modules/mongodb/lib/collection.js:2265
Object.wrapped dans /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.wrappedQuery dans /app/node_modules/newrelic/lib/instrumentation/mongodb.js:218
Object.wrapped in [as findAndModify] (/app/node_modules/newrelic/lib/instrumentation/mongodb.js:188
NativeCollection.NativeCollection. (Anonyme dans la fonction) [as findAndModify] (/app/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:136
NodeCollection.NodeCollection.findAndModify dans /app/node_modules/mquery/lib/collection/node.js:79
Query.Query._findAndModify dans /app/node_modules/mongoose/lib/query.js:1833
Query.Query._findOneAndUpdate dans /app/node_modules/mongoose/lib/query.js:1621
inconnu. [anonyme] dans /app/node_modules/kareem/index.js:156
inconnu. [anonyme] dans /app/node_modules/kareem/index.js:18
Object.wrapped dans /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.doNTCallback0 dans node.js: 430
process.process._tickCallback dans node.js: 359

Surveillance:

Cette trace de pile me dit vraiment que 1) vous utilisez une nouvelle relique (ce qui est très discutable, car la nouvelle relique fait beaucoup de patching de singe du pilote mongodb), et 2) le pilote mongodb pense qu'il n'y a pas de primaire disponible, mais je ne sais pas pourquoi.

Essayez d'activer le mode de débogage du pilote mongodb en ajoutant replset: { loggerLevel: 'debug' } à vos options de connexion, c'est-à-dire:

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

Cela enregistrera un grand nombre de données de débogage de pilote sur stdout et nous aidera à comprendre ce qui ne va pas. Pouvez-vous capturer ces données lorsque l'erreur «Aucun serveur principal trouvé» se produit?

Merci @ vkarpov15 ,

Nous avons ajouté cela et ferons un rapport dès que nous en aurons un autre déclenché.

À votre santé,
Roy

Je ne pense pas que newrelic soit le problème ici. Nous avons essayé de courir sans et ce problème persiste. Collectera des données de journal à partir de loggerLevel: 'debug' et publiera ici.

Merci, faites-moi savoir si vous parvenez à obtenir plus de détails sur l'erreur.

Un autre point de données: Mongoose déclenche l'événement "reconnecté" à mesure que le nombre de connexions augmente.

Les erreurs "aucun serveur principal disponible" déclenchent généralement _après_ le nombre de connexions a déjà commencé à augmenter.

Nous avons également rencontré ce problème. Avec une application Node hébergée sur Heroku avec MongoLab.
La semaine dernière, nous avons soudainement perdu la connexion avec la base de données et avons continué à recevoir le message Error no primary server available . Le redémarrage de notre application a résolu le problème.
Heroku et MonogLab n'ont rien vu dans leurs journaux.
J'espère que quelqu'un trouvera une solution à cela.

Bump - nous voyons cela sur node v4.2.3 mongoose v4.1.5 sur un grand déploiement de production. Difficile de résoudre ce problème car il:

• ne fait pas d'erreur de manière cohérente, ce qui nous empêche d'agir (redémarrer le processus / retirer le nœud)
• se produit au hasard et ne semble pas corrélé au statut de replset mongo

@sansmischevia utilisez-vous également mongolab + heroku?

^ Nous rencontrons ce problème dans un grand déploiement de production sur AWS EC2 avec des serveurs mongodb auto-hébergés via Cloud Manager.

Bonjour,

Nous aimerions également intervenir.
Nous utilisons node v0.12.8 , mongo v2.6.11 avec 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]

Il est souvent reproductible lors d'une opération qui amorce la base de données, impliquant de nombreuses requêtes. Notre application ne semble pas être affectée après cela. Aucune erreur dans le journal mongo et notre jeu de répliques à trois nœuds est sain pendant ce temps.

Nous essaierons loggerLevel: 'debug' et ferons

@ vkarpov15 nous sommes sur les replsets mongolab + ec2 directement

Je rencontre également ce problème sur mongolab.

Nous rencontrons également ce problème sur MongoLab et Modulus.

jetez un œil à https://jira.mongodb.org/browse/NODE-622 et si quelqu'un peut fournir un ensemble complet de journaux qui seraient extrêmement utiles afin que nous puissions le reproduire.

Je vais carillon ici, nous n'utilisons pas la mangouste, mais le client natif MongoDB. Obtenir la même erreur no primary server available ici. Nous exécutons un réplica défini sur une instance EC2 dans un VPC privé, notre chaîne de connexion correspond aux adresses IP privées des instances. MongoDB v3.0.3 . Il me semble que cela se produit lorsqu'il y a un débit élevé de requêtes, car en général, l'erreur ne se produit pas.

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

Il semble qu'il y ait un correctif pour cela dans les prochaines versions de pilotes: NODE-622

Il n'est jamais trop tôt pour les cadeaux! :)

La version corrigée a déjà été publiée sur NPM https://www.npmjs.com/package/mongodb.

Je peux confirmer que nous ne recevons plus l'erreur. : tada:

PR pour mongodb 2.1.2 ici: https://github.com/Automattic/mongoose/pull/3712

Cette erreur persiste après la mise à niveau de mongoose vers 4.3.4 , qui utilise mongo core 2.1.2 . https://jira.mongodb.org/browse/NODE-622 a été rouvert

+1 Je viens de remarquer que cela se produit également sur notre serveur de production. Je ne vois aucun motif de pourquoi. Utilisation du nœud 4.2.4 avec mangouste 4.3.4 et mongodb 3.0.8. J'utilise les services MMS de mongodb pour surveiller mon cluster et je n'ai vu aucune alerte pendant le temps où j'obtiens: MongoError: aucun serveur principal disponible

@ amit777 Pouvez-vous publier votre chaîne de connexion et vos options? De plus, cela s'est-il produit pendant une charge de travail inhabituellement lourde, par exemple, beaucoup d'écritures dans la base de données?

Chris, cela se produit certainement lors des opérations d'écriture, même si je ne dirais pas que notre charge est particulièrement lourde. Nous avons quelques nœuds dans un cluster où chaque nœud écrira indépendamment dans mongo.

Voici comment nous nous connectons:

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

Je viens également de remarquer que mes journaux mongod se remplissent très rapidement de messages de connexion et de déconnexion:

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)

Voici quelques informations supplémentaires qui peuvent aider à déboguer. Je commence à penser qu'il peut y avoir un bogue lié au regroupement de connexions. Après avoir redémarré mes processus de nœud, je vois un tas de nouvelles connexions apparaître dans le mongod.log. Ensuite, après environ une minute, je vois un tas de messages de connexion de fin dans mongod.log.

Il semble que la connexion / déconnexion s'amplifie de plus en plus rapidement avec le temps (bien que j'essaie toujours de le confirmer).

la situation typique causant ceci est quelque chose comme.

Le réplicaset contient des hôtes qui ne peuvent pas être résolus par le pilote. Lorsque le pilote se connecte, il utilise le réplicaset comme source canonique pour toutes les connexions. Les reconnexions utiliseront ces adresses. Ils DOIVENT pouvoir être résolus par le conducteur.

Vous devez également éviter d'utiliser des adresses IP, elles sont une source de nombreux problèmes comme celui-ci, utilisez des noms d'hôtes complets (pas de noms courts)

@christkv si le système d'exploitation est capable de résoudre les hôtes (c'est-à-dire en faisant un ping), cela signifie-t-il que le pilote devrait également pouvoir résoudre?

cela devrait oui, mais vous pouvez toujours utiliser le port de nom d'hôte telnet pour vérifier.

ouais, je suis capable de telnet à l'hôte et au port .. (tous les hôtes de base de données ont des entrées / etc / hosts sur les serveurs d'application).

Une fois notre application démarrée et le pool de connexions créé, devrait-il y avoir des déconnexions et des reconnexions s'il n'y a pas de problèmes de réseau? Ou y a-t-il un délai normal de connexion et de reconnexion que je verrai dans les journaux de mongodb?

Le problème est qu'il est impossible de corréler ces choses pour tenter de comprendre et de reproduire le problème sans un ensemble complet de journaux (voir mon dernier commentaire sur https://jira.mongodb.org/browse/NODE-622)

si vous n'avez pas assez d'opérations dans la fenêtre de temporisation du socket pour exercer toutes les connexions, le pool se fermera et se reconnectera. donc si vous avez une fenêtre de 30 secondes et 10 connexions mais seulement 5 opérations, cela provoquera un événement de reconnexion toutes les 30 secondes.

Va-t-il fermer toutes les connexions à la piscine? ou seulement les connexions qui n'ont pas été exercées? Si nous effectuons toutes les connexions dans les 30 secondes, le même contrôle sera-t-il effectué dans la prochaine fenêtre de 30 secondes?

Je vais essayer d'obtenir les journaux que vous demandez dans le ticket mongodb .. merci pour votre aide.

Tout. Si vous parvenez à exercer toutes les connexions du pool dans la fenêtre socketTimeout, node.js n'expirera pas les sockets et ne se fermera pas, forçant la reconnexion du pool.

Un conseil, beaucoup de connexions ne sont utiles que si vous avez beaucoup d'opérations lentes en parallèle, sinon vous êtes mieux adapté avec un pool plus petit car MongoDB utilise un thread par socket, ce qui signifie que des milliers de connexions nécessitent plus de mémoire allouée sur le serveur et provoquent plus de changements de contexte du processeur.

La prochaine révision majeure de mongodb-core changera le pool pour qu'il s'agrandisse ainsi que d'autres changements fondamentaux pour minimiser les problèmes de trains lents. Cependant, cela reste plusieurs mois et sera probablement lié au travail de MongoDB 3.4.

Pensez-vous qu'il est possible / probable que les quantités massives de déconnexion / reconnexion puissent causer par intermittence le problème d'absence de serveur principal disponible?

oui car il y aura une brève période où il se peut qu'il n'y ait aucun serveur dans l'ensemble

@christkv J'ai attendu que cela se reproduise pour vous envoyer des journaux dans cet autre ticket. Notre cluster est en fait stable depuis quelques semaines et nous n'avons pas vu cette erreur.

@ChrisZieba drôle comment cela semble toujours arriver lol: +1: Je vais laisser le ticket ouvert dans jira pour le moment et voir ce que nous pouvons comprendre.

@christkv Salut Christian, je suis simplement curieux de savoir si vous avez des conseils sur des solutions de contournement dans le cas d'un trafic plus faible. Je pensais simplement réduire la taille de la piscine et augmenter les délais d'attente.

si cela aide quelqu'un d'autre, j'ai supprimé le délai d'expiration du socket ainsi que l'augmentation de keepAlive à 200 et j'ai également réduit la taille du pool à 3 .. je semble avoir beaucoup moins de déconnexion / reconnexion .. mais cela arrive encore occasionnellement.

Si cela aide quelqu'un, nous avons supprimé presque tous les paramètres de mangouste, y compris socketTimeout et connectionTimeout et keepAlive et les connexions ont commencé à être stables. Notre poolSize est de 200.
Je ne suis pas sûr que ce soit l'approche recommandée, mais cela fonctionne maintenant. Nous le surveillons toujours pour nous assurer qu'il tient.

mangouste v4.4.2
Nœud 4
Mongo 3.0

Avez-vous énormément d'opérations lentes? si vous ne le faites pas, je ne pense pas que vous remarquerez une différence entre un pool de 20 sockets vs 500.

Désolé ... c'est 200. Correction du commentaire.

Et oui, tu as raison. Nous ne sentons pas beaucoup de différence, mais nous préférons avoir une taille de piscine plus grande que plus petite.

Le vrai problème avec quand les connexions continuent à s'ouvrir et non fermées. Cela se produisait jusqu'à ce que nous supprimions tous les paramètres de délai d'attente et de keepAlive. Je me demande pourquoi ceux-ci sont gérés par mongoose / mongo-driver et ne pas laisser le système d'exploitation le faire?

Well 2.1.7 et supérieur a un pool repensé qui évite cela. Si vous définissez socketTimeout 0, vous le déléguez au système d'exploitation, mais cela peut représenter jusqu'à 10 minutes de connexions suspendues.

D'accord. intéressant. Alors maintenant que j'ai supprimé les paramètres keepAlive et socketTimeout, quels sont les paramètres par défaut?

cela dépend, je ne sais pas si la mangouste a défini des paramètres spécifiques par défaut. si vous utilisez la méthode MongoClient.connect dans le pilote, les délais de connexion et de socket sont de 30 secondes.

Nous utilisons connect mais lorsque nous définissons manuellement 30 secondes, les connexions commencent à s'accumuler.

Eh bien, avec 500 connexions, vous avez besoin d'au moins 500 opérations à l'intérieur de la période socketTimeout pour garder la piscine ouverte, sinon elle se fermera et forcera une reconnexion. Cela change cependant dans la version 2.1.7 car le pool est un modèle croissant / rétrécissant.

J'ai le même problème avec mongodb 3.2.6 et mongoose 4.3.4. Une aide à ce sujet?

@ 15astro essayez de supprimer les paramètres de socketTimeout et connectionTimeout et voyez si cela aide.

@refaelos Ok ... j'essaierai ça..J'ai essayé avec keepAlive = 6000 mais cela n'a pas aidé. Je voulais juste savoir comment supprimer socketTimeout et connectionTimeout aidera?

Oui, nous l'avons essayé avec des valeurs différentes et seulement lorsque nous avons complètement supprimé ces paramètres, les choses ont commencé à bien fonctionner.

@refaelos : Je n'ai pas eu de chance de supprimer ces paramètres. Une autre chose me manque?

@ 15astro aucun homme. Pardon. Voici à quoi ressemblent nos paramètres aujourd'hui:

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

  }

Dans mon cas, cela était lié au manque d'IP pour la liaison de nom dans / etc / hosts.

Si vous avez configuré un jeu de répliques avec des noms au lieu d'adresses IP et que vous avez quelque chose comme ça dans / etc / hosts des nœuds 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

Ensuite, vous devez également le mettre dans / etc / hosts de tous vos serveurs d'applications.

Je pensais que node-mongo se connectait en fonction de tout ce que je mettais dans l'URI, mais ce n'est pas le cas.

Il semble que node-mongo se connecte par IP ou par nom à partir de l'URI Mongo, puis obtient les noms d'hôte des autres membres de la réplique à partir du premier nœud MongoDB qui a répondu à la demande. Il obtient par exemple mongodb-2gb-fra1-03 et le transmet au système d'exploitation pour la résolution. Si le système d'exploitation ne sait rien sur mongodb-2gb-fra1-03 , il lance "Erreur aucun serveur principal disponible".

J'espère que cela pourra aider.

@adriank oui c'est correct, il base ses connexions avec celles qu'il récupère de la configuration du réplicaset. La raison en est que c'est la source canonique de vérité sur un réplicaset. C'est également pourquoi toutes les adresses de la configuration du réplicaset doivent pouvoir être résolues par le pilote pour que le pilote bascule correctement et pour qu'il puisse détecter les serveurs ajoutés et supprimés de l'ensemble. Les pilotes précédents n'ont pas mis en œuvre la spécification SDAM et où plus laxiste. Cela poserait cependant des problèmes dans les environnements de production.

@christkv Cependant, c'est un cauchemar pour des outils comme notre MongoSpector . À cause de cela, nous avons des problèmes de connexion sécurisée à plus d'une réplique à partir d'un hôte. DigitalOcean génère automatiquement des noms de gouttelettes que presque personne ne change et l'effet est que de nombreux clients ont mongodb-2gb-fra1-01 comme PRIMAIRE. :) J'espère que nous pouvons trouver quelque chose.

Nous suivons un ticket de serveur ici https://jira.mongodb.org/browse/SERVER-1889. J'aimerais que quelque chose comme ça soit possible.

Nous devrions également déposer un ticket auprès de DigitalOcean indiquant l'erreur qu'ils font et comment cela affecte leurs utilisateurs.

en passant, vous pouvez supprimer et rajouter les membres du réplicaset avec leurs nouveaux noms étant ips

Ayant un problème similaire, après environ 12 à 24 heures de connexion, nous obtenons une erreur "Aucun serveur principal disponible"

Le redémarrage résout généralement le problème.

lien:
{ "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" }