Mongoose: Ne pas se reconnecter après la déconnexion

+1, a eu 2 pannes au cours des 5 derniers jours liées à ce problème. Ma solution de contournement actuelle consiste à faire planter mon processus explicitement ( process.exit(0) ) lorsque l'événement disconnected est émis. Ensuite, le processus est redémarré et la connexion correctement ouverte à nouveau.

Je suppose que la mangouste essaie de se reconnecter, mais échoue dans l'intervalle reconnectTries * reconnectInterval , et l'événement error n'est pas émis en raison de cette régression (https://github.com/Automattic/mongoose/pull /4653). Ce que je ne sais pas, c'est pourquoi mongoose/mongo se déconnecte au hasard, je n'avais pas ce comportement auparavant.
Quel hébergement mongo utilisez-vous ? mLab ?

Nous l'hébergons nous-mêmes dans AWS. Malheureusement, process.exit(0) n'est pas une option pour nous.

J'ai appliqué les modifications au #4653 et j'ai obtenu le même comportement. Déconnexion après quelques heures :

2016-10-27T11:26:42 pid:5276 MONGODB sync_reports_db connected successfully.
2016-10-27T11:26:42 pid:5276 MONGODB sync_reports_db opened successfully.
.... 2 hours later
2016-10-27T13:45:45 pid:5276 MONGODB sync_reports_db disconnected
2016-10-27T13:45:45 pid:5276 MONGODB CLOSE sync_reports_db

Aucun événement error émis ? (devrait être 30 secondes après le disconnected )

Non, regardez le code dans la description du problème. À moins que je fasse quelque chose de mal, il y a un gestionnaire d'événement en place pour l'événement error . En fait, le processus est toujours en cours et la mangouste n'a déclenché aucun autre événement.

Nous avons eu les mêmes problèmes ces derniers jours depuis 4.6.5 - des déconnexions aléatoires qui bloquent le processus de nœud. Mais pas d'événement error . Revenir à 4.5.3 fonctionne.

@loris est-ce lié à https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad en 4.6.6 ?

@mck Oui, https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad corrige l'événement error qui n'est pas émis lorsque le mécanisme de nouvelle tentative de connexion mongodb échoue. Cependant, je n'ai aucune idée de la raison pour laquelle des déconnexions aléatoires se produisent en premier lieu, une idée @vkarpov15?

fwiw, cela nous arrivait 40-50% du temps si nous essayions de faire une opération de sauvegarde/mise à jour (écrit environ 650kb)

Oui, je n'ai pas vraiment beaucoup de bonnes idées. Vous pouvez essayer d'appeler close() sur la connexion, puis vous rappeler vous-même connect() . @loris avez-vous une expérience similaire où une sauvegarde/mise à jour lourde semble provoquer cela ?

Nous sommes également confrontés à cela. Sur l'un de nos services, nous obtenons un événement d'erreur (connexion N à ds0XXXXX-a0.mongolab.com:XXXXX a expiré), suivi d'un événement déconnecté. Et la connexion ne se rétablit jamais. Sur un autre service, nous obtenons un événement déconnecté après une forte demande sur la base de données, c'est-à-dire la suppression d'enregistrements 2M. Et puis il est impossible de se reconnecter (mongoose 4.6.6, DB version 3.0.12).

Cela nous est arrivé à nouveau, il y a quelques minutes, d'exécuter aussi mongodb sur mLab (pas sûr que ce soit lié). Nous avons exécuté une requête lourde, elle a expiré ( unhandledRejection { MongoError: connection 0 to ds****-a0.mongolab.com:**** timed out } , l'événement disconnected a été correctement émis, mais rien après, non error , non reconnected etc, ainsi, ce serveur Web a continué à fonctionner et à recevoir des requêtes HTTP, mais elles ont toutes expiré jusqu'à ce que nous le redémarrions, car il continuait à exécuter des requêtes de mangouste qui se mettaient en mémoire tampon et ne revenaient jamais.

Notre configuration de mangouste (4.6.5 sur le nœud 7.0.0) :

const mongoConnectOpts = { reconnectTries: 10, reconnectInterval: 500, socketOptions: { keepAlive: 300000, connectTimeoutMS: 30000 } };
mongoose.connect(process.env.MONGODB_URI, { server: mongoConnectOpts, replset: mongoConnectOpts });
mongoose.connection.on('error', err => {
  console.log({ event: 'mongoose:error', ...err });
  process.exit(0);
});
mongoose.connection.on('connected', () => console.log({ event: 'mongoose:connected' }));
mongoose.connection.on('disconnected', () => console.log({ event: 'mongoose:disconnected' }));
mongoose.connection.on('reconnected', () => console.log({ event: 'mongoose:reconnected' }));

