Mongoose: कोई प्राथमिक सर्वर उपलब्ध नहीं है

फिलहाल कुछ भी लीक नहीं हुआ है। क्या आपको यकीन है कि कोई भी मोंगोडब सर्वर क्रैश नहीं हो रहा है? इसके अलावा, क्या आप शेल का उपयोग करके एक स्थिर कनेक्शन बनाए रख सकते हैं?

कमांड db.runCommand( { replSetGetStatus : 1 } ) चल रहा है जबकि त्रुटि हो रही थी सभी 3 नोड्स पर "health" : 1, उत्पादन होता है। नोड्स में से एक पर एक प्राथमिक सेट "stateStr" : "PRIMARY", भी है।

क्या आप DNS का उपयोग करके उसी कनेक्शन स्ट्रिंग का उपयोग कर कनेक्ट कर रहे हैं? इस मुद्दे के बाद भी आपका स्टोरेज फ्लैट-लाइनेड जैसा दिखता है, क्या आप अपनी किसी मशीन पर हार्ड ड्राइव स्पेस से बाहर निकल कर चेक कर सकते हैं?

क्या आप DNS का उपयोग करके उसी कनेक्शन स्ट्रिंग का उपयोग कर कनेक्ट कर रहे हैं?

मैं एक ही कनेक्शन स्ट्रिंग का उपयोग नहीं कर रहा था। क्या आपको लगता है कि निजी EC2 IP पतों का उपयोग करने से यह हल हो जाएगा?

निश्चित नहीं है कि स्टोरेज किस तरह से अधिकतम हो सकता है, लेकिन नए इंस्टेंस को बूट करने के बाद भी कोई प्राथमिक सर्वर के साथ समस्या अभी भी बहुत सारे स्थान उपलब्ध नहीं है।

EC2 IP पते आपकी प्रतिकृति सेट को कैसे कॉन्फ़िगर किया गया है, इसके आधार पर मदद कर सकता है। क्या आप मुझे शेल से rs.status() का

यह रेस्टस्टेटस () है, जबकि कनेक्शन बढ़ रहे हैं।

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

प्रतिकृति सेट में सामान्य से बाहर कुछ भी नहीं है। क्या आपके पास कोई अन्य प्रासंगिक कोड नमूने हैं, उदाहरण के लिए, क्या आपके पास कोई ऐसा कोड है जो कनेक्शन घटनाओं को संशोधित करने के लिए प्रतिक्रिया दे रहा है?

विचार करने लायक एक और संभावित मुद्दा, क्या आप अप-टू-डेट नए अवशेष एजेंट का उपयोग कर रहे हैं? मैं नए अवशेष के बिना दौड़ने की कोशिश करूंगा और देखूंगा कि क्या यह अभी भी होता है, नए अवशेष बंदर-मोंगोडब ड्राइवर को पैच करते हैं ताकि कभी-कभी अप्रत्याशित व्यवहार हो सके।

हम मानगो कनेक्शन घटनाओं का उत्पादन कर रहे हैं:

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

यह कुछ लॉग की तरह दिखता है

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

मैं इस सप्ताह मोंडोडब ईवेंट में था, जहां मैं कुछ समय निर्धारित करने में सक्षम था और इस मुद्दे को मोंगोडीबी में एक वरिष्ठ अभियंता को दिखा सकता था, और वे निश्चित नहीं थे कि यह मुद्दा क्या था। उन्होंने प्रतिकृति स्ट्रिंग और अधिकतम पूल आकार को कनेक्शन स्ट्रिंग में जोड़ने का उल्लेख किया, जिसने दुर्भाग्य से इस मुद्दे को हल नहीं किया है।

हमने जीवित रखने को अक्षम करने का प्रयास किया, और इसे इंस्टेंस पर एक छोटे से मूल्य पर सेट किया, लेकिन यह भी ऐसा नहीं लगता था।

