Mongoose: لا يوجد خادم أساسي متاح

لا شيء يقفز للخارج في الوقت الحالي. هل أنت متأكد من عدم تعطل أي من خوادم mongodb؟ أيضا ، هل يمكنك الحفاظ على اتصال ثابت باستخدام قذيفة؟

يؤدي تشغيل الأمر db.runCommand( { replSetGetStatus : 1 } ) أثناء حدوث الخطأ إلى إنتاج "health" : 1, على العقد الثلاثة. هناك أيضًا مجموعة أساسية "stateStr" : "PRIMARY", على إحدى العقد.

هل تقوم بالاتصال باستخدام نفس سلسلة الاتصال ، باستخدام DNS؟ يبدو أيضًا أن مساحة التخزين الخاصة بك مبطنة بشكل مسطح بعد المشكلة ، فهل يمكنك التحقق مرة أخرى ومعرفة ما إذا كانت مساحة محرك الأقراص الثابتة لديك قد نفدت على أحد أجهزتك؟

هل تقوم بالاتصال باستخدام نفس سلسلة الاتصال ، باستخدام DNS؟

لم أكن أستخدم نفس سلسلة الاتصال. هل تعتقد أن استخدام عناوين EC2 IP الخاصة سيحل هذا؟

لست متأكدًا من سبب زيادة السعة التخزينية إلى الحد الأقصى من هذا القبيل ، ولكن حتى بعد تشغيل مثيلات جديدة ، لا تزال المشكلة مع عدم وجود خوادم أساسية مع توفر مساحة كبيرة.

قد تساعد عناوين EC2 IP ، اعتمادًا على كيفية تكوين مجموعة النسخ المتماثلة. هل يمكنك أن تريني ناتج rs.status() من الصدفة ؟

هذه هي حالة 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
}

لا شيء خارج عن المألوف في مجموعة النسخ المتماثلة. هل لديك أي عينات أخرى من التعليمات البرمجية ذات الصلة ، على سبيل المثال ، هل لديك أي كود يتفاعل مع أحداث الاتصال النمس؟

هناك مشكلة محتملة أخرى تستحق الدراسة ، هل تستخدم وكيل بقايا جديد محدث؟ سأحاول الركض بدون بقايا جديدة ومعرفة ما إذا كان هذا لا يزال يحدث أم لا ، يقوم القرد القديم الجديد بتصحيح برنامج التشغيل mongodb بحيث يمكن أن يؤدي في بعض الأحيان إلى سلوك غير متوقع

لقد قمنا بإخراج أحداث اتصال النمس:

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

لقد كنت في حدث mongodb days هذا الأسبوع ، حيث تمكنت من تحديد بعض الوقت وعرض هذه المشكلة على أحد كبار المهندسين في MongoDB ، ولم يكونوا متأكدين من سبب المشكلة. لقد ذكروا إضافة مجموعة النسخ المتماثل والحد الأقصى لحجم التجمع إلى سلسلة الاتصال ، والتي لم تحل هذه المشكلة ، للأسف.

لقد حاولنا أيضًا تعطيل ميزة "البقاء على قيد الحياة" ، وتعيينها على قيمة أصغر في الحالات ، ولكن يبدو أن ذلك أيضًا لم يحل المشكلة.

نحن ؛ نستخدم الإصدار 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 ممكّن في الإنتاج.

ليس هذا ما أعلمه عن. أحاول فقط معرفة ما إذا كانت هناك اتصالات أخرى بـ mongodb قد تساهم في هذه المشكلة. لقد قمت ببعض البحث على Google - هل تستخدم نفس أسماء DNS لسلسلة الاتصال الخاصة بك مثل تلك التي تظهر في rs.status() ؟ وفقًا لهذا ، قد ترى مشكلات مماثلة إذا كنت تستخدم DNS مختلفًا لسلسلة الاتصال عما تعتقده مجموعة النسخ المتماثلة.