La solution de contournement temporaire consisterait à process.exit(0) également sur l'événement disconnected pour forcer le serveur Web à redémarrer et à configurer une nouvelle connexion mongodb. Des idées?

Oui, j'ai déjà entendu parler de ce genre de chose avec mlab. TBH dans ce cas, je ferais planter le serveur et redémarrer, un réseau très lent et irrégulier a tendance à causer des problèmes au pilote mongodb et j'imagine que le débogage impliquerait une coordination avec mlab.

Je ne sais pas ce qui ne va pas maintenant (mongoose, pilote mongo, mlab ou heroku), mais depuis quelques jours, l'exécution d'une requête Web qui exécute une requête mangouste lourde (prenant plus de 30 secondes pour répondre) déclenchera une requête heroku timeout (il s'agit d'un mécanisme dans heroku qui expire toute requête Web prenant plus de 30 s). Une fois que cette demande Web a expiré, toute demande Web suivante sur ce serveur qui nécessite une requête de mangouste expirera également. Ce qui est un vrai problème, c'est que l'événement ZERO est déclenché par la mangouste (pas de error , close , disconnected , etc...), nous n'avons donc aucun moyen de détecter le déconnexion et redémarrez le serveur. Voici comment nous configurons la mangouste :

mongoose.Promise = global.Promise;
mongoose.set('debug', process.env.NODE_ENV === 'development');
const mongoConnectOpts = { reconnectTries: 10, reconnectInterval: 500, socketOptions: { keepAlive: 300000, connectTimeoutMS: 30000 } };
mongoose.connect(process.env.MONGODB_URI, { server: mongoConnectOpts, replset: mongoConnectOpts });
mongoose.connection.on('error', err => {
  logfmt.log({ event: 'mongoose:error', ...err });
  process.exit(0);
});
mongoose.connection.on('connected', () => logfmt.log({ event: 'mongoose:connected', uri: _.truncate(process.env.MONGODB_URI) }));
mongoose.connection.on('disconnected', () => {
  logfmt.log({ event: 'mongoose:disconnected' });
  process.exit(0);
});
mongoose.connection.on('close', () => logfmt.log({ event: 'mongoose:close' }));
mongoose.connection.on('reconnected', () => logfmt.log({ event: 'mongoose:reconnected' }));

// Setup Redis cache (Default cache TTL: 60 seconds)
cachegoose(mongoose, { engine: 'redis', client: redisCache }, process.env.NODE_ENV === 'development');

@Ioris pouvez-vous voir si cela se produit toujours si vous désactivez le cachegoose ?

@vkarpov15 J'essaierai de vérifier cela, mais ce n'est pas facile car le bogue ne se produit qu'en production et nous ne pouvons pas nous permettre d'exécuter la production avec le cache désactivé.
@aartiles @mck- @lushchick utilisez-vous le plugin de cache de mangouste ?

Il est possible que cela soit lié à https://github.com/christkv/mongodb-core/issues/148. J'ai rencontré un problème similaire lorsqu'un membre d'un jeu de réplicas devient indisponible.

Nous n'utilisons pas le plugin de cache de mangouste.

Je suis toujours en train de me renseigner, ce que je peux vous dire pour l'instant :