हम, newrelic संस्करण 1.24.0 , और mongo-express-patch संस्करण 0.21.1 । मैं newrelic के बिना चलाने की कोशिश करूँगा कि क्या यह हल करता है।

हम्म हाँ, ऐसा लगता है कि मानसून किसी कारण से फिर से जुड़ रहा है। क्या आप मुझे npm list | grep "mongoose" और 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]

क्या आप mongodb-core लिए उपयोग कर रहे हैं? इसके अलावा, क्या आप mongo-express साथ उत्पादों में सक्षम हैं?

वर्तमान में किसी भी चीज़ के लिए mongodb-core का उपयोग नहीं किया जा रहा है। क्या आपको लगता है कि मानसून निर्भरता के बीच संस्करण बेमेल मुद्दों का कारण हो सकता है?

हमारे पास उत्पादन में mongo-express सक्षम हैं।

मेरी जानकारी में नहीं। मैं सिर्फ यह देखने की कोशिश कर रहा हूं कि क्या मंगोडब के अन्य कनेक्शन हैं जो इस मुद्दे पर योगदान दे सकते हैं। मैंने थोड़ा सा googling किया है - क्या आप अपने कनेक्शन स्ट्रिंग के लिए समान DNS नामों का उपयोग कर रहे हैं जो rs.status() में दिखाई देते हैं? इसके अनुसार , यदि आप अपने प्रतिकृति सेट के बारे में सोचते हैं तो आप कनेक्शन स्ट्रिंग के लिए विभिन्न DNS का उपयोग करते हैं तो आप इसी तरह के मुद्दे देख सकते हैं।

जब rs.status() में "syncingTo" विशेषता के रूप में कनेक्शन स्ट्रिंग में समान DNS का उपयोग करते समय यह त्रुटि होगी। यह कनेक्शन स्ट्रिंग में आंतरिक ec2 IP का उपयोग करते समय भी होता है।

केवल एक चीज जो मैंने अभी तक कोशिश नहीं की है वह सिर्फ connectWithNoPrimary से true ।

मैं mongo-express साथ भी चलने की कोशिश करूँगा। यह मुद्दों का कारण हो सकता है ...

हम एक ही मुद्दे में चल रहे हैं। हमारे पास एक साइट है जो 500-700 आरपीएम + में चोटियों के साथ लगभग 100 आरपीएम के निरंतर लोड का अनुभव कर रही है। ऐसा लगता है कि हम इस प्रक्रिया को अपेक्षाकृत काफी अवधि के दौरान भी देखते हैं।

वातावरण:
हरोकू - 75 2x डायनोस - नोड.जेएस 5.1.1
डेटाबेस - MongoLabs समर्पित क्लस्टर M4 - संस्करण 3.0.7

कनेक्शन स्ट्रिंग:
mongodb: // _: * _ @ ds043294-a0.mongolab com: 43294 , ds043294-a1.mongolab com: 43294 / heroku_hf8q79dt; प्रतिकृति_सेट = rs-ds043294

एनपीएम:

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

कनेक्शन ।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
};

लॉगिंग:
हमने इसे मॉनिटर करने और इसे डीबग करने के लिए बहुत अधिक मात्रा में मॉनिटरिंग सक्षम की है, इसलिए मैंने हमारे रेगन स्टैक के निशान को भी इसमें शामिल कर लिया है, ताकि यह रगड़ने में मदद करे। _Note: _ यह ठीक वही लाइन नंबर है जो @ChrisZieba ऊपर के ट्रेस में दिखाया गया है।

