Mongoose: Kein Primärserver verfügbar

Im Moment springt nichts heraus. Sind Sie sicher, dass keiner der Mongodb-Server abstürzt? Können Sie mit der Shell auch eine stabile Verbindung aufrechterhalten?

Wenn Sie den Befehl db.runCommand( { replSetGetStatus : 1 } ) während der Fehler auftrat, wird auf allen drei Knoten "health" : 1, erzeugt. Es gibt auch eine Primärmenge "stateStr" : "PRIMARY", auf einem der Knoten.

Stellen Sie eine Verbindung mit derselben Verbindungszeichenfolge und dem DNS her? Sieht auch so aus, als ob Ihr Speicher nach dem Problem flach ausgekleidet ist. Können Sie noch einmal überprüfen, ob auf einem Ihrer Computer nicht mehr genügend Festplattenspeicher vorhanden ist?

Stellen Sie eine Verbindung mit derselben Verbindungszeichenfolge und dem DNS her?

Ich habe nicht dieselbe Verbindungszeichenfolge verwendet. Denken Sie, dass die Verwendung der privaten EC2-IP-Adressen dies beheben würde?

Ich bin mir nicht sicher, warum der Speicher so maximal wird, aber selbst nach dem Booten neuer Instanzen tritt das Problem ohne Primärserver immer noch auf, wenn genügend Speicherplatz verfügbar ist.

Die EC2-IP-Adressen können hilfreich sein, je nachdem, wie Ihr Replikatsatz konfiguriert ist. Können Sie mir die Ausgabe von rs.status() aus der Shell zeigen ?

Dies ist der rs.status (), während die Verbindungen auf dem Vormarsch sind.

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

Nichts Außergewöhnliches im Replikatset. Haben Sie andere relevante Codebeispiele, zum Beispiel Code, der auf Mungo-Verbindungsereignisse reagiert?

Ein weiteres potenzielles Problem, das Sie in Betracht ziehen sollten: Verwenden Sie einen aktuellen neuen Reliktagenten? Ich würde versuchen, ohne neues Relikt zu laufen und zu sehen, ob dies immer noch passiert. Neue Relikt-Affen-Patches patchen den Mongodb-Treiber, sodass dies manchmal zu unerwartetem Verhalten führen kann.

Wir haben die Mungo-Verbindungsereignisse ausgegeben:

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

So sehen einige der Protokolle aus

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

Ich war diese Woche beim Mongodb Days Event, wo ich einige Zeit einplanen und dieses Problem einem der leitenden Ingenieure bei MongoDB zeigen konnte, und sie waren sich nicht sicher, was das Problem war. Sie haben erwähnt, dass der Replikationssatz und die maximale Poolgröße zur Verbindungszeichenfolge hinzugefügt werden sollen, wodurch dieses Problem leider nicht behoben wurde.

Wir haben auch versucht, das Keep Alive zu deaktivieren und es für die Instanzen auf einen kleineren Wert zu setzen, aber das schien dies auch nicht zu beheben.

Wir verwenden newrelic Version 1.24.0 und mongo-express-patch Version 0.21.1 . Ich werde versuchen, ohne newrelic zu laufen, um zu sehen, ob dies das behebt.

Hmm ja, es sieht so aus, als würde sich der Mungo aus irgendeinem Grund wieder verbinden. Können Sie mir die Ausgabe von npm list | grep "mongoose" und 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]

Wofür verwenden Sie mongodb-core ? Laufen Sie auch mit mongo-express das in prod aktiviert ist?

Derzeit wird mongodb-core für nichts verwendet. Denken Sie, dass die Versionsinkongruenz zwischen der Mungoabhängigkeit Probleme verursachen kann?

Wir haben mongo-express in der Produktion aktiviert.

Nicht, dass ich davon Wüste. Ich versuche nur zu sehen, ob es andere Verbindungen zu Mongodb gibt, die zu diesem Problem beitragen könnten. Ich habe ein wenig gegoogelt - verwenden Sie für Ihre Verbindungszeichenfolge dieselben DNS-Namen wie in rs.status() ? Demnach können ähnliche Probleme auftreten, wenn Sie ein anderes DNS für die Verbindungszeichenfolge verwenden, als Ihr Replikatsatz denkt.