سيحدث هذا الخطأ عند استخدام نفس DNS في سلسلة الاتصال كسمة "syncingTo" في rs.status() . كما يحدث أيضًا عند استخدام عنوان IP الداخلي ec2 في سلسلة الاتصال.

الشيء الوحيد الذي لم أجربه حتى الآن هو تعيين connectWithNoPrimary إلى true .

سأحاول أيضًا الركض بخصم mongo-express أيضًا. قد يتسبب ذلك في حدوث مشكلات ...

نحن نواجه نفس المشكلة. لدينا موقع يعاني من حمل مستمر يبلغ حوالي 100 دورة في الدقيقة مع قمم في 500-700 دورة في الدقيقة +. يبدو أننا نرى هذا طوال العملية حتى خلال فترات هادئة نسبيًا.

بيئة:
Heroku - 75 2x dynos - Node.JS 5.1.1
قاعدة البيانات - MongoLabs Dedicated Cluster M4 - الإصدار 3.0.7

سلسلة الاتصال:
mongodb: // _: * _ @ ds043294-a0.mongolab. كوم: 43294 ، ds043294-a1.mongolab. كوم: 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
};

تسجيل:
لقد قمنا بتمكين قدر لا بأس به من المراقبة لمحاولة تصحيح هذا الخطأ ، لذا فقد قمت بتضمين آثار مكدس Raygun حتى وإن كان هذا سيساعد في تصحيح الأخطاء. _ملاحظة: _ هذا هو نفس رقم السطر الذي أظهرهChrisZieba في التتبع أعلاه.

الرسالة: لا يوجد خادم أساسي متاح
Object.pickServer في /app/node_modules/mongodb-core/lib/topologies/replset.js:860
ReplSet.ReplSet.command في /app/node_modules/mongodb-core/lib/topologies/replset.js:437
ReplSet.ReplSet.command في /app/node_modules/mongodb/lib/replset.js:392
Object.executeCommand in /app/node_modules/mongodb/lib/db.js:281
Db.Db.command في /app/node_modules/mongodb/lib/db.js:305
Object.wrapped في /app/node_modules/newrelic/lib/instrumentation/mongodb.js:185
Object.findAndModify في /app/node_modules/mongodb/lib/collection.js:2327
Collection.Collection.findAndModify في /app/node_modules/mongodb/lib/collection.js:2265
Object.wrapped في /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.wrapped الاستعلام في /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. (مجهول في الوظيفة) [as findAndModify] (/app/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:136
NodeCollection.NodeCollection.findAndModify في /app/node_modules/mquery/lib/collection/node.js:79
Query.Query._findAndModify في /app/node_modules/mongoose/lib/query.js:1833
Query.Query._findOneAndUpdate في /app/node_modules/mongoose/lib/query.js:1621
غير معروف. [مجهول] في /app/node_modules/kareem/index.js:156
غير معروف. [مجهول] في /app/node_modules/kareem/index.js:18
Object.wrapped في /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
Object.doNTCallback0 في node.js: 430
process.process._tickCallback في node.js: 359

المراقبة:

يخبرني تتبع المكدس هذا فقط أن 1) أنك تستخدم بقايا جديدة (وهو أمر مشكوك فيه للغاية ، حيث أن البقايا الجديدة تقوم بالكثير من ترقيع القرود لبرنامج mongodb) ، و 2) يعتقد السائق mongodb أنه لا يوجد أساسي متاح ، لكني لست متأكدًا من السبب.

حاول تمكين وضع تصحيح أخطاء برنامج تشغيل mongodb عن طريق إضافة 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
        }
    }
};

سيؤدي هذا إلى تسجيل الكثير من بيانات تصحيح أخطاء برنامج التشغيل إلى stdout ومساعدتنا في اكتشاف الخطأ. هل يمكنك التقاط هذه البيانات عند حدوث الخطأ "لم يتم العثور على خادم أساسي"؟