संदेश: कोई प्राथमिक सर्वर उपलब्ध नहीं है
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
ऑब्जेक्ट.executeCommand in /app/node_modules/mongodb/lib/db.js:281
Db.Db.command in /app/node_modules/mongodb/lib/db.bsp255
Object.wipped 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.wipped in /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
ऑब्जेक्ट.wrappedQuery in /app/node_modules/newrelic/lib/instrumentation/mongodb.js:218
Object.wrapped [as findAndModify] (/app/node_modules/newrelic/lib/instrumentation/mongodb.js:188
मूल निवासी
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
अज्ञात। [गुमनाम] in /app/node_modules/kareem/index.js:156
अज्ञात। [अनाम] in /app/node_modules/kareem/index.js:18
Object.wipped in /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.doNTCallback0 in नोड। Js: 430
process.process._tickCallback in node.js: 359

निगरानी:

यह स्टैक ट्रेस वास्तव में केवल मुझे बताता है कि 1) आप नए अवशेष का उपयोग कर रहे हैं (जो बहुत ही संदिग्ध है, क्योंकि नए अवशेष में बहुत अधिक बंदर-पैंकिग करते हैं), और 2) मोंगोडब ड्राइवर को लगता है कि कोई प्राथमिक नहीं है उपलब्ध है, लेकिन मुझे यकीन नहीं है कि क्यों।

अपने कनेक्शन विकल्पों में replset: { loggerLevel: 'debug' } जोड़कर मेनगोड ड्राइवर डिबग मोड को सक्षम करने का प्रयास करें, जो है:

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

यह स्टडआउट करने के लिए बहुत सारे ड्राइवर डिबग डेटा को लॉग करेगा और हमें यह पता लगाने में मदद करेगा कि क्या गलत हो रहा है। क्या आप इस डेटा को तब पकड़ सकते हैं जब यह "कोई प्राथमिक सर्वर नहीं मिला" त्रुटि होती है?

धन्यवाद @ vkarpov15 ,

हमने इसे जोड़ दिया है और जैसे ही हमारे पास एक और ट्रिगर होगा वापस रिपोर्ट करेंगे।

चीयर्स,
रॉय

मुझे नहीं लगता कि newrelic यहाँ समस्या है। हमने इसके बिना चलने की कोशिश की और यह मुद्दा कायम है। loggerLevel: 'debug' से कुछ लॉग डेटा एकत्र करेंगे और यहां पोस्ट करेंगे।

धन्यवाद, मुझे बताएं कि क्या आप त्रुटि के बारे में अधिक जानकारी प्राप्त कर सकते हैं।

एक अन्य डेटा बिंदु: कनेक्शन की गिनती बढ़ने के साथ-साथ मानगो "पुन: कनेक्टेड" इवेंट को ट्रिगर करता है।

"कोई प्राथमिक सर्वर उपलब्ध नहीं" त्रुटियां आमतौर पर _after_ ट्रिगर होती हैं। कनेक्शन की गिनती पहले ही शुरू हो गई है।

हमने इस मुद्दे का अनुभव किया है। MongoLab के साथ हरकू पर होस्ट किया गया एक नोड ऐप है।
पिछले हफ्ते हमने डेटाबेस से अचानक संबंध खो दिया और Error no primary server available संदेश प्राप्त करते रहे। हमारे एप्लिकेशन को पुनः आरंभ करने से समस्या हल हो गई।
हेरोकू और मोनोग्लाब दोनों ने अपने लॉग में कुछ भी नहीं देखा।
मुझे आशा है कि किसी को इसके लिए एक समाधान मिल जाएगा।

टक्कर - हम इसे बड़े उत्पादन पर mongoose v4.1.5 node v4.2.3 mongoose v4.1.5 node v4.2.3 mongoose v4.1.5 पर देख रहे हैं। इस समस्या को इस तरह से मिटा देना मुश्किल है:

• लगातार त्रुटि नहीं करता है जो हमें कार्रवाई करने से रोकता है (फिर से शुरू करने की प्रक्रिया / नोड को बाहर निकालना)
• बेतरतीब ढंग से होता है और लगता है कि मानसून प्रतिकृति स्थिति के लिए असंबंधित है

@sansmischevia क्या आप मोंगोलैब + हेरोकू का उपयोग कर रहे हैं?