• J'ai pu reproduire le problème sur ma machine locale : je lance une boucle en exécutant une requête rapide toutes les secondes et en enregistrant les résultats, un peu plus tard, j'exécute une requête lourde (comme une requête non indexée sur une collection d'un million de lignes). Toutes les requêtes (les plus rapides aussi) seront verrouillées/expirées, aucun événement mangouste ne sera déclenché.
• Le problème est apparu dans 4.6.5 , rétrograder à 4.6.4 résoudre le problème (les requêtes rapides sont toujours exécutées pendant que la requête lourde est en cours d'exécution)
• On dirait que ça n'a rien à voir avec :
  
  
  
  • le plugin cache mangouste
  
  
  • exécuter ou non un jeu de réplicas
  
  

J'ai creusé davantage et le problème est survenu avec la mise à niveau vers [email protected] , et le commit buggy est https://github.com/mongodb/node-mongodb-native/pull/1418
il semble qu'ils aient corrigé une faute de frappe, mais ce nom d'événement (avec la faute de frappe) est utilisé par certains deps

@loris Savez-vous où se trouvent les références restantes avec le mauvais nom d'événement ? Je peux faire un PR pour le réparer mais je n'arrive pas à en trouver.

@jakesjews Je ne trouve pas non plus de références, donc je me trompe peut-être sur la raison pour laquelle j'ai peut-être vérifié les versions incompatibles sur ma machine, je vous répondrai

Avoir un problème similaire : un échec de reconnexion après une déconnexion. Cela se manifeste dans le client en s'accrochant à toute opération de base de données mangouste (expiration du délai via la mise en mémoire tampon de l'opération).

@jakesjews mon problème est également unique aux jeux de réplicas et ne se produit pas avec une connexion à un seul nœud. En regardant plus dans le noyau replset.js.

Activé la journalisation de débogage dans le nœud-mongodb-native pour voir si la reconnexion HA fonctionnait comme prévu, il semble que ce soit le cas.

attemptReconnect for replset with id successful resuming topologyMonitor 1

Bien que le pilote node-mongodb-native prétende avoir effectué avec succès sa tentative de reconnexion, mongoose n'émettra jamais d' événement connecté ou reconnecté comme il le fait lorsqu'un seul nœud non-replset se reconnecte.

Comme @loris l'a mentionné, process.exit(0) -> le redémarrage du service fonctionnerait (dans mon cas) car le problème est directement lié à la reconnexion à un jeu de réplicas mais encore une fois pas idéal.

[email protected]
[email protected]

@mck- Trouvé le même que vous, la rétrogradation à 4.5.3 a résolu le problème de reconnexion pour ma connexion au jeu de réplicas.

Je peux mettre à niveau jusqu'à 4.5.10 avant qu'il ne commence à échouer à 4.6.0, où le problème de reconnexion du jeu de réplicas se produit pour la première fois. L'hypothèse actuelle est que cela pourrait être lié à la mise à niveau vers le pilote mongodb 2.2.9.

@loris pourriez-vous fournir votre cas de test afin que nous puissions l'essayer ?

Je suis toujours en train de le regarder, je me suis trompé précédemment à propos du commit de correction de faute de frappe. Il semble que le coupable soit https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f
Fournir un cas de test est un peu compliqué car cela ne se produit que de cette façon :

• mongoose 4.6.8 , connexion à mon localhost mongodb (3.2) avec les paramètres par défaut
• 2 routes express, l'une exécutant une requête mangouste longue (plusieurs secondes), l'autre exécutant une requête mangouste rapide (le problème ne se produit pas lors de l'exécution des requêtes mangouste directement dans le nœud, avec le cas de test setInterval/setTimeout par exemple, donc je suppose que c'est lié à la façon dont la connexion au pool est gérée)
• Si j'exécute l'itinéraire express de longue durée, puis essayez d'atteindre l'itinéraire rapide, ce dernier continuera à fonctionner sans revenir
• En définissant poolSize sur 50 au lieu de celui par défaut, résolvez le problème
• La vérification du commit précédent de mongodb-core résout également le problème (la route express rapide revient en quelques ms pendant le traitement de la route longue) (avec la taille du pool par défaut)
• Donc je suppose que https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f a changé quelque chose dans la façon dont une seule mangouste de longue durée peut utiliser chaque connexion disponible dans un pool

Un correctif vient d'arriver dans mongo-core qui pourrait résoudre ce problème.

@loris ouais augmenter la taille de la piscine aidera. On dirait que vous rencontrez le problème du train lent où le serveur mongodb ne peut pas gérer plus de poolSize requêtes simultanément. L'augmentation de la taille du pool aidera, mais ne l'augmentez pas trop, ou vous commencerez à voir des problèmes de performances avec WiredTiger.

Salut,
Une mise à jour pour ceci? Je vois le même problème, auto_reconnect ne fonctionne pas lors de l'utilisation d'un jeu de répliques. Je viens d'essayer mongoose 4.7.0 avec mongodb 2.2.11 et je ne me reconnecte toujours pas. J'utilise mongod version 3.2.10.

J'exécute tout sur un seul hôte (ordinateur portable) avec trois instances de mongod s'exécutant sur différents ports avec différents répertoires de bases de données. Cela ne semble pas être un problème, mais je suis nouveau sur mongo/mongoose/node/javascript. Mon application de nœud avec mongoose s'exécute également sur le même hôte.

Je peux reproduire cela en fermant simplement tous les processus mongod
(launchctl stop mongod01 ; launchctl stop mongod02 ; launchctl stop mongod03)
attendez le message de fermeture de la connexion puis redémarrez (remplacez "stop" par "start" dans les commandes launchctl). Mon application ne se reconnecte jamais à mongo.

Si je fais le même test avec une seule instance de mongod non configurée en tant que jeu de répliques, mongoose se reconnecte bien.

heureux de fournir des journaux ou d'essayer des correctifs si cela est utile.

Après avoir fait quelques recherches, je pense que j'ai peut-être trouvé une source du problème. Il semble que lorsque la reconnexion automatique est vraie, le tampon de connexion n'est pas censé devenir actif https://github.com/Automattic/mongoose/blob/master/lib/drivers/node-mongodb-native/connection.js#L153 lors de la connexion fermer les événements. Cependant, il n'y a plus de propriété autoReconnect définie dans la classe replset dans mongodb-native https://github.com/mongodb/node-mongodb-native/blob/2.2/lib/replset.js donc tout événement proche de l'un des nœuds provoque l'activation permanente du tampon. J'ai eu un peu de chance avec le commit https://github.com/eflexsystems/mongoose/commit/5ac12727f34b41791f94643b66c8cc88aff4d66a mais je veux lui donner un peu plus de temps pour voir si cela a causé d'autres problèmes avant de faire une pull request.

@joeldodson, vous décrivez le même problème que j'ai rencontré. Juste une mise en garde >= 4.6.0 semble contenir le problème. J'essayerais 4.5.10 en attendant, il s'est reconnecté à un replset et à une connexion unique très bien pour moi.

Merci @jakesjews et @kog13

J'ai essayé 4.5.10 et la mangouste se reconnecte après avoir redémarré le jeu de répliques. Cependant, le db.readyState ne semble pas être effacé après l'arrêt de toutes les instances du jeu de réplicas. Nous vérifions cela pour déterminer s'il faut rejeter les demandes (afin qu'elles ne fassent pas la queue en attendant que l'application se reconnecte à la base de données). De plus, je n'ai pas reçu les notifications de déconnexion ou de fermeture de connexion avec 4.5.10.

J'ai déjà une logique qui se trouve dans une boucle avec une minuterie de 5 secondes pour essayer de se connecter si la base de données n'est pas disponible au démarrage de l'application. Nous avons essayé d'appeler cela dans le gestionnaire db.on('closed', function(){...}) et cela semble fonctionner correctement. Ma préoccupation est de savoir si essayer explicitement de se connecter aura des conflits avec une logique de reconnexion sous le capot. Étant donné que la reconnexion ne semble pas se produire pour les jeux de répliques, je pense que tout va bien. Nous définissons également auto_reconnect sur false dans les options de connexion pour le serveur et le replset.

@jakesjews - J'ai essayé le correctif que vous avez mentionné ci-dessus mais je n'ai toujours pas réussi à me reconnecter. J'ai peut-être raté quelque chose, mais il semblait que ce correctif visait davantage à garantir que l'événement de fermeture est généré et que le readyState est mis à jour.

Je suis heureux d'essayer d'autres correctifs pour auto_reconnect si quelqu'un en a. Je vais continuer à creuser aussi.

Merci.

@joeldodson en plus du correctif ci-dessus, vous devrez également dépendre de la dernière version de mongo-core qui contient des correctifs pour s'assurer que la connexion du moniteur du jeu de répliques reste active. Si vous essayez ma fourche, elle devrait déjà l'avoir.

Je pense que je suis dans une assez bonne position en ce qui concerne les délais d'attente et le basculement maintenant avec la mangouste. Si quelqu'un d'autre veut l'essayer, vous voudrez utiliser mon fork de mangouste en plus de définir socketTimeout sur 0 dans socketOptions.

La raison pour laquelle socketTimeout est défini sur 0 est qu'il existe un bogue dans mongo-core pour lequel je dois toujours signaler un problème. Le problème est causé par le pool de connexions qui se réduit/se développe dynamiquement. La façon dont le pool fonctionne est que chaque fois qu'il ajoute une nouvelle connexion, cette connexion se ferme après 30 secondes d'inactivité. Les événements de délai d'expiration déclenchent la suppression du pool et effectuent également une vérification comparant le nombre de délais d'expiration à une limite de 30 tentatives de connexion. Il y a une pulsation qui s'exécute toutes les 2 secondes et efface le nombre de temporisations, mais si 30 demandes ou plus sont mises en file d'attente en parallèle, elles expireront toutes entre les pulsations et détruiront le pool de connexions. Pour l'instant, définir le délai d'expiration des connexions sur 0 empêche les connexions d'être élaguées dans le pool si elles sont inactives et évite le problème. Si vous souhaitez reproduire le problème, essayez de définir une taille de pool de connexions à environ 50 et d'exécuter 50 requêtes parallèles. Après cela, la piscine sera détruite dans environ 30 secondes. Notez que le délai d'expiration n'affecte pas la pulsation vérifiant le jeu de réplicas car celui-ci a son propre délai d'expiration.

J'ai été vraiment submergé par le travail récemment, donc je n'ai pas eu l'occasion de rassembler tous ces changements ensemble, mais j'espère y arriver bientôt.

Merci encore @jakesjews. J'ai récupéré vos dépôts de mangouste et mongodb-core. La reconnexion a fonctionné. Je n'ai pas reçu les événements "connecté" et "reconnecté" que j'obtiens lors de l'utilisation d'une seule instance de Mongo. De plus, le readyState ne semble pas être réinitialisé, il est toujours à 0 même après la reconnexion.

Je suis heureux de vous aider à tester ou à collecter des journaux.

Toujours le problème avec [email protected]

Du nouveau à ce sujet ?

Vivre les problèmes aussi ici. J'ai dû annuler la mise à niveau de la version mangouste en raison de problèmes de connexion. Une requête qui prend quelques secondes met actuellement en attente notre connexion, alors que ce n'était pas le cas auparavant.

Ce problème doit être traité sinon le package n'est pas utilisable.
J'essaierai probablement la solution

Si le problème est un bogue avec mongo-core, ce n'est pas vraiment un problème avec mongoose. Si vous rencontrez le problème avec la version la plus récente de mongoose, pouvez-vous signaler un problème dans le dépôt mongodb-core ?

En fait, c'est un problème avec mongoose car il a été mis à jour pour dépendre de la version de mongodb-core ayant un problème. Peut-être que mongoose devrait être restauré vers une version précédente de mongodb-core .

@jakesjews Voyant que [email protected] dépend [email protected] , qui à son tour dépend de [email protected] , en appliquant les correctifs de votre fourchette serait tout ce qui est nécessaire pour résoudre ce problèmes avec apparemment aucun effet secondaire?

Et en regardant votre fork, ce commit est maintenant le seul changement nécessaire pour un PR 4.7.x et/ou 4.8.x ?

@Koslun, la fourchette devrait être inutile maintenant. Le correctif consiste à peu près simplement à définir socketTimeout sur 0 pour la base de données socketOptions maintenant.

Voici à quoi ressemblent mes options de socket maintenant.

    var opts = {
      server: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
      },
      replSet: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
    }