شكرا @ vkarpov15 ،

لقد أضفنا ذلك وسنقدم تقريرًا بمجرد أن يتم تشغيل واحد آخر.

في صحتك،
روي

لا أعتقد أن newrelic هي المشكلة هنا. لقد حاولنا الركض بدونه واستمرت هذه المشكلة. سيتم جمع بعض بيانات السجل من loggerLevel: 'debug' ونشرها هنا.

شكرًا ، يُرجى إعلامي إذا تمكنت من التعرف على مزيد من التفاصيل حول الخطأ.

نقطة بيانات أخرى: يقوم Mongoose بتشغيل حدث "إعادة الاتصال" مرارًا وتكرارًا مع زيادة عدد الاتصال.

عادةً ما تؤدي أخطاء "عدم توفر خادم أساسي" إلى _after_ بدأ عدد الاتصال في الارتفاع بالفعل.

لقد اختبرنا هذه المشكلة أيضًا. مع وجود تطبيق Node مستضاف على Heroku مع MongoLab.
لقد فقدنا الاتصال بقاعدة البيانات فجأة الأسبوع الماضي واستمرنا في تلقي الرسالة Error no primary server available . أدت إعادة تشغيل تطبيقنا إلى حل المشكلة.
لم ير كل من Heroku و MonogLab شيئًا في سجلاتهم.
آمل أن يجد أحدهم حلاً لهذا.

نتوء - نشاهد هذا على node v4.2.3 mongoose v4.1.5 في عملية نشر إنتاج كبيرة. من الصعب الخوض في هذه القضية لأنها:

• لا يخطئ باستمرار مما يمنعنا من اتخاذ إجراء (عملية إعادة التشغيل / إخراج العقدة)
• يحدث بشكل عشوائي ويبدو غير مرتبط بحالة إعادة تعيين mongo

sansmischevia هل تستخدم mongolab + heroku أيضًا؟

^ نحن نواجه هذه المشكلة في عملية نشر كبيرة للإنتاج على AWS EC2 مع خوادم mongodb ذاتية الاستضافة عبر Cloud Manager.

مرحبا،

نود أيضًا أن نتناغم.
نقوم بتشغيل 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]

غالبًا ما يكون قابلاً للتكرار أثناء عملية تقوم ببذر قاعدة البيانات ، والتي تتضمن الكثير من الاستفسارات. يبدو أن طلبنا لم يتأثر بعد حدوث ذلك. لا توجد أخطاء في سجل mongo ومجموعة النسخ المتماثلة للعقد الثلاثة الخاصة بنا سليمة خلال هذا الوقت.

سنحاول loggerLevel: 'debug' ونعيد الإبلاغ.

@ vkarpov15 نحن على مجموعات mongolab + ec2 مباشرة

أنا أواجه هذه المشكلة على mongolab أيضًا.

نحن أيضًا نواجه هذه المشكلة في MongoLab و Modulus.

ألق نظرة على https://jira.mongodb.org/browse/NODE-622 وإذا كان بإمكان أي شخص توفير مجموعة كاملة من السجلات التي ستكون مفيدة للغاية حتى نتمكن من إعادة إنتاجها.

سنعمل هنا ، نحن لا نستخدم النمس ، ولكن عميل MongoDB الأصلي. الحصول على نفس الخطأ no primary server available هنا. نقوم بتشغيل نسخة متماثلة على مثيل EC2 داخل VPC خاص ، وسلسلة الاتصال الخاصة بنا هي عناوين 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.

يمكنني أن أؤكد أننا لم نعد نتلقى الخطأ. : تادا:

PR لـ mongodb 2.1.2 هنا: https://github.com/Automattic/mongoose/pull/3712

لا تزال ترى هذا الخطأ بعد ترقية mongoose إلى 4.3.4 ، والذي يستخدم mongo core 2.1.2 . تمت إعادة فتح https://jira.mongodb.org/browse/NODE-622