^ हम क्लाउड प्रबंधक के माध्यम से स्व-होस्ट किए गए मोंगोडब सर्वर के साथ AWS EC2 पर एक बड़े उत्पादन परिनियोजन में इस समस्या का सामना कर रहे हैं।

नमस्कार,

हम भी इसमें झंकार करना चाहेंगे।
हम node v0.12.8 , mongo v2.6.11 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]

यह अक्सर एक ऑपरेशन के दौरान प्रतिलिपि प्रस्तुत करने योग्य होता है जो डेटाबेस को बीज देता है, जिसमें बहुत सारे प्रश्न शामिल होते हैं। ऐसा होने के बाद हमारा आवेदन अप्रभावित हो रहा है। मोंगो लॉग में कोई त्रुटि नहीं है और इस दौरान हमारा तीन नोड प्रतिकृति सेट स्वस्थ है।

हम loggerLevel: 'debug' कोशिश करेंगे और वापस रिपोर्ट करेंगे।

@ vkarpov15 हम सीधे मंगोल + प्रतिकृति पर हैं

मैं मंगोलोल पर भी इस मुद्दे का अनुभव कर रहा हूं।

हम भी MongoLab और Modulus पर इस मुद्दे का सामना कर रहे हैं।

https://jira.mongodb.org/browse/NODE-622 पर एक नज़र डालें और अगर कोई भी लॉग का पूरा सेट प्रदान कर सकता है जो बेहद मददगार होगा तो हम इसे पुन: पेश कर सकते हैं।

यहाँ में झंकार, हम आम का उपयोग नहीं कर रहे हैं, लेकिन देशी MongoDB ग्राहक। यहाँ no primary server available त्रुटि हो रही है। हम एक निजी VPC के अंदर EC2 उदाहरण पर एक प्रतिकृति सेट चला रहे हैं, हमारा कनेक्शन स्ट्रिंग इंस्टेंस के निजी IP पते हैं। MongoDB v3.0.3 । मुझे लगता है कि यह तब होता है जब प्रश्नों का एक उच्च प्रवाह होता है, क्योंकि सामान्य रूप से त्रुटि उत्पन्न नहीं होती है।

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

ऐसा लगता है कि आगामी ड्राइवर रिलीज़ में इसके लिए एक फिक्स है: NODE-622

यह प्रस्तुत करने के लिए बहुत जल्दी नहीं है! :)

निश्चित संस्करण पहले ही NPM https://www.npmjs.com/package/mongodb पर प्रकाशित हो चुका है

मैं पुष्टि कर सकता हूं कि हमें अब त्रुटि नहीं मिली है। : टाडा:

पीआर के लिए mongodb 2.1.2 यहाँ: https://github.com/Automattic/mongoose/pull/3712

अभी भी इस त्रुटि को 4.3.4 लिए मानगो को अपग्रेड करने के बाद देख रहा है, जो mongo core 2.1.2 का उपयोग करता है। https://jira.mongodb.org/browse/NODE-622 फिर से खोल दिया गया है

+1 मैंने अभी हमारे प्रोडक्शन सर्वर पर भी यह देखा। मैं क्यों का कोई भी पैटर्न नहीं देखता। नोड के साथ 4.2.4 का उपयोग करते हुए मोंगोज़ 4.3.4 और मोंगोडब 3.0.8 के साथ। मैं अपने क्लस्टर पर नज़र रखने के लिए मोंगोडब की एमएमएस सेवाओं का उपयोग करता हूं और मुझे उस समय कोई अलर्ट नहीं देखा जाता है जब मुझे मिलता है: MongoError: कोई प्राथमिक सर्वर उपलब्ध नहीं है

@ amit777 क्या आप अपने कनेक्शन स्ट्रिंग और विकल्प पोस्ट कर सकते हैं? इसके अलावा, क्या यह असामान्य रूप से भारी कार्यभार के दौरान हुआ था, उदाहरण के लिए, डेटाबेस को बहुत कुछ लिखता है?