Dieser Fehler tritt auf, wenn in der Verbindungszeichenfolge dasselbe DNS wie im Attribut "syncingTo" in rs.status() . Dies tritt auch auf, wenn die interne ec2-IP in der Verbindungszeichenfolge verwendet wird.

Das einzige, was ich noch nicht ausprobiert habe, ist, connectWithNoPrimary auf true .

Ich würde auch versuchen, mit mongo-express zu laufen. Das könnte Probleme verursachen ...

Wir haben das gleiche Problem. Wir haben einen Standort mit einer Dauerlast von etwa 100 U / min und Spitzenwerten von 500 bis 700 U / min. Es scheint, dass wir dies während des gesamten Prozesses auch in relativ ruhigen Zeiträumen sehen.

Umgebung:
Heroku - 75 2x Dynos - Node.JS 5.1.1
Datenbank - MongoLabs Dedicated Cluster M4 - Version 3.0.7

Verbindungszeichenfolge:
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
};

Protokollierung:
Wir haben eine ganze Menge Überwachung aktiviert, um dies zu versuchen und zu debuggen, daher habe ich unsere Raygun-Stack-Traces in das sogar aufgenommen, dass dies beim Debuggen helfen würde. _Hinweis: _ Dies ist genau die gleiche Zeilennummer, die @ChrisZieba in der obigen

Nachricht: Kein Primärserver verfügbar
Object.pickServer in /app/node_modules/mongodb-core/lib/topologies/replset.js:860
ReplSet.ReplSet.command in /app/node_modules/mongodb-core/lib/topologies/replset.js:437
ReplSet.ReplSet.command in /app/node_modules/mongodb/lib/replset.js:392
Object.executeCommand in /app/node_modules/mongodb/lib/db.js:281
Befehl Db.Db. in /app/node_modules/mongodb/lib/db.js:305
Object.wrapped in /app/node_modules/newrelic/lib/instrumentation/mongodb.js:185
Object.findAndModify in /app/node_modules/mongodb/lib/collection.js:2327
Collection.Collection.findAndModify in /app/node_modules/mongodb/lib/collection.js:2265
Object.wrapped in /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.wrappedQuery in /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. (In der Funktion anonym) [als findAndModify] (/app/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:136
NodeCollection.NodeCollection.findAndModify in /app/node_modules/mquery/lib/collection/node.js:79
Query.Query._findAndModify in /app/node_modules/mongoose/lib/query.js:1833
Query.Query._findOneAndUpdate in /app/node_modules/mongoose/lib/query.js:1621
unbekannt. [anonym] in /app/node_modules/kareem/index.js:156
unbekannt. [anonym] in /app/node_modules/kareem/index.js:18
Object.wrapped in /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.doNTCallback0 in node.js: 430
process.process._tickCallback in node.js: 359

Überwachung:

Diese Stapelverfolgung sagt mir wirklich nur, dass 1) Sie ein neues Relikt verwenden (was sehr fraglich ist, da das neue Relikt viele Affen-Patches des Mongodb-Treibers ausführt) und 2) der Mongodb-Treiber denkt, dass es kein primäres gibt verfügbar, aber ich bin nicht sicher warum.

Versuchen Sie, den Debug-Modus des Mongodb-Treibers zu aktivieren, indem Sie Ihren Verbindungsoptionen replset: { loggerLevel: 'debug' } hinzufügen.

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

Dadurch werden viele Treiber-Debug-Daten in stdout protokolliert und wir können herausfinden, was falsch läuft. Können Sie diese Daten erfassen, wenn der Fehler "Kein Primärserver gefunden" auftritt?

Danke @ vkarpov15 ,

Wir haben das hinzugefügt und werden zurückmelden, sobald wir einen anderen ausgelöst haben.

Prost,
Roy

Ich denke nicht, dass Newrelic hier das Problem ist. Wir haben versucht, ohne es zu laufen, und dieses Problem besteht weiterhin. Sammelt einige Protokolldaten von loggerLevel: 'debug' und veröffentlicht sie hier.