+1 لقد لاحظت حدوث ذلك على خادم الإنتاج أيضًا. لا أرى أي نمط للسبب. باستخدام العقدة 4.2.4 مع النمس 4.3.4 و mongodb 3.0.8. أستخدم خدمات mongodb MMS لمراقبة الكتلة الخاصة بي ولم أر أي تنبيهات خلال الوقت الذي أحصل فيه على: MongoError: لا يتوفر خادم أساسي

@ amit777 هل يمكنك نشر سلسلة الاتصال والخيارات؟ أيضًا ، هل حدث هذا أثناء عبء العمل الثقيل بشكل غير عادي ، على سبيل المثال ، الكثير من عمليات الكتابة إلى قاعدة البيانات؟

كريس ، هذا يحدث بالتأكيد أثناء عمليات الكتابة ، على الرغم من أنني لن أقول أن حملنا ثقيل بشكل خاص. لدينا عقدتان في مجموعة حيث ستكتب كل عقدة بشكل مستقل إلى mongo.

إليك كيف نتواصل:

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.

يبدو أن الاتصال / قطع الاتصال يتضخم بشكل أسرع وأسرع بمرور الوقت ، (على الرغم من أنني ما زلت أحاول تأكيد ذلك).

الوضع النموذجي الذي يسبب هذا هو شيء من هذا القبيل.

تحتوي مجموعة النسخ المتماثلة على مضيفات لا يمكن حلها بواسطة السائق. عندما يتصل المشغل ، فإنه يستخدم المجموعة المتماثلة كمصدر أساسي لجميع الاتصالات. ستستخدم عمليات إعادة الاتصال هذه العناوين. يجب أن تكون قابلة للحل من قبل السائق.

يجب أيضًا تجنب استخدام عناوين IP فهي مصدر للعديد من المشكلات مثل هذا ، استخدم أسماء مضيف مؤهلة بالكامل (بدون أسماء قصيرة)

christkv إذا كان نظام التشغيل قادرًا على حل المضيفين (على ) ، هل هذا يعني أن السائق يجب أن يكون قادرًا على حل المشكلة أيضًا؟

نعم ، لكن يمكنك دائمًا استخدام منفذ اسم مضيف telnet للتحقق.

نعم ، أنا قادر على telnet إلى المضيف والمنفذ .. (كل مضيف قاعدة البيانات لديه / etc / hosts إدخالات على خوادم التطبيق).

بعد بدء تشغيل تطبيقنا وإنشاء تجمع الاتصال ، هل يجب أن يكون هناك قطع اتصال وإعادة الاتصال إذا لم تكن هناك مشكلات في الشبكة؟ أو هل هناك مهلة اتصال عادية وإعادة الاتصال التي سأراها في سجلات mongodb؟