क्रिस, यह निश्चित रूप से लेखन कार्यों के दौरान होता है, हालांकि मैं यह नहीं कहूंगा कि हमारा भार विशेष रूप से भारी है। हमारे पास एक क्लस्टर में कुछ नोड्स हैं जहां प्रत्येक नोड स्वतंत्र रूप से मोंगो को लिखेगा।

यहां बताया गया है कि हम कैसे कनेक्ट होते हैं:

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

मैंने यह भी देखा कि मेरे मोंगॉड लॉग वास्तव में कनेक्शन और डिस्कनेक्ट के संदेशों के साथ तेजी से भर रहे हैं:

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)

यहाँ कुछ अतिरिक्त जानकारी है जो डीबग करने में मदद कर सकती है .. मुझे लगता है कि कनेक्शन पूलिंग से संबंधित कुछ बग हो सकते हैं। अपनी नोड प्रक्रियाओं को पुनः आरंभ करने के बाद, मुझे mongod.log में नए कनेक्शन का एक गुच्छा दिखाई देता है। फिर लगभग एक मिनट के बाद, मुझे mongod.log में अंत-कनेक्शन संदेशों का एक गुच्छा दिखाई देता है।

ऐसा लगता है कि कनेक्ट / डिस्कनेक्ट समय के साथ तेज और तेज हो जाता है, (हालांकि मैं अभी भी पुष्टि करने की कोशिश कर रहा हूं)।

इस के कारण विशिष्ट स्थिति कुछ इस तरह है।

रेप्लिकासेट में मेजबान होते हैं जिन्हें चालक द्वारा हल नहीं किया जा सकता है। जब ड्राइवर कनेक्ट होता है तो यह सभी कनेक्शनों के लिए विहित स्रोत के रूप में प्रतिकृति का उपयोग करता है। पुनर्विचार उन पतों का उपयोग करेंगे। वे चालक द्वारा पुन: प्रयोज्य होना चाहिए।

आपको आईपी पते का उपयोग करने से भी बचना चाहिए क्योंकि वे इस तरह की बहुत सारी समस्याओं का स्रोत हैं, पूरी तरह से योग्य होस्ट नाम (कोई छोटा नाम नहीं) का उपयोग करें

@christkv यदि OS मेजबानों को हल करने में सक्षम है (यानी, पिंग करके), क्या इसका मतलब यह है कि ड्राइवर को भी हल करने में सक्षम होना चाहिए?

यह हां चाहिए, लेकिन आप हमेशा जांचने के लिए टेलनेट होस्टनाम पोर्ट का उपयोग कर सकते हैं।

हाँ, मैं होस्ट और पोर्ट को टेलनेट करने में सक्षम हूं .. (सभी डेटाबेस होस्ट की एप्लिकेशन सर्वर पर / आदि / होस्ट प्रविष्टियाँ हैं)।

हमारे ऐप के शुरू होने और कनेक्शन पूल बनने के बाद, क्या कभी नेटवर्क समस्या नहीं होने पर डिस्कनेक्ट और फिर से कनेक्ट होना चाहिए? या क्या एक सामान्य कनेक्शन टाइमआउट है और फिर से कनेक्ट करना है जो मुझे मोंगोडब लॉग में दिखाई देगा?