Vielen Dank, lassen Sie mich wissen, wenn Sie weitere Details zu dem Fehler erhalten.

Ein weiterer Datenpunkt: Mongoose löst das Ereignis "Wiederverbindung" immer wieder aus, wenn die Anzahl der Verbindungen zunimmt.

Die Fehler "Kein Primärserver verfügbar" lösen normalerweise aus, nachdem die Anzahl der Verbindungen bereits zu steigen begonnen hat.

Auch dieses Problem haben wir erlebt. Mit haben eine Node-App auf Heroku mit MongoLab gehostet.
Letzte Woche haben wir plötzlich die Verbindung zur Datenbank verloren und immer wieder die Nachricht Error no primary server available . Durch einen Neustart unserer App wurde das Problem behoben.
Sowohl Heroku als auch MonogLab sahen nichts in ihren Protokollen.
Ich hoffe, jemand findet eine Lösung dafür.

Bump - Wir sehen dies bei node v4.2.3 mongoose v4.1.5 bei einer großen Produktionsbereitstellung. Es ist schwer, dieses Problem zu lösen, da es:

• Fehler nicht konsistent, was uns daran hindert, Maßnahmen zu ergreifen (Prozess neu starten / Knoten herausnehmen)
• geschieht zufällig und scheint nicht mit dem Mongo-Replset-Status zu korrelieren

@sansmischevia benutzt du auch mongolab + heroku?

^ Dieses Problem tritt bei einer großen Produktionsbereitstellung unter AWS EC2 mit selbst gehosteten Mongodb-Servern über Cloud Manager auf.

Hallo,

Wir würden uns auch gerne einschalten.
Wir führen node v0.12.8 , mongo v2.6.11 mit 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]

Es ist häufig während eines Vorgangs reproduzierbar, bei dem die Datenbank mit vielen Abfragen erstellt wird. Unsere Anwendung scheint danach nicht betroffen zu sein. Während dieser Zeit sind keine Fehler im Mongo-Protokoll und in unserem Replikatsatz mit drei Knoten fehlerfrei.

Wir werden loggerLevel: 'debug' versuchen und uns zurückmelden.

@ vkarpov15 wir sind auf mongolab replsets + ec2 direkt

Ich habe dieses Problem auch bei Mongolab.

Dieses Problem tritt auch bei MongoLab und Modulus auf.

Werfen Sie einen Blick auf https://jira.mongodb.org/browse/NODE-622 und wenn jemand einen vollständigen Satz von Protokollen bereitstellen kann, wäre dies äußerst hilfreich, damit wir ihn reproduzieren können.

Wir werden hier drin läuten, wir verwenden keinen Mungo, sondern den nativen MongoDB-Client. Hier wird der gleiche Fehler no primary server available angezeigt. Wir führen ein Replikatset auf einer EC2-Instanz in einer privaten VPC aus. Unsere Verbindungszeichenfolge sind die privaten IP-Adressen der Instanzen. MongoDB v3.0.3 . Es scheint mir, dass dies passiert, wenn ein hoher Durchsatz von Abfragen vorliegt, da der Fehler im Allgemeinen nicht auftritt.

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

Anscheinend gibt es in den kommenden Treiberversionen eine Lösung dafür:

Für Geschenke ist es nie zu früh! :) :)

Die feste Version wurde bereits auf NPM https://www.npmjs.com/package/mongodb veröffentlicht.

Ich kann bestätigen, dass wir den Fehler nicht mehr erhalten. : tada:

PR für mongodb 2.1.2 hier: https://github.com/Automattic/mongoose/pull/3712

Nach dem Upgrade von Mungo auf 4.3.4 , bei dem der Mongo-Kern 2.1.2 verwendet wird, wird dieser Fehler immer noch angezeigt. https://jira.mongodb.org/browse/NODE-622 wurde wieder geöffnet

+1 Ich habe gerade bemerkt, dass dies auch auf unserem Produktionsserver passiert. Ich sehe kein Muster dafür, warum. Verwenden von Knoten 4.2.4 mit Mungo 4.3.4 und Mongodb 3.0.8. Ich verwende die MMS-Dienste von mongodb, um meinen Cluster zu überwachen, und habe während der folgenden Zeit keine Warnungen gesehen: MongoError: Kein Primärserver verfügbar