المشكلة هي أنه من المستحيل ربط هذه الأشياء بمحاولة فهم المشكلة وإعادة إنتاجها بدون مجموعة كاملة من السجلات (انظر تعليقي الأخير على https://jira.mongodb.org/browse/NODE-622)

إذا لم يكن لديك عدد كافٍ من العمليات في نافذة مهلة المقبس لممارسة جميع الاتصالات ، فسيتم إغلاق التجمع وإعادة الاتصال. لذلك إذا كانت لديك نافذة مدتها 30 ثانية و 10 اتصالات ولكن 5 عمليات فقط ، فسيؤدي ذلك إلى إعادة الاتصال كل 30 ثانية.

هل سيغلق جميع الاتصالات بالمسبح؟ أم فقط الاتصالات التي لم تمارس؟ إذا قمنا بتدريب جميع الاتصالات في غضون 30 ثانية ، فهل سيتم إجراء نفس الفحص في النافذة الـ 30 التالية؟

سأحاول الحصول على السجلات التي تطلبها في تذكرة mongodb .. شكرا للمساعدة.

الكل. إذا تمكنت من ممارسة جميع الاتصالات في التجمع في عقدة نافذة socketTimeout.js ، فلن تنتهي مهلة المقابس ولن تغلق بفرض إعادة اتصال التجمع.

الكثير من الاتصالات مفيدة فقط إذا كان لديك الكثير من عمليات التشغيل البطيئة بالتوازي ، وإلا فأنت أكثر ملاءمة مع مجموعة أصغر حيث يستخدم MongoDB مؤشر ترابط لكل مقبس مما يعني أن آلاف الاتصالات تتطلب ذاكرة مخصصة أكثر على الخادم وسوف تسبب المزيد من رموز تبديل سياق وحدة المعالجة المركزية.

ستعمل المراجعة الرئيسية التالية على mongodb-core على تغيير التجمع بحيث ينمو بالإضافة إلى بعض التغييرات الأساسية الأخرى لتقليل مشاكل القطار البطيء. ومع ذلك ، فإن هذا يستغرق عدة أشهر ومن المحتمل أن يتم ربطه مع عمل MongoDB 3.4.

هل ترى أنه من الممكن / المحتمل أن الكميات الهائلة من قطع الاتصال / إعادة الاتصال يمكن أن تتسبب بشكل متقطع في مشكلة عدم توفر الخادم الأساسي؟

نعم ، حيث ستكون هناك فترة وجيزة حيث قد لا يكون هناك أي خوادم في المجموعة

christkv لقد كنت أنتظر حتى يحدث هذا مرة أخرى لأرسل لك بعض السجلات في تلك التذكرة الأخرى. لقد كانت مجموعتنا مستقرة بالفعل خلال الأسابيع القليلة الماضية ولم نر هذا الخطأ.

ChrisZieba مضحك كيف يبدو أن هذا يحدث دائمًا لول: +1: سأترك التذكرة مفتوحة في الجيرة الآن وأرى ما يمكننا اكتشافه.

christkv مرحبًا كريستيان ، أشعر بالفضول إذا كان لديك أي مؤشرات حول الحلول البديلة في حالة انخفاض حركة المرور. كنت أفكر فقط في تقليل حجم البركة بالإضافة إلى زيادة المهلات.

إذا كان ذلك يساعد أي شخص آخر ، فقد قمت بإزالة مهلة المقبس وكذلك زيادة KeepAlive إلى 200 وقمت أيضًا بتقليل حجم التجمعات إلى 3 .. يبدو أن لدي الكثير من قطع الاتصال / إعادة الاتصال .. ومع ذلك لا يزال يحدث أحيانًا.

إذا كان ذلك مفيدًا لأي شخص ، فقد أزلنا جميع إعدادات النمس تقريبًا ، بما في ذلك socketTimeout و connectionTimeout و keepAlive وبدأت الاتصالات في الاستقرار. حجم حمام السباحة لدينا 200.
لست متأكدًا من أنه النهج الموصى به ولكنه يعمل الآن. ما زلنا نراقبها للتأكد من صحتها.

النمس v4.4.2
العقدة 4
مونجو 3.0

هل لديك قدر هائل من العمليات البطيئة؟ إذا كنت لا أعتقد أنك ستلاحظ أي فرق بين مجموعة من 20 مقبس مقابل 500.

آسف ... إنه 200. إصلاح التعليق.

ونعم ، أنت على حق. لا نشعر بالفرق الكبير ولكن لدينا حجم حمام السباحة أكبر من الأصغر.

المشكلة الحقيقية في حالة استمرار فتح الاتصالات وعدم إغلاقها. كان هذا يحدث حتى قمنا بإزالة جميع مهلة النمس وإعدادات الاحتفاظ بالحيوية. أتساءل لماذا يتم التعامل مع هذه من قبل mongoose / mongo-driver وعدم ترك نظام التشغيل يقوم بذلك؟

حسنًا ، 2.1.7 وأعلى يحتوي على مجموعة معاد تصميمها تتجنب ذلك. إذا قمت بتعيين socketTimeout 0 ، فأنت تقوم بتفويضه إلى نظام التشغيل ولكن قد يستغرق ذلك 10 دقائق من الاتصالات المعلقة.

موافق. مثير للإعجاب. والآن بعد أن قمت بإزالة إعدادات keepAlive و socketTimeout ، ما هي الإعدادات الافتراضية؟

هذا يعتمد ، لست متأكدًا مما إذا كان النمس قد قام بتعيين أي إعدادات محددة كإعدادات افتراضية. إذا كنت تستخدم طريقة MongoClient.connect في برنامج التشغيل ، فستكون 30 ثانية لكل من مهلات الاتصال والمقبس.

نحن نستخدم connect ولكن عند تعيين 30 ثانية يدويًا تبدأ الاتصالات في التراكم.

حسنًا ، مع 500 اتصال ، فأنت بحاجة إلى 500 عملية على الأقل داخل فترة المهلة لإبقاء المسبح مفتوحًا ، وإلا فسيتم إغلاقه وفرض إعادة الاتصال. يتغير هذا في 2.1.7 مع ذلك لأن المجمع هو نموذج متنامي / متقلص.

أواجه نفس المشكلة مع mongodb 3.2.6 و mongoose 4.3.4. أي مساعدة في هذا؟

@ 15astro حاول إزالة إعدادات socketTimeout و connectionTimeout ومعرفة ما إذا كان ذلك مفيدًا.

refaelos حسنًا .. سأجرب ذلك .. حاولت استخدام 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
      }
    }

  }