@jakesjews Ok, merci pour la clarification rapide :).

Savez-vous dans quelle version de mongodb-core nous verrons un correctif pour ce bogue ? Ou bien avez-vous un problème, un RP ou un engagement que nous pouvons suivre ?

Des mises à jour concernant le commentaire de @Koslun ?

Des mises à jour pour ce problème ?

Le problème est toujours ouvert à partir de 2016 :open_mouth:

Je me demande si ce problème peut toujours se produire avec mongoose 5.x avec le pilote mongodb 3.3.4 et le serveur MongoDB en version 4.x ? :pensée:

Est-ce que quelqu'un sait si le reconnectTries est réinitialisé lorsque la reconnexion est réussie.

Instance Fox, si reconnectTries est défini sur 30, et une fois déconnecté, la mangouste essaie 5 fois et la connexion est réussie.
La prochaine fois que la connexion est perdue, quel sera le compteur de nouvelles tentatives ?
Essaiera-t-il de se reconnecter 30 fois ?
Ou 25 fois ?

@szabolcs-szilagyi oui, mais seulement si vous ne définissez pas useUnifiedTopology sur true .

@ bhaveshvyas007 oui c'est le cas. Voici le code correspondant

Pour la postérité :

Si vous exécutez Mongoose 5.x sans useUnifiedTopology , lisez ce guide pour gérer les connexions MongoDB .

Si vous utilisez Mongoose 5.x avec useUnifiedTopology , ce problème ne vous concerne pas.