@ amit777 Kannst du deine Verbindungszeichenfolge und Optionen posten? Ist dies auch während einer ungewöhnlich hohen Arbeitsbelastung aufgetreten, z. B. bei vielen Schreibvorgängen in die Datenbank?

Chris, es passiert definitiv während des Schreibvorgangs, obwohl ich nicht sagen würde, dass unsere Last besonders schwer ist. Wir haben ein paar Knoten in einem Cluster, in denen jeder Knoten unabhängig in Mongo schreibt.

So verbinden wir uns:

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

Ich habe auch gerade bemerkt, dass sich meine Mongod-Protokolle sehr schnell mit Verbindungs- und Verbindungsmeldungen füllen:

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)

Hier sind einige zusätzliche Informationen, die beim Debuggen hilfreich sein können. Ich fange an zu glauben, dass möglicherweise ein Fehler im Zusammenhang mit dem Verbindungspooling vorliegt. Nachdem ich meine Knotenprozesse neu gestartet habe, werden im mongod.log eine Reihe neuer Verbindungen angezeigt. Nach ungefähr einer Minute sehe ich in mongod.log eine Reihe von Endverbindungsnachrichten.

Es scheint, als würde sich das Verbinden / Trennen mit der Zeit immer schneller verstärken (obwohl ich immer noch versuche, dies zu bestätigen).

Die typische Situation, die dies verursacht, ist so etwas wie.

Replicaset enthält Hosts, die vom Treiber nicht aufgelöst werden können. Wenn der Treiber eine Verbindung herstellt, verwendet er das Replikat als kanonische Quelle für alle Verbindungen. Bei erneuten Verbindungen werden diese Adressen verwendet. Sie MÜSSEN vom Fahrer aufgelöst werden können.

Sie sollten auch die Verwendung von IP-Adressen vermeiden, da diese viele Probleme verursachen. Verwenden Sie vollständig qualifizierte Hostnamen (keine Kurznamen).

@christkv, wenn das Betriebssystem die Hosts auflösen kann (dh durch Ping), bedeutet dies, dass der Fahrer auch in der Lage sein sollte, eine Lösung zu finden?

Es sollte ja sein, aber Sie können immer den Telnet-Hostnamen-Port verwenden, um dies zu überprüfen.

Ja, ich kann mit dem Host und dem Port telneten. (Alle Datenbankhosts haben / etc / hosts-Einträge auf den Anwendungsservern.)

Sollte es nach dem Start unserer App und dem Erstellen des Verbindungspools jemals zu Unterbrechungen und erneuten Verbindungen kommen, wenn keine Netzwerkprobleme vorliegen? Oder gibt es ein normales Verbindungszeitlimit und eine erneute Verbindung, die in den Mongodb-Protokollen angezeigt wird?

