Mongoose: Nach Trennung nicht wieder verbinden

+1, hatte in den letzten 5 Tagen 2 Ausfälle im Zusammenhang mit diesem Problem. Meine aktuelle Problemumgehung besteht darin, meinen Prozess explizit zum Absturz zu bringen ( process.exit(0) ), wenn das Ereignis disconnected ausgegeben wird. Dann wird der Prozess neu gestartet und die Verbindung wieder ordnungsgemäß geöffnet.

Ich vermute, dass Mungo versucht, sich erneut zu verbinden, aber innerhalb des reconnectTries * reconnectInterval Intervalls fehlschlägt und das error Ereignis aufgrund dieser Regression nicht ausgegeben wird (https://github.com/Automattic/mongoose/pull /4653). Was ich nicht weiß, ist, warum Mungo / Mongo zufällig getrennt werden, ich hatte dieses Verhalten vorher nicht.
Welches Mongo-Hosting betreibst du? mLab?

Wir hosten es selbst in AWS. Leider ist process.exit(0) für uns keine Option.

Ich habe die Änderungen bei #4653 angewendet und das gleiche Verhalten erhalten. Verbindungsabbruch nach ein paar Stunden:

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

Kein error Ereignis ausgegeben? (sollte 30 Sekunden nach dem disconnected eins sein)

Nein, sehen Sie sich den Code in der Problembeschreibung an. Sofern ich nichts falsch mache, gibt es einen Ereignishandler für das error Ereignis. Tatsächlich läuft der Prozess noch und Mungo hat kein anderes Ereignis ausgelöst.

Wir haben in den letzten Tagen seit 4.6.5 die gleichen Probleme – zufällige Verbindungsabbrüche, die dazu führen, dass der Knotenprozess stecken bleibt. Aber kein error Ereignis. Die Rückkehr zu 4.5.3 funktioniert.

@loris hängt das mit https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad in 4.6.6 ?

@mck Ja, https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad behebt das error Ereignis, das nicht ausgegeben wird, wenn der mongodb-Verbindungswiederholungsmechanismus fehlschlägt. Ich habe jedoch keine Ahnung, warum es überhaupt zu zufälligen Verbindungsabbrüchen kommt, eine Idee @ vkarpov15?

fwiw, es passierte uns 40-50% der Zeit, wenn wir versuchten, eine Speicher- / Aktualisierungsoperation durchzuführen (etwa 650 kb schreiben)

Ja, ich habe nicht wirklich viele gute Ideen. Sie können versuchen, close() über die Verbindung anzurufen und dann erneut connect() anzurufen. @loris haben Sie eine ähnliche Erfahrung, bei der ein

Auch wir sind damit konfrontiert. Bei einem unserer Dienste erhalten wir ein Fehlerereignis (Verbindung N zu ds0XXXXX-a0.mongolab.com:XXXXX Timeout), gefolgt von einem getrennten Ereignis. Und die Verbindung wird nie wieder hergestellt. Bei einem anderen Dienst erhalten wir nach einer intensiven Anfrage an die DB ein getrenntes Ereignis, dh das Entfernen von 2 Millionen Datensätzen. Und dann kann es keine Verbindung mehr herstellen (Mungo 4.6.6, DB-Version 3.0.12).

Es ist uns gerade wieder passiert, vor ein paar Minuten, mongodb auch auf mLab laufen zu lassen (nicht sicher, ob es damit zusammenhängt). Wir haben eine schwere Abfrage ausgeführt, es ist eine Zeitüberschreitung aufgetreten ( unhandledRejection { MongoError: connection 0 to ds****-a0.mongolab.com:**** timed out } , das Ereignis disconnected wurde ordnungsgemäß ausgegeben, aber nichts danach, kein error , kein reconnected usw. Daher lief dieser Webserver weiter und empfing HTTP-Anfragen, aber alle haben eine Zeitüberschreitung, bis wir ihn neu gestartet haben, weil er weiterhin Mungo-Abfragen ausgeführt hat, die gepuffert und nie zurückgegeben wurden.

Unser Mungo-Setup (4.6.5 auf Knoten 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' }));

Eine vorübergehende Problemumgehung wäre, process.exit(0) auch beim disconnected Ereignis zu erzwingen, um den Webserver zu einem Neustart und einer neuen Mongodb-Verbindung zu zwingen. Irgendwelche Ideen?

Ja, ich habe schon von solchen Dingen gehört, die mit mlab passiert sind. TBH in diesem Fall würde ich einfach den Server zum Absturz bringen und neu starten, wirklich langsames, fleckiges Netzwerk neigt dazu, Probleme für den mongodb-Treiber zu verursachen, und ich würde mir vorstellen, dass das Debuggen die Koordination mit mlab beinhaltet.

Ich bin mir nicht sicher, was jetzt falsch ist (Mungo, Mongo-Treiber, Mlab oder Heroku), aber in den letzten Tagen löst das Ausführen einer Webanfrage, die eine schwere Mungo-Abfrage ausführt (die Antwort dauert mehr als 30 Sekunden), eine Heroku-Anfrage aus timeout (dies ist ein Mechanismus in heroku, der jede Webanfrage, die länger als 30 Sekunden dauert, abbricht). Sobald diese Webanfrage abgelaufen ist, wird auch jede folgende Webanfrage auf diesem Server, die eine Mungo-Abfrage erfordert, eine Zeitüberschreitung haben. Ein echtes Problem ist, dass das NULL-Ereignis von Mungos ausgelöst wird (kein error , close , disconnected usw.), sodass wir keine Möglichkeit haben, dies zu erkennen Trennen Sie die Verbindung und starten Sie den Server neu. So richten wir Mungo ein:

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 können Sie sehen, ob dies immer noch passiert, wenn Sie Cachegoose deaktivieren?

@vkarpov15 Ich werde versuchen, dies zu überprüfen, aber nicht einfach, da der Fehler nur in der Produktion
@aartiles @mck- @lushchick verwendet ihr das Mungo-Cache-Plugin?

Es ist möglich, dass dies mit https://github.com/christkv/mongodb-core/issues/148 zusammenhängt. Ich bin auf ein ähnliches Problem gestoßen, wenn ein Mitglied eines Replikatsatzes nicht verfügbar ist.

Wir verwenden kein Mungo-Cache-Plugin.

Ich suche noch nach, was ich dir bisher sagen kann:

• Ich konnte das Problem auf meinem lokalen Computer reproduzieren: Ich starte eine Schleife, die alle Sekunden eine schnelle Abfrage ausführt und die Ergebnisse protokolliere. Alle Abfragen (auch die schnellen) werden gesperrt/timeout, es wird kein Mungo-Ereignis ausgelöst.
• Das Problem trat in 4.6.5 , ein Downgrade auf 4.6.4 behebt das Problem (die schnellen Abfragen werden immer noch ausgeführt, während die schwere Abfrage ausgeführt wird).
• Anscheinend hat das nichts zu tun mit:
  
  
  
  • das Mungo-Cache-Plugin
  
  
  • einen Replikatsatz ausführen oder nicht
  
  

Ich habe mehr gegraben und das Problem trat beim Upgrade auf [email protected] , und der fehlerhafte Commit dort ist https://github.com/mongodb/node-mongodb-native/pull/1418
es sieht so aus, als hätten sie einen Tippfehler behoben, aber dieser eventName (mit dem Tippfehler) wird von einigen Deps verwendet

@loris Wissen Sie, wo sich die verbleibenden Referenzen mit dem falschen Ereignisnamen befinden? Ich kann eine PR machen, um das Problem zu beheben, aber ich kann keine finden.

@jakesjews Ich kann auch keine Referenzen finden, daher ausgecheckt habe. Ich werde mich bei Ihnen

Habe ein ähnliches Problem: ein Fehler beim Wiederverbinden nach einer Trennung. Dies manifestiert sich im Client, indem er an einer Mungo-DB-Operation hängt (Zeitüberschreitung durch Operationspufferung).

@jakesjews Mein Problem

Debug-Protokollierung innerhalb von node-mongodb-native aktiviert, um zu sehen, ob die HA-Wiederverbindung wie erwartet funktioniert hat.

attemptReconnect for replset with id successful resuming topologyMonitor 1

Obwohl der node-mongodb-native Treiber behauptet, dass er seinen tryReconnect erfolgreich durchgeführt hat, wird mongoose niemals ein verbundenes oder wieder verbundenes Ereignis ausgeben, wie es der Fall ist, wenn ein einzelner Knoten, der nicht replset ist, erneut verbunden wird.

Wie @loris erwähnt, würde process.exit(0) -> Neustart des Dienstes (in meinem Fall) funktionieren, da das Problem direkt mit der erneuten Verbindung zu einem Replikatsatz zusammenhängt, aber auch hier nicht ideal.

[email protected]
[email protected]

@mck- Das gleiche wie Sie gefunden, ein Downgrade auf 4.5.3 hat das Problem

Ich kann bis 4.5.10 aktualisieren, bevor es bei 4.6.0 fehlschlägt, wo das Reconnect-Problem zum ersten Mal auftritt. Derzeit wird vermutet, dass es mit dem Upgrade auf den mongodb-Treiber 2.2.9 zusammenhängen könnte.

@loris Könnten Sie Ihren Testfall bereitstellen, damit wir ihn ausprobieren können?

Ich schaue es mir immer noch an, ich habe mich zuvor mit dem Tippfehler-Fix-Commit geirrt. Es sieht so aus, als wäre der Täter https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f
Die Bereitstellung eines Testfalls ist etwas kompliziert, da dies nur so geschieht:

• mongoose 4.6.8 , verbindet sich mit meinem localhost mongodb (3.2) mit Standardeinstellungen
• 2 Expressrouten, eine mit einer lang laufenden Mungo-Abfrage (mehrere Sekunden), eine mit einer schnell laufenden Mungo-Abfrage (das Problem tritt nicht auf, wenn die Mungo-Abfragen direkt im Knoten ausgeführt werden, z. B. mit dem Testfall setInterval/setTimeout, Ich vermute also, dass es damit zusammenhängt, wie die Poolverbindung gehandhabt wird)
• Wenn ich die Langstrecken-Express-Route ausführe, dann versuche die Schnellstrecke zu treffen, diese läuft weiter, ohne zurückzukehren
• Setzen Sie poolSize auf 50 anstelle des Standardwerts, um das Problem zu beheben
• Das Auschecken des vorherigen Commits von mongodb-core behebt das Problem ebenfalls (die schnell laufende Expressroute kehrt in wenigen ms zurück, während die lang laufende Route verarbeitet wird) (mit der Standardpoolgröße)
• Also denke ich, dass https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f etwas daran geändert hat, wie ein einzelner langlaufender Mungo jede verfügbare Verbindung in einem Pool nutzen kann

Ein Fix ist gerade in Mongo-Core gelandet, der dieses Problem beheben könnte.

@loris ja, eine Erhöhung der poolSize Anfragen gleichzeitig verarbeiten kann. Das Erhöhen der Poolgröße wird helfen. Erhöhen Sie es nur nicht zu sehr, sonst treten Leistungsprobleme mit WiredTiger auf.

Hi,
Gibt es hierzu Neuigkeiten? Ich sehe das gleiche Problem, auto_reconnect funktioniert nicht, wenn ein Replikatsatz verwendet wird. Ich habe gerade Mongoose 4.7.0 mit mongodb 2.2.11 ausprobiert und immer noch keine Verbindung hergestellt. Ich verwende Mongod-Version 3.2.10.

Ich führe alles auf einem einzigen Host (Laptop) aus, wobei drei Instanzen von Mongod auf verschiedenen Ports mit unterschiedlichen Datenbankverzeichnissen ausgeführt werden. Scheint kein Problem zu sein, aber ich bin neu bei Mongo/Mungo/Knoten/Javascript. Meine Node-App mit Mungo läuft auch auf demselben Host.

Ich kann das reproduzieren, indem ich einfach alle Mongod-Prozesse herunterfahre
(launchctl stop mongod01; launchctl stop mongod02; launchctl stop mongod03)
warten Sie auf die Meldung "Verbindung geschlossen" und starten Sie dann neu (ersetzen Sie "stop" durch "start" in den launchctl-Befehlen). Meine App verbindet sich nie wieder mit Mongo.

Wenn ich denselben Test mit einer einzelnen Instanz von Mongod durchführe, die nicht als Replikatsatz konfiguriert ist, verbindet sich Mongoose wieder einwandfrei.

Ich freue mich, Protokolle bereitzustellen oder Patches auszuprobieren, wenn dies hilfreich ist.

Nachdem ich etwas gegraben habe, denke ich, dass ich eine Ursache des Problems gefunden haben könnte. Es sieht so aus, als ob der Verbindungspuffer nicht aktiv werden soll, wenn Autoreconnect wahr ist https://github.com/Automattic/mongoose/blob/master/lib/drivers/node-mongodb-native/connection.js#L153 bei Verbindung Veranstaltungen schließen. Es gibt jedoch keine autoReconnect-Eigenschaft mehr, die in der replset-Klasse in mongodb-native https://github.com/mongodb/node-mongodb-native/blob/2.2/lib/replset.js festgelegt wird bewirkt, dass der Puffer dauerhaft aktiviert wird. Ich hatte etwas Glück mit dem Commit https://github.com/eflexsystems/mongoose/commit/5ac12727f34b41791f94643b66c8cc88aff4d66a, aber ich möchte ihm noch etwas Zeit geben, um zu sehen, ob es andere Probleme verursacht, bevor ich eine Pull-Anfrage stelle.

@joeldodson Sie beschreiben das gleiche Problem, das ich erlebt habe. Nur ein Heads-Up-Release >= 4.6.0 scheint das Problem zu enthalten. Ich würde in der Zwischenzeit 4.5.10 versuchen, es hat sich wieder mit einem Replset und einer einzelnen Verbindung verbunden, für mich ist es gut.

Danke @jakesjews und @kog13

Ich habe 4.5.10 ausprobiert und Mungo verbindet sich nach dem Neustart des Replikatsatzes erneut. Allerdings scheint db.readyState nicht gelöscht zu werden, nachdem alle Instanzen im Replikatsatz gestoppt wurden. Wir überprüfen dies, um festzustellen, ob Anfragen abgelehnt werden (damit sie sich nicht in die Warteschlange stellen, bis die App wieder eine Verbindung zur DB herstellt). Außerdem habe ich mit 4.5.10 keine Benachrichtigungen über getrennte oder geschlossene Verbindungen erhalten.

Ich habe bereits eine Logik, die mit einem 5-Sekunden-Timer in einer Schleife sitzt, um zu versuchen, eine Verbindung herzustellen, wenn die DB beim Start der App nicht verfügbar ist. Wir haben versucht, das im db.on('closed', function(){...})-Handler aufzurufen, und es scheint gut zu funktionieren. Meine Sorge ist jedoch, ob der explizite Versuch, eine Verbindung herzustellen, zu Konflikten mit der Wiederverbindungslogik unter der Haube führt. Da die Wiederverbindung bei Replikatsätzen nicht zu erfolgen scheint, denke ich, dass es in Ordnung ist. Außerdem setzen wir auto_reconnect in den Verbindungsoptionen sowohl für den Server als auch für das Replset auf false.

@jakesjews - Ich habe den oben erwähnten Patch ausprobiert, aber immer noch keine erneute Verbindung erhalten. Vielleicht habe ich etwas übersehen, aber es sah so aus, als ob es bei diesem Patch mehr darum ging, sicherzustellen, dass das Close-Ereignis generiert und der readyState aktualisiert wird.

Ich freue mich, weitere Patches für auto_reconnect auszuprobieren, falls jemand welche hat. Ich werde auch weiter stöbern.

Danke.

@joeldodson Zusätzlich zum obigen Patch müssen Sie sich auch auf die neueste Version von Mongo-Core verlassen, die Korrekturen enthält, um sicherzustellen, dass die Monitorverbindung des Replikatsatzes am Leben bleibt. Wenn du meine Gabel ausprobierst, sollte sie es schon haben.

Ich denke, dass ich in Bezug auf Timeouts und Failover jetzt mit Mungo an einem ziemlich guten Ort bin. Wenn es jemand anderes ausprobieren möchte, sollten Sie zusätzlich zum Setzen von socketTimeout auf 0 in den socketOptions meine Mungogabel verwenden.

Der Grund für das Setzen von socketTimeout auf 0 ist, dass es einen Fehler in mongo-core gibt, für den ich noch ein Problem melden muss. Das Problem wird durch den dynamisch verkleinerten/erweiternden Verbindungspool verursacht. Der Pool funktioniert so, dass jedes Mal, wenn eine neue Verbindung hinzugefügt wird, diese Verbindung nach 30 Sekunden Inaktivität geschlossen wird. Timeout-Ereignisse lösen das Entfernen aus dem Pool aus und führen außerdem eine Prüfung durch, die die Anzahl der Timeouts mit einem Limit von 30 Verbindungsversuchen vergleicht. Es gibt einen Heartbeat, der alle 2 Sekunden ausgeführt wird und die Anzahl der Timeouts löscht, aber wenn 30 oder mehr Requests parallel in die Warteschlange gestellt werden, führt dies dazu, dass alle zwischen dem Heartbeat ablaufen und den Verbindungspool zerstören. Das Setzen des Zeitlimits für die Verbindungen auf 0 verhindert derzeit, dass Verbindungen zurück in den Pool bereinigt werden, wenn sie inaktiv sind, und vermeidet das Problem. Wenn Sie das Problem replizieren möchten, versuchen Sie, eine Verbindungspoolgröße auf etwa 50 festzulegen und 50 parallele Abfragen auszuführen. Danach wird der Pool in etwa 30 Sekunden zerstört. Beachten Sie, dass sich das Timeout nicht auf die Heartbeat-Überprüfung des Replikatsatzes auswirkt, da dieses über ein eigenes Timeout verfügt.

Ich war in letzter Zeit wirklich mit Arbeit überhäuft, daher hatte ich keine Gelegenheit, all diese Änderungen zusammen zu sammeln, aber ich hoffe, dass ich bald dazu komme.

Danke nochmal @jakesjews. Ich habe Ihre Mungo- und Mongodb-Core-Repos eingezogen. Das Wiederverbinden hat funktioniert. Ich habe jedoch nicht die Ereignisse "verbunden" und "wieder verbunden" erhalten, die ich erhalte, wenn ich eine einzelne Instanz von Mongo verwende. Auch der readyState scheint nicht zurückgesetzt zu werden, er ist auch nach dem Reconnect immer noch 0.

Ich helfe gerne beim Testen oder Sammeln von Protokollen.

Habe immer noch das Problem mit [email protected]

Gibt es etwas Neues zu diesem Thema?

Erlebe die Probleme auch hier. Musste das Upgrade der Mungo-Version aufgrund von Verbindungsproblemen rückgängig machen. Eine Abfrage, die einige Sekunden dauert, führt derzeit zu einem Timeout unserer Verbindung, wo dies zuvor nicht der Fall war.

Dieses Problem muss behoben werden, sonst ist das Paket nicht verwendbar.
Werde wahrscheinlich

Wenn das Problem ein Fehler bei Mongo-Core ist, ist dies bei Mongoose nicht wirklich ein Problem. Wenn das Problem mit der neuesten Version von Mongoose auftritt, können Sie es im mongodb-core Repository einreichen?

Tatsächlich ist es ein Problem mit mongoose da es aktualisiert wurde, um von der Version von mongodb-core abhängig zu sein, die ein Problem hat. Vielleicht sollte mongoose auf eine frühere Version von mongodb-core wiederhergestellt werden.

@jakesjews zu sehen , dass [email protected] abhängt [email protected] , was wiederum davon abhängt , [email protected] , das Updates von Ihrer Anwendung Gabel würde alles sein , was erforderlich ist , diese Probleme zu beheben scheinbar ohne Nebenwirkungen?

Und wenn Sie sich Ihren Fork ansehen, ist dieser Commit jetzt die einzige Änderung, die für eine 4.7.x- und/oder 4.8.x-PR erforderlich ist?

@Koslun die Gabel sollte jetzt unnötig sein. Der Fix besteht darin, socketTimeout jetzt für die SocketOptions der Datenbank auf 0 zu setzen.

So sehen meine Socket-Optionen jetzt aus.

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

@jakesjews Ok, danke für die schnelle Klärung :).

Wissen Sie, in welcher Version von mongodb-core dieser Fehler behoben wird? Oder haben Sie alternativ ein Problem, eine PR oder ein Commit, das wir verfolgen können?

Irgendwelche Updates zum @Koslun- Kommentar?

Irgendwelche Updates für dieses Problem?

Das Thema ist ab 2016 noch offen :open_mouth:

Ich frage mich, ob dieses Problem bei Mongoose 5.x mit Mongodb-Treiber 3.3.4 und MongoDB-Server in Version 4.x immer noch auftreten kann? :Denken:

Weiß jemand, ob der reconnectTries zurückgesetzt wird, wenn die erneute Verbindung erfolgreich war.

Fox-Instanz, wenn reconnectTries auf 30 gesetzt ist und Mungo nach dem Trennen 5 Mal versucht und die Verbindung erfolgreich ist.
Wenn die Verbindung das nächste Mal unterbrochen wird, wie lautet der Zähler für Wiederholungen?
Wird es 30 Mal versuchen, sich wieder zu verbinden?
Oder 25 mal?

@szabolcs-szilagyi ja, aber nur, wenn Sie useUnifiedTopology auf true .

@ bhaveshvyas007 ja, das tut es. Hier ist der entsprechende Code

Für die Nachwelt:

Wenn Sie Mongoose 5.x ohne useUnifiedTopology ausführen , lesen Sie

Wenn Sie Mongoose 5.x mit useUnifiedTopology ausführen, betrifft Sie dieses Problem nicht.