समस्या यह है कि लॉग के पूर्ण सेट के बिना समस्या को समझने और पुन: पेश करने का प्रयास करने के लिए इन चीजों को सहसंबंधित करना असंभव है (मेरी अंतिम टिप्पणी https://jira.mongodb.org/browse/NODE-622 पर देखें)

यदि आपके पास सॉकेट टाइमआउट विंडो में पर्याप्त ऑप्स नहीं हैं, तो सभी कनेक्शनों का उपयोग करने के लिए पूल बंद हो जाएगा और फिर से कनेक्ट होगा। इसलिए यदि आपके पास 30 सेकंड की विंडो और 10 कनेक्शन हैं, लेकिन केवल 5 ऑप्स से यह हर 30 सेकंड में एक पुन: कनेक्ट होने वाली घटना का कारण होगा।

क्या यह पूल के सभी कनेक्शनों को बंद कर देगा? या केवल उन कनेक्शनों का उपयोग नहीं किया गया है? यदि हम 30 सेकंड के भीतर सभी कनेक्शनों का उपयोग करते हैं, तो क्या अगली 30 सेकंड विंडो में एक ही चेक किया जाएगा?

मेरी कोशिश होगी कि आप जो भी मोनगोडब टिकट में रिक्वेस्ट लाएं .. उसकी सहायता के लिए धन्यवाद।

सब। यदि आप सॉकेट टाइमआउट विंडो नोड में पूल में सभी कनेक्शनों का उपयोग करने का प्रबंधन करते हैं। तो सॉकेट्स को टाइमआउट नहीं किया जाएगा और वे पूल को फिर से जोड़ने के लिए मजबूर नहीं करेंगे।

कनेक्शन के एक बहुत सारे केवल तभी उपयोगी होते हैं जब आपके पास समानांतर में बहुत धीमी गति से चलने वाले संचालन होते हैं, अन्यथा आप एक छोटे पूल के साथ बेहतर होते हैं क्योंकि MongoDB प्रति सॉकेट थ्रेड का उपयोग करता है जिसका अर्थ है कि हजारों कनेक्शनों को सर्वर और इच्छाशक्ति पर अधिक आवंटित मेमोरी की आवश्यकता होती है अधिक CPU संदर्भ स्विच का कारण।

मेनगोडब-कोर का अगला प्रमुख संशोधन धीमी गति से ट्रेन की समस्याओं को कम करने के लिए पूल को बदलने के साथ-साथ कुछ अन्य मूलभूत परिवर्तन भी करेगा। हालाँकि, कई महीने बाहर है और शायद MongoDB 3.4 काम के साथ एक साथ बंधे होंगे।

क्या आप यह संभव / संभावना देखते हैं कि डिस्कनेक्ट / रीकनेक्ट की भारी मात्रा में कोई प्राथमिक सर्वर उपलब्ध समस्या का कारण बन सकता है?

हां, क्योंकि एक संक्षिप्त अवधि होगी जहां सेट में कोई सर्वर नहीं हो सकता है

@christkv मैं तब तक इंतजार कर रहा हूं जब तक कि आप फिर से उस दूसरे टिकट में कुछ लॉग भेजने के लिए नहीं होते। हमारा क्लस्टर वास्तव में पिछले कुछ हफ्तों से स्थिर है और हमने इस त्रुटि को नहीं देखा है।

@ChrisZieba अजीब है कि हमेशा ऐसा कैसे होता है lol: +1: मैं अभी के लिए जीरा में टिकट खुला छोड़ देती हूं और देखती हूं कि हम क्या समझ सकते हैं।

@christkv हाय क्रिश्चियन, मैं उत्सुक हूँ अगर आपके पास कम ट्रैफ़िक के मामले में वर्कअराउंड पर कोई संकेत है। मैं पूल के आकार को कम करने के साथ-साथ टाइमआउट को बढ़ाने के बारे में सोच रहा था।

अगर यह किसी और की मदद करता है, तो मैंने सॉकेट टाइमआउट को बढ़ा दिया और साथ ही 200 को भी बढ़ा दिया है और पूल 3 को भी कम कर दिया है। मुझे लगता है कि यह बहुत कम डिस्कनेक्ट / पुन: कनेक्ट होता है .. हालांकि यह अभी भी कभी-कभी होता है।

यदि यह किसी की मदद करता है, तो हमने सॉकेट टाइमआउट और कनेक्शनटाइमआउट और कीपएलाइव सहित लगभग सभी मानसून सेटिंग्स को हटा दिया और कनेक्शन स्थिर होने लगे। हमारा पूलसाइज़ 200 है।
मुझे यकीन नहीं है कि यह अनुशंसित दृष्टिकोण है लेकिन अब यह काम करता है। हम अभी भी यह सुनिश्चित करने के लिए निगरानी कर रहे हैं कि यह धारण किया जाए।

मोंगोस v4.4.2
नोड 4
मानगो 3.0

क्या आपके पास धीमे संचालन की एक बड़ी राशि है? अगर आपको नहीं लगता कि आपको 20 कुर्सियां ​​बनाम 500 के पूल के बीच कोई अंतर दिखाई देगा।

क्षमा करें ... यह 200 है। टिप्पणी फिक्स्ड।

और हाँ, तुम सही हो। हम बहुत अंतर महसूस नहीं करते हैं, लेकिन हमारे पास पूल का आकार छोटे से बड़ा है।

जब कनेक्शन खुला रहता है और बंद नहीं होता है तो असली समस्या। यह तब तक हुआ करता था जब तक कि हम सभी मैंगोज़ टाइमआउट और कीप्लीव सेटिंग्स को हटा नहीं देते। मुझे आश्चर्य है कि ये क्यों mongoose / mongo- चालक द्वारा नियंत्रित किए जाते हैं और OS को ऐसा नहीं करने देते हैं?

अच्छी तरह से 2.1.7 और उच्चतर में एक पुन: डिज़ाइन किया गया पूल है जो इससे बचते हैं। यदि आप सॉकेट टाइमआउट 0 सेट करते हैं, तो आप इसे ओएस को सौंपते हैं, लेकिन यह लटकते कनेक्शन के 10 मिनट तक हो सकता है।

अछा ठीक है। दिलचस्प है। तो अब जब कि मैंने KeepAlive और सॉकेट टाइमआउट सेटिंग्स को हटा दिया तो डिफ़ॉल्ट सेटिंग्स क्या हैं?

यह निर्भर करता है, निश्चित नहीं है कि मानसून डिफ़ॉल्ट के रूप में कोई विशिष्ट सेटिंग्स सेट करता है। यदि आप ड्राइवर में MongoClient.connect विधि का उपयोग करते हैं तो कनेक्ट और सॉकेट टाइमआउट दोनों के लिए यह 30 सेकंड है।

हम connect उपयोग करते हैं लेकिन जब हम 30 सेकंड मैन्युअल रूप से सेट करते हैं तो ढेर शुरू हो जाता है।

अच्छी तरह से 500 कनेक्शन के साथ आपको पूल को खुला रखने के लिए सॉकेट टाइमआउट अवधि के अंदर कम से कम 500 ऑप्स की आवश्यकता होती है, अन्यथा यह बंद हो जाएगा और पुन: कनेक्ट करने के लिए मजबूर करेगा। 2.1.7 में यह बदलाव हालांकि पूल बढ़ने वाला / सिकुड़ता हुआ मॉडल है।

मैं mongodb 3.2.6 और mongoose 4.3.4 के साथ एक ही मुद्दा रहा हूँ। इस पर कोई मदद?

@ 15astro socketTimeout और connectionTimeout की सेटिंग्स को निकालने का प्रयास करें और देखें कि क्या यह मदद करता है।

@refaelos Ok..willl कोशिश करते हैं कि .. मैंने KeepAlive = 6000 के साथ कोशिश की, लेकिन इससे कोई मदद नहीं मिली। बस यह जानना चाहता था कि socketTimeout और connectionTimeout निकालने से कैसे मदद मिलेगी?

हाँ, हमने इसे विभिन्न मूल्यों के साथ आज़माया और केवल जब हमने इन सेटिंग्स को पूरी तरह से हटा दिया तब चीजें अच्छी तरह से काम करने लगीं।

@refaelos : मुझे इन सेटिंग्स को हटाने के साथ कोई भाग्य नहीं मिला। कोई और बात याद आ रही है?

@ 15astro नहीं यार। माफ़ करना। आज हमारी सेटिंग कैसी दिखती है:

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

  }