Das Problem ist, dass es unmöglich ist, diese Dinge zu korrelieren, um zu versuchen, das Problem ohne einen vollständigen Satz von Protokollen zu verstehen und zu reproduzieren (siehe meinen letzten Kommentar unter https://jira.mongodb.org/browse/NODE-622).

Wenn Sie im Socket-Timeout-Fenster nicht genügend Operationen haben, um alle Verbindungen auszuführen, wird der Pool geschlossen und die Verbindung wiederhergestellt. Wenn Sie also ein 30-Sekunden-Fenster und 10 Verbindungen, aber nur 5 Operationen haben, wird alle 30 Sekunden ein Ereignis zum erneuten Verbinden ausgelöst.

Wird es alle Verbindungen zum Pool schließen? oder nur die Verbindungen, die nicht ausgeübt wurden? Wenn wir alle Verbindungen innerhalb von 30 Sekunden ausführen, wird dieselbe Überprüfung im nächsten 30-Sekunden-Fenster durchgeführt?

Ich werde versuchen, die von Ihnen angeforderten Protokolle im Mongodb-Ticket zu erhalten. Vielen Dank für Ihre Unterstützung.

Alle. Wenn Sie es schaffen, alle Verbindungen im Pool im Fenster socketTimeout auszuüben, wird bei node.js das Zeitlimit für die Sockets nicht überschritten und es wird nicht geschlossen, um eine erneute Verbindung des Pools zu erzwingen.

Ein Tipp Viele Verbindungen sind nur dann nützlich, wenn Sie viele langsam laufende Vorgänge parallel ausführen. Andernfalls sind Sie besser für einen kleineren Pool geeignet, da MongoDB einen Thread pro Socket verwendet, was bedeutet, dass Tausende von Verbindungen mehr zugewiesenen Speicher auf dem Server benötigen und dies auch tun werden verursachen mehr CPU-Kontextwechsel.

Die nächste größere Überarbeitung des Mongodb-Kerns wird das Wachstum des Pools sowie einige andere grundlegende Änderungen ändern, um Probleme mit langsamen Zügen zu minimieren. Das ist jedoch einige Monate her und wird wahrscheinlich mit der MongoDB 3.4-Arbeit verbunden sein.

Sehen Sie es als möglich / wahrscheinlich an, dass die massiven Mengen an Trennung / Wiederverbindung zeitweise dazu führen können, dass kein primärer Server verfügbar ist?

Ja, da es eine kurze Zeit geben wird, in der möglicherweise keine Server im Set vorhanden sind

@christkv Ich habe gewartet, bis dies wieder passiert, um Ihnen einige Protokolle in diesem anderen Ticket zu senden. Unser Cluster war in den letzten Wochen tatsächlich stabil und wir haben diesen Fehler nicht gesehen.

@ChrisZieba lustig, wie das immer zu passieren scheint lol: +1: Ich lasse das Ticket vorerst in Jira offen und sehe, was wir herausfinden können.

@christkv Hallo Christian, ich bin nur neugierig, ob du

Wenn es jemand anderem hilft, habe ich das Socket-Timeout entfernt sowie keepAlive auf 200 erhöht und auch die Poolgröße auf 3 reduziert. Ich habe anscheinend viel weniger Verbindungsabbrüche / Wiederverbindungen. Es kommt jedoch gelegentlich immer noch vor.

Wenn es jemandem hilft, haben wir fast alle Mungoeinstellungen entfernt, einschließlich socketTimeout und connectionTimeout und keepAlive, und die Verbindungen wurden stabil. Unsere Poolgröße beträgt 200.
Ich bin nicht sicher, ob es der empfohlene Ansatz ist, aber er funktioniert jetzt. Wir überwachen es immer noch, um sicherzustellen, dass es funktioniert.

Mungo v4.4.2
Knoten 4
Mongo 3.0

Haben Sie eine große Anzahl langsamer Operationen? Wenn Sie dies nicht tun, werden Sie wahrscheinlich keinen Unterschied zwischen einem Pool von 20 Steckdosen und 500 feststellen.

Entschuldigung ... es ist 200. Der Kommentar wurde korrigiert.

Und ja, du hast recht. Wir spüren keinen großen Unterschied, aber wir haben eher eine größere als eine kleinere Poolgröße.

Das eigentliche Problem, wenn Verbindungen weiterhin geöffnet und nicht geschlossen werden. Dies geschah früher, bis wir alle Einstellungen für Mungo-Timeout und KeepAlive entfernt hatten. Ich frage mich, warum diese von Mungo / Mongo-Treiber behandelt werden und das Betriebssystem dies nicht tun lässt.

Nun, 2.1.7 und höher hat einen neu gestalteten Pool, der dies vermeidet. Wenn Sie socketTimeout 0 festlegen, delegieren Sie es an das Betriebssystem. Dies kann jedoch bis zu 10 Minuten dauern, bis Verbindungen hängen bleiben.

OK. interessant. Nachdem ich die Einstellungen für keepAlive und socketTimeout entfernt habe, wie lauten die Standardeinstellungen?

Es hängt davon ab, ob Mungo bestimmte Einstellungen als Standardeinstellung festgelegt hat. Wenn Sie die MongoClient.connect-Methode im Treiber verwenden, sind es 30 Sekunden für das Zeitlimit für Verbindung und Socket.

Wir verwenden connect aber wenn wir 30 Sekunden manuell einstellen, häufen sich die Verbindungen.

Bei 500 Verbindungen benötigen Sie mindestens 500 Operationen innerhalb des SocketTimeout-Zeitraums, um den Pool offen zu halten. Andernfalls wird er geschlossen und eine erneute Verbindung erzwungen. Dies ändert sich jedoch in 2.1.7, da der Pool ein wachsendes / schrumpfendes Modell ist.

Ich habe das gleiche Problem mit Mongodb 3.2.6 und Mungo 4.3.4. Hilfe dazu?

@ 15astro versuche die Einstellungen von socketTimeout und connectionTimeout zu entfernen und zu sehen, ob es hilft.

@refaelos Ok socketTimeout und connectionTimeout hilft?

Ja, wir haben es mit verschiedenen Werten versucht und erst als wir diese Einstellungen vollständig entfernt haben, haben die Dinge gut funktioniert.

@refaelos : Ich habe kein Glück gefunden, diese Einstellungen zu entfernen. Fehlt mir noch etwas?

@ 15astro kein Mann. Es tut uns leid. So sehen unsere Einstellungen heute aus:

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

  }