في حالتي ، كان الأمر مرتبطًا بنقص IP لربط الأسماء في / etc / hosts.

إذا قمت بإعداد مجموعة متماثلة بأسماء بدلاً من عناوين IP وكان لديك شيء مثل هذا في / etc / hosts لعقد 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 / hosts لجميع خوادم تطبيقاتك.

اعتقدت أن node-mongo يتصل وفقًا لكل ما أضعه في URI ، لكن الأمر ليس كذلك.

يبدو أن node-mongo تتصل بواسطة IP أو اسم من Mongo URI ، ثم تحصل على أسماء مضيفين لأعضاء نسخة متماثلة أخرى من عقدة MongoDB الأولى التي استجابت للطلب. يحصل على سبيل المثال mongodb-2gb-fra1-03 ويمرره إلى نظام التشغيل للحل. إذا كان نظام التشغيل لا يعرف أي شيء عن mongodb-2gb-fra1-03 ، فإنه يرمي "خطأ لا يوجد خادم أساسي متاح".

امل ان يساعد.

adriank نعم ، هذا صحيح ، فهو

christkv ومع ذلك ، فهو كابوس لأدوات مثل MongoSpector . بسبب ذلك ، نواجه مشاكل في الاتصال الآمن بأكثر من نسخة متماثلة من مضيف واحد. تُنشئ DigitalOcean تلقائيًا أسماء إلى قطرات لا يغيرها أحد تقريبًا ، ويكون التأثير هو أن العديد من العملاء لديهم mongodb-2gb-fra1-01 كأساسي لهم. :) آمل أن نتمكن من معرفة شيء ما.

نحن نتتبع تذكرة خادم هنا https://jira.mongodb.org/browse/SERVER-1889. أحب أن يكون مثل هذا ممكنًا.

يجب علينا أيضًا تقديم تذكرة مع DigitalOcean للإشارة إلى الخطأ الذي يرتكبونه وكيف يؤثر على مستخدميهم.

بالمناسبة ، يمكنك إزالة أعضاء المجموعة المتماثلة وإعادة إضافتهم بأسمائهم الجديدة وهي ips

تواجه مشكلة مشابهة ، بعد حوالي 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" }