मेरे मामले में यह / आदि / मेजबानों में बाध्यकारी नाम के लिए आईपी की कमी से संबंधित था।

यदि आपने आईपी के बजाय नामों के साथ प्रतिकृति सेट किया है और आपके पास कुछ ऐसा है / 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

फिर आपको इसे अपने सभी ऐप सर्वर के / etc / मेजबान में डालने की भी आवश्यकता है।

मुझे लगा कि यूआरआई में मैंने जो कुछ भी डाला है, उसके अनुसार नोड-मोंगो कनेक्ट करता है, लेकिन यह मामला नहीं है।

ऐसा लगता है कि नोड-मोंगो आईपी या मोंगो यूआरआई से नाम से जोड़ता है, फिर पहले मोंगोबीडी नोड से अन्य प्रतिकृति सदस्यों के होस्टनाम प्राप्त करता है जिन्होंने अनुरोध किया था। यह उदाहरण के लिए mongodb-2gb-fra1-03 और इसे हल करने के लिए OS पर जाता है। अगर OS ​​को mongodb-2gb-fra1-03 बारे में कुछ भी पता नहीं है, तो यह "त्रुटि कोई प्राथमिक सर्वर उपलब्ध नहीं है" फेंकता है।

उम्मीद है की वो मदद करदे।

@adriank हाँ, यह सही है, यह उन लोगों के कनेक्शन है, जो इसे प्रतिकृत विन्यास से वापस प्राप्त करते हैं। कारण यह है कि यह एक प्रतिकृति के बारे में सत्य का विहित स्रोत है। यही कारण है कि रेप्लिकासेट कॉन्फ़िगरेशन के सभी पते ड्राइवर द्वारा ड्राइवर के लिए सही रूप से विफल होना चाहिए और इसके लिए सर्वर को जोड़े जाने और सेट से हटाए जाने का पता लगाने में सक्षम होना चाहिए। पिछले ड्राइवरों ने SDAM युक्ति को लागू नहीं किया था और जहाँ अधिक ढीला था। हालांकि यह उत्पादन वातावरण में समस्याओं का कारण होगा।

@christkv हालांकि यह हमारे MongoSpector जैसे उपकरणों के लिए एक बुरा सपना है। इसकी वजह से हमें एक मेजबान से एक से अधिक प्रतिकृति से सुरक्षित रूप से जुड़ने में समस्या है। DigitalOcean ऑटो ड्रॉप्स को नाम देता है जो लगभग किसी को भी नहीं बदलता है और इसका असर यह है कि कई क्लाइंट्स के पास mongodb-2gb-fra1-01 PR

हम यहां एक सर्वर टिकट ट्रैक कर रहे हैं https://jira.mongodb.org/browse/SERVER-1889। मैं इस तरह से संभव होने के लिए कुछ पसंद करूंगा।

हमें DigitalOcean के साथ एक टिकट भी दर्ज करना चाहिए जो वे गलती कर रहे हैं और यह बता रहे हैं कि यह उनके उपयोगकर्ताओं को कैसे प्रभावित कर रहा है।

वैसे आप प्रतिकृत सदस्यों को उनके नए नामों के साथ हटा सकते हैं और जोड़ सकते हैं

एक समसामयिक समस्या होने के बाद, हमारे जुड़े रहने के लगभग 12-24 घंटों के बाद हमें एक त्रुटि मिलती है "कोई प्राथमिक सर्वर उपलब्ध नहीं"

पुनरारंभ करना आमतौर पर समस्या को हल करता है।

कनेक्शन:
{ "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" }