In meinem Fall lag es am Mangel an IP für die Namensbindung in / etc / hosts.

Wenn Sie ein Replikatset mit Namen anstelle von IPs eingerichtet haben und in / etc / hosts von MongoDB-Knoten Folgendes haben:

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

Dann müssen Sie es auch in / etc / hosts aller Ihrer App-Server ablegen.

Ich dachte, dass Node-Mongo eine Verbindung gemäß dem herstellt, was ich in die URI eingegeben habe, aber das ist nicht der Fall.

Es scheint, dass Node-Mongo eine Verbindung über IP oder Namen von Mongo URI herstellt und dann Hostnamen anderer Replikatmitglieder vom ersten MongoDB-Knoten erhält, der auf die Anfrage geantwortet hat. Es erhält zum Beispiel mongodb-2gb-fra1-03 und übergibt es zur Lösung an das Betriebssystem. Wenn das Betriebssystem nichts über mongodb-2gb-fra1-03 weiß, wird "Fehler kein primärer Server verfügbar" ausgegeben.

Hoffentlich hilft das.

@adriank Ja, das ist richtig. Es basiert auf den Verbindungen derjenigen, die es von der Replikatset-Konfiguration zurückerhält. Der Grund ist, dass dies die kanonische Quelle der Wahrheit über ein Replikat ist. Aus diesem Grund müssen alle Adressen in der Replikatsatzkonfiguration vom Treiber aufgelöst werden können, damit der Treiber ein korrektes Failover durchführt und Server erkennen kann, die zum Satz hinzugefügt und daraus entfernt werden. Frühere Treiber haben die SDAM-Spezifikation nicht implementiert und waren laxer. Dies würde jedoch Probleme in Produktionsumgebungen verursachen.

@christkv Es ist jedoch ein Albtraum für Tools wie unseren MongoSpector . Aus diesem Grund haben wir Probleme, eine sichere Verbindung zu mehr als einem Replikat von einem Host herzustellen. DigitalOcean generiert automatisch Namen für Tröpfchen, die fast niemand ändert, und der Effekt ist, dass viele Clients mongodb-2gb-fra1-01 als PRIMARY haben. :) Ich hoffe wir können etwas herausfinden.

Wir verfolgen hier ein Serverticket https://jira.mongodb.org/browse/SERVER-1889. Ich würde es lieben, wenn so etwas möglich wäre.

Wir sollten auch ein Ticket bei DigitalOcean einreichen, das auf den Fehler hinweist, den sie machen, und wie er sich auf ihre Benutzer auswirkt.

Übrigens können Sie die Replikatset-Mitglieder entfernen und wieder hinzufügen, wobei ihre neuen Namen ips sind

Bei einem ähnlichen Problem wird nach ca. 12-24 Stunden Verbindung die Fehlermeldung "Kein Primärserver verfügbar" angezeigt.

Ein Neustart behebt normalerweise das Problem.

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