Mongoose: لا تعيد الاتصال بعد قطع الاتصال

تم إنشاؤها على ٢٦ أكتوبر ٢٠١٦  ·  47تعليقات  ·  مصدر: Automattic/mongoose

بعد الترقية من 4.4.11 إلى> = 4.6.1 ، نحصل على عمليات قطع عشوائية ولا يعيد النمس الاتصال أبدًا.

إصدار النمس: 4.6.5
نسخة mongodb: 3.2.9

هذه هي طريقة إنشاء الروابط:

    var uri = 'mongodb://USENAME:PASSWORD<strong i="9">@host1</strong>:port1,host2:port2/database?authSource=admin';

    var options = {};
    options.server = {
      auto_reconnect: true,
      poolSize: 5,
      socketOptions: { keepAlive: 1, connectTimeoutMS: 30000 },
      reconnectTries: 3000
    };

    options.replset = {
      auto_reconnect: true,
      poolSize: 5,
      socketOptions: { keepAlive: 1, connectTimeoutMS: 30000 },
      reconnectTries: 3000
    };

    var db = mongoose.createConnection(uri, options);

    mongoose.connection.on('error', function(err) {
      console.log('MONGODB ERROR MONGOOSE LEVEL ' + server, err);
    });

    db.on('connecting', function() {
      console.info('MONGODB ' + server + ' connecting.');
    });

    db.on('error', function(err) {
      console.log('MONGODB ERROR ' + server, err);
    });

    db.on('close', function(err) {
      console.log('MONGODB CLOSE ' + server, err);
    });

    db.on('connected', function() {
      console.info('MONGODB ' + server + ' connected successfully.');
    });

    db.once('open', function callback() {
      console.info('MONGODB ' + server + ' opened successfully.');
    });

    db.on('reconnected', function() {
      console.info('MONGODB ' + server + ' reconnected.');
    });

    db.on('timeout', function() {
      console.info('MONGODB ' + server + ' timeout.');
    });

    db.on('disconnected', function() {
      console.info('MONGODB ' + server + ' disconnected');
    });

هذا هو تسلسل الأحداث التي أحصل عليها:

pid:3429 MONGODB geo_uri connected successfully.
pid:3429 MONGODB geo_uri opened successfully.
pid:3429 MONGODB dashboards_db connected successfully.
pid:3429 MONGODB dashboards_db opened successfully.
pid:3429 MONGODB tweet_analytics_db connected successfully.
pid:3429 MONGODB tweet_analytics_db opened successfully.
pid:3429 MONGODB fullcontact_enrichment_db disconnected
pid:3429 MONGODB ERROR fullcontact_enrichment_db { [MongoError: no valid replicaset members found]
  name: 'MongoError',
  message: 'no valid replicaset members found' }
pid:3429 MONGODB uri connected successfully.
pid:3429 MONGODB uri opened successfully.
pid:3429 MONGODB sync_reports_db connected successfully.
pid:3429 MONGODB sync_reports_db opened successfully.
pid:3429 MONGODB uri disconnected
pid:3429 MONGODB CLOSE uri

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

picture aartiles
👍2

التعليق الأكثر فائدة

Koslun الشوكة يجب أن تكون غير ضرورية الآن. الإصلاح إلى حد كبير هو مجرد تعيين socketTimeout إلى 0 لخيارات قاعدة البيانات socketOptions الآن.

هيريس كيف تبدو خيارات المقبس الخاصة بي الآن.

    var opts = {
      server: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
      },
      replSet: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
    }
picture jakesjews في ١٣ فبراير ٢٠١٧
👍6 🎉3

ال 47 كومينتر

+1 ، حدث انقطاعان في آخر 5 أيام متعلقة بهذه المشكلة. الحل الحالي هو جعل عمليتي تتعطل بشكل واضح ( process.exit(0) ) عند انبعاث حدث disconnected . بعد ذلك ، تتم إعادة العملية وفتح الاتصال بشكل صحيح مرة أخرى.

أظن أن النمس يحاول إعادة الاتصال ، لكنه يفشل خلال الفاصل الزمني reconnectTries * reconnectInterval ، ولا يتم إصدار حدث error بسبب هذا الانحدار (https://github.com/Automattic/mongoose/pull / 4653). ما لا أعرفه هو سبب قطع اتصال النمس / النمس بشكل عشوائي ، لم يكن لدي هذا السلوك من قبل.
ما هي استضافة المونغو التي تديرها؟ mLab؟

loris picture loris في ٢٧ أكتوبر ٢٠١٦

نحن نستضيفه بأنفسنا في AWS. للأسف process.exit(0) ليس خيارًا بالنسبة لنا.

aartiles picture aartiles في ٢٧ أكتوبر ٢٠١٦

لقد قمت بتطبيق التغييرات في # 4653 وحصلت على نفس السلوك. قطع الاتصال بعد ساعتين:

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
aartiles picture aartiles في ٢٧ أكتوبر ٢٠١٦

لا يوجد حدث error انبعاث؟ (يجب أن يكون ، 30 ثانية بعد disconnected واحد)

loris picture loris في ٢٧ أكتوبر ٢٠١٦

لا ، ألق نظرة على الكود في وصف المشكلة. ما لم أفعل شيئًا خاطئًا ، هناك معالج حدث في مكان الحدث error . في الواقع ، لا تزال العملية جارية ولم يتسبب النمس في أي حدث آخر.

aartiles picture aartiles في ٢٧ أكتوبر ٢٠١٦

لقد واجهنا نفس المشكلات في الأيام القليلة الماضية منذ 4.6.5 - قطع الاتصال العشوائي الذي يتسبب في توقف عملية العقدة. ولكن لا يوجد حدث error . العودة إلى 4.5.3 works.

loris هل هذا متعلق بـ https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad في 4.6.6 ؟

mck- picture mck- في ٤ نوفمبر ٢٠١٦

mck نعم ، https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaad إصلاح حدث error الذي لم ينبعث عند فشل آلية إعادة محاولة الاتصال mongodb. ومع ذلك ، ليس لدي أي فكرة عن سبب حدوث قطع الاتصال العشوائي في المقام الأول ، أي فكرة @ vkarpov15؟

loris picture loris في ٤ نوفمبر ٢٠١٦

fwiw ، حدث لنا 40-50٪ من الوقت إذا حاولنا إجراء عملية حفظ / تحديث (كتابة حوالي 650 كيلوبايت)

mck- picture mck- في ٤ نوفمبر ٢٠١٦

نعم ليس لدي الكثير من الأفكار الجيدة. يمكنك محاولة الاتصال بـ close() على الاتصال ثم الاتصال بـ connect() بنفسك مرة أخرى. loris ، هل لديك تجربة مماثلة حيث يبدو أن الحفظ / التحديث الثقيل يتسبب في ذلك؟

vkarpov15 picture vkarpov15 في ١١ نوفمبر ٢٠١٦

نحن نواجه هذا أيضًا. في إحدى خدماتنا ، نحصل على حدث خطأ (الاتصال N بـ ds0XXXXX-a0.mongolab.com:XXXXX انتهت مهلة) ، متبوعًا بحدث غير متصل. والاتصال لا يعاد إنشاؤه أبدًا. في خدمة أخرى ، حصلنا على حدث غير متصل بعد طلب كبير على قاعدة البيانات ، وهو إزالة 2 مليون سجل. ثم يتعذر إعادة الاتصال (mongoose 4.6.6 ، DB الإصدار 3.0.12).

lushchick picture lushchick في ١١ نوفمبر ٢٠١٦

لقد حدث لنا ذلك مرة أخرى ، منذ بضع دقائق ، أثناء تشغيل mongodb على mLab أيضًا (لست متأكدًا من أنه مرتبط بذلك). لقد أجرينا استعلامًا كثيفًا ، وانتهت مهلته ( unhandledRejection { MongoError: connection 0 to ds****-a0.mongolab.com:**** timed out } ، تم إصدار حدث disconnected بشكل صحيح ، ولكن لم يحدث شيء بعد ذلك ، لا error ، لا reconnected إلخ ، وبالتالي ، استمر خادم الويب هذا في العمل واستلام طلبات HTTP ، ولكن انتهت مهلتها جميعًا حتى أعدنا تشغيلها لأنها استمرت في تشغيل الاستعلامات النميرية التي تم تخزينها مؤقتًا ولم يتم إرجاعها أبدًا.

إعداد النمس لدينا (4.6.5 في العقدة 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' }));

سيكون الحل المؤقت هو process.exit(0) أيضًا في disconnected event لإجبار خادم الويب على إعادة التشغيل وإعداد اتصال mongodb جديد. أيه أفكار؟

loris picture loris في ١١ نوفمبر ٢٠١٦

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

vkarpov15 picture vkarpov15 في ١٥ نوفمبر ٢٠١٦

لست متأكدًا مما هو الخطأ الآن (النمس أو سائق المونغو أو mlab أو heroku) ، ولكن في الأيام القليلة الماضية ، سيؤدي تشغيل طلب ويب ينفذ استعلامًا ضخمًا من النمس (يستغرق الرد على أكثر من 30 ثانية) إلى طلب heroku مهلة (هذه آلية في heroku تنتهي مهلة أي طلب ويب يستغرق أكثر من 30 ثانية). بمجرد انتهاء مهلة طلب الويب هذا ، فإن أي طلب ويب تالٍ على هذا الخادم والذي يتطلب استعلامًا نمسًا سينتهي أيضًا. ما هي المشكلة الحقيقية هو أن حدث الصفر يتم تشغيله بواسطة النمس (لا يوجد error ، close ، disconnected ، إلخ ...) ، لذلك ليس لدينا طريقة للكشف عن قطع الاتصال وإعادة تشغيل الخادم. إليك كيفية إعداد النمس:

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');
loris picture loris في ١٧ نوفمبر ٢٠١٦

Ioris هل يمكنك معرفة ما إذا كان هذا لا يزال يحدث إذا قمت بتعطيل cachegoose؟

vkarpov15 picture vkarpov15 في ١٩ نوفمبر ٢٠١٦

@ vkarpov15 سنحاول التحقق من ذلك ولكن ليس بالأمر السهل نظرًا لأن الخطأ يحدث فقط في الإنتاج ولا يمكننا تحمل تكلفة تشغيل الإنتاج مع تعطيل ذاكرة التخزين المؤقت.
aartiles @ تستخدمون يا رفاق المكون الإضافي لذاكرة التخزين المؤقت النمس؟

loris picture loris في ١٩ نوفمبر ٢٠١٦

من المحتمل أن يكون هذا مرتبطًا بـ https://github.com/christkv/mongodb-core/issues/148. لقد واجهت مشكلة مماثلة عندما يصبح عضو مجموعة متماثلة غير متوفر.

jakesjews picture jakesjews في ١٩ نوفمبر ٢٠١٦

نحن لا نستخدم mongoose cache plugin.

aartiles picture aartiles في ٢٠ نوفمبر ٢٠١٦

ما زلت أبحث في الأمر ، ما يمكنني إخبارك به حتى الآن:

  • تمكنت من إعادة إنتاج المشكلة على جهازي المحلي: بدأت حلقة تشغل استعلامًا سريعًا كل ثانية وتسجيل النتائج ، وتأخر بعض الشيء لاحقًا ، وأجريت استعلامًا كثيفًا (مثل استعلام غير مفهرس على مجموعة مليون صف). سيتم قفل / مهلة جميع الاستعلامات (السريعة أيضًا) ، ولن يتم إطلاق أي حدث نمس.
  • ظهرت المشكلة في 4.6.5 ، والرجوع إلى 4.6.4 لحل المشكلة (لا يزال يتم تنفيذ الاستعلامات السريعة أثناء تشغيل الاستعلام الثقيل)
  • يبدو أنه لا علاقة له بـ:

    • المكون الإضافي mongoose cache

    • تشغيل مجموعة متماثلة أم لا

loris picture loris في ٢٢ نوفمبر ٢٠١٦

لقد قمت بإجراء المزيد من عمليات البحث وجاءت المشكلة مع الترقية إلى [email protected] ، والتزام عربات التي تجرها الدواب هناك https://github.com/mongodb/node-mongodb-native/pull/1418
يبدو أنهم أصلحوا خطأ مطبعي ، ولكن يتم استخدام هذا eventName (مع الخطأ المطبعي) من قبل بعض الإدارات

loris picture loris في ٢٢ نوفمبر ٢٠١٦

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

jakesjews picture jakesjews في ٢٢ نوفمبر ٢٠١٦

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

loris picture loris في ٢٢ نوفمبر ٢٠١٦

وجود مشكلة مماثلة: فشل في إعادة الاتصال بعد قطع الاتصال. يتجلى ذلك في العميل بالتعليق على أي عملية db mongoose (تنتهي المهلة عبر التخزين المؤقت للعملية).

jakesjews مشكلتي هي فريدة من نوعها لمجموعات النسخ المتماثلة أيضًا ولا تحدث مع اتصال عقدة واحدة. النظر أكثر في جوهر replset.js.

تم تمكين تسجيل تصحيح الأخطاء داخل node-mongodb-native لمعرفة ما إذا كانت إعادة اتصال HA تعمل كما هو متوقع ، على ما يبدو.

attemptReconnect for replset with id successful resuming topologyMonitor 1

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

كما ذكر loris ، فإن process.exit (0) -> ستعمل إعادة تشغيل الخدمة (في حالتي) نظرًا لأن المشكلة مرتبطة مباشرة بإعادة الاتصال بمجموعة متماثلة ولكنها ليست مثالية مرة أخرى.

[email protected]
[email protected]

kog13 picture kog13 في ٢٢ نوفمبر ٢٠١٦

@ mck- وجدت نفس الشيء مثلك ، أدى الرجوع إلى الإصدار

يمكنني الترقية على طول الطريق إلى 4.5.10 قبل أن يبدأ الفشل في 4.6.0 حيث تحدث مشكلة إعادة الاتصال بالمجموعة المتماثلة لأول مرة. التخمين الحالي هو أنه يمكن أن يكون مرتبطًا بالترقية إلى برنامج تشغيل mongodb 2.2.9.

kog13 picture kog13 في ٢٣ نوفمبر ٢٠١٦

loris ، هل يمكنك تقديم حالة الاختبار الخاصة بك حتى نتمكن من تجربتها؟

aartiles picture aartiles في ٢٣ نوفمبر ٢٠١٦

ما زلت أبحث في الأمر ، كنت مخطئًا في السابق بشأن ارتكاب إصلاح الخطأ المطبعي. يبدو أن الجاني هو https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f
يعد تقديم حالة الاختبار أمرًا معقدًا بعض الشيء لأنه لا يحدث إلا بهذه الطريقة:

  • mongoose 4.6.8 ، الاتصال بمضيفي المحلي mongodb (3.2) بالإعدادات الافتراضية
  • مساران سريعان ، أحدهما يقوم بتشغيل استعلام نمس طويل المدى (عدة ثوانٍ) ، والآخر يقوم بتشغيل استعلام نمس سريع التشغيل (لا تحدث المشكلة عند تشغيل استعلامات mongoose مباشرة في العقدة ، مع حالة اختبار setInterval / setTimeout على سبيل المثال ، لذا أعتقد أنه مرتبط بكيفية التعامل مع اتصال التجمع)
  • إذا قمت بتنفيذ المسار السريع طويل المدى ، ثم حاولت الوصول إلى التشغيل السريع ، فسيستمر الأخير في العمل دون العودة
  • عند تعيين poolSize إلى 50 بدلاً من الإعداد الافتراضي ، أصلح المشكلة
  • التحقق من الالتزام السابق من mongodb-core بإصلاح المشكلة أيضًا (يعود المسار السريع السريع التشغيل في غضون بضع مللي ثانية أثناء معالجة مسار التشغيل الطويل) (مع حجم التجمع الافتراضي)
  • لذلك أعتقد أن https://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57f غيّر شيئًا ما في كيفية استخدام نمس طويل المدى لاستخدام كل اتصال متاح في حمام السباحة
loris picture loris في ٢٣ نوفمبر ٢٠١٦

لقد وصل الإصلاح للتو إلى mongo-core والذي قد يحل هذه المشكلة.

jakesjews picture jakesjews في ٢٣ نوفمبر ٢٠١٦

loris ، نعم ، poolSize وقت واحد. ستساعد زيادة حجم البركة ، فقط لا تزيدها كثيرًا ، أو ستبدأ في رؤية مشكلات الأداء مع WiredTiger.

vkarpov15 picture vkarpov15 في ٢٦ نوفمبر ٢٠١٦

أهلا،
أي تحديث على هذا؟ أرى نفس المشكلة ، لا يعمل auto_reconnect عند استخدام مجموعة النسخ المتماثلة. لقد جربت للتو النمس 4.7.0 مع mongodb 2.2.11 وما زلت لا أعيد الاتصال. أنا أستخدم mongod الإصدار 3.2.10.

أقوم بتشغيل كل شيء على مضيف واحد (كمبيوتر محمول) مع ثلاث مثيلات من mongod تعمل على منافذ مختلفة بأدلة قاعدة بيانات مختلفة. لا يبدو أن هذا يجب أن يكون مشكلة ، لكنني جديد على mongo / mongoose / node / javascript. تطبيق العقدة الخاص بي مع النمس يعمل أيضًا على نفس المضيف.

يمكنني إعادة إنتاج هذا ببساطة عن طريق إيقاف تشغيل جميع العمليات النموذجية
(launchctl stop mongod01 ؛ launchctl stop mongod02 ؛ launchctl stop mongod03)
انتظر رسالة إغلاق الاتصال ثم أعد التشغيل (استبدل كلمة "stop" بكلمة "start" في أوامر launchctl). تطبيقي لا يعيد الاتصال بـ mongo أبدًا.

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

يسعدني تقديم السجلات أو تجربة التصحيحات إذا كان ذلك مفيدًا.

joeldodson picture joeldodson في ٣٠ نوفمبر ٢٠١٦

بعد القيام ببعض الحفر ، أعتقد أنني ربما وجدت مصدرًا واحدًا للمشكلة. يبدو أنه عندما يكون الاتصال التلقائي صحيحًا ، لا يُفترض أن يصبح المخزن المؤقت للاتصال نشطًا https://github.com/Automattic/mongoose/blob/master/lib/drivers/node-mongodb-native/connection.js#L153 عند الاتصال أحداث قريبة. ومع ذلك ، لا يوجد المزيد من خاصية autoReconnect التي يتم تعيينها داخل فئة الاستبدال في mongodb-native https://github.com/mongodb/node-mongodb-native/blob/2.2/lib/replset.js لذلك أي حدث قريب من إحدى العقد يتسبب في تمكين المخزن المؤقت بشكل دائم. لقد حالفني بعض الحظ في الالتزام https://github.com/eflexsystems/mongoose/commit/5ac12727f34b41791f94643b66c8cc88aff4d66a لكنني أريد منحه مزيدًا من الوقت لمعرفة ما إذا كان قد تسبب في أي مشكلات أخرى قبل تقديم طلب سحب.

jakesjews picture jakesjews في ٣٠ نوفمبر ٢٠١٦

joeldodson أنت تصف نفس المشكلة التي واجهتها. يبدو أن مجرد إصدار تنبيه> = 4.6.0 يحتوي على المشكلة. سأحاول 4.5.10 في غضون ذلك ، لقد تم إعادة الاتصال بإعادة الاتصال والاتصال الفردي المناسب لي.

kog13 picture kog13 في ١ ديسمبر ٢٠١٦

شكرا jakesjews و @ kog13

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

لدي بالفعل منطق يجلس في حلقة مع مؤقت 5 ثوانٍ لمحاولة الاتصال إذا لم تكن قاعدة البيانات متاحة عند بدء تشغيل التطبيق. لقد حاولنا استدعاء ذلك في معالج db.on ('مغلق' ، الوظيفة () {...}) ويبدو أنه يعمل بشكل جيد. لكن ما يقلقني هو ما إذا كانت محاولة الاتصال صراحةً ستتعارض مع أي منطق لإعادة الاتصال تحت الغطاء. نظرًا لأنه لا يبدو أن إعادة الاتصال تحدث لمجموعات النسخ المتماثلة ، أعتقد أنه لا بأس بذلك. كما قمنا بتعيين auto_reconnect إلى false في خيارات الاتصال لكل من الخادم وإعادة الضبط.

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

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

شكرا.

joeldodson picture joeldodson في ٢ ديسمبر ٢٠١٦

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

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

سبب تعيين socketTimeout على 0 هو وجود خطأ في mongo-core لا زلت بحاجة إلى تقديم مشكلة له. سبب المشكلة هو تقليص / توسيع تجمع الاتصال ديناميكيًا. الطريقة التي يعمل بها التجمع هي أنه في كل مرة يضيف فيها اتصالًا جديدًا ، سيتم إغلاق الاتصال بعد 30 ثانية من عدم النشاط. تؤدي أحداث المهلة إلى الإزالة من التجمع وتقوم أيضًا بإجراء فحص لمقارنة عدد المهلات بحد 30 محاولة اتصال. هناك نبضة قلب تعمل كل ثانيتين وتزيل عدد المهلات ولكن إذا تم وضع 30 طلبًا أو أكثر في قائمة الانتظار بالتوازي ، فسيؤدي ذلك إلى انتهاء مهلة كل منهم بين نبضات القلب وتدمير مجموعة الاتصال. في الوقت الحالي ، يؤدي تعيين المهلة على الاتصالات إلى 0 إلى منع الاتصالات من التقليم مرة أخرى في التجمع إذا كانت غير نشطة وتجنب المشكلة. إذا كنت ترغب في تكرار المشكلة ، فحاول تعيين حجم تجمع اتصال إلى ما يقرب من 50 وتشغيل 50 استعلامًا متوازيًا. بعد ذلك ، سيتم تدمير المسبح في حوالي 30 ثانية. لاحظ أن المهلة لا تؤثر على ضربات القلب التي تتحقق من المجموعة المتماثلة نظرًا لأن ذلك له مهلة خاصة به.

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

jakesjews picture jakesjews في ٢ ديسمبر ٢٠١٦

شكرا مرة أخرى jakesjews. لقد سحبت في مستودعات النمس و mongodb-core. إعادة الاتصال عملت. لم أحصل على الحدثين "المتصلين" و "المعاد توصيلهما" رغم أنني أحصل عليهما عند استخدام مثيل واحد من Mongo. كما يبدو أن حالة الاستعداد لا تتم إعادة تعيينها ، فهي لا تزال 0 حتى بعد إعادة الاتصال.

يسعدني مساعدتك في اختبار السجلات أو جمعها.

joeldodson picture joeldodson في ٢ ديسمبر ٢٠١٦

لا تزال تواجه المشكلة مع [email protected]

loris picture loris في ٦ ديسمبر ٢٠١٦

هل من جديد بخصوص هذا الموضوع؟

YouriT picture YouriT في ٢٥ يناير ٢٠١٧
👍4

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

يجب التعامل مع هذه المشكلة وإلا فلن تكون الحزمة قابلة للاستخدام.
ربما سأحاول حل jakesjews عندما يكون لدي الوقت. حتى ذلك الحين باستخدام 4.4.X

Serfenia picture Serfenia في ١٣ فبراير ٢٠١٧

إذا كانت المشكلة هي خلل في النمس ، فهذه ليست مشكلة مع النمس. إذا كنت تواجه المشكلة مع أحدث إصدار من النمس ، فهل يمكنك تقديم مشكلة في mongodb-core repo؟

varunjayaraman picture varunjayaraman في ١٣ فبراير ٢٠١٧

في الواقع ، إنها مشكلة مع mongoose حيث تم تحديثها للاعتماد على إصدار mongodb-core الذي به مشكلة. ربما يجب إعادة mongoose إلى إصدار سابق من mongodb-core .

loris picture loris في ١٣ فبراير ٢٠١٧

jakesjews برؤية أن [email protected] يعتمد على [email protected] ، والذي يعتمد بدوره على [email protected] ، فإن تطبيق الإصلاحات من fork سيكون كل ما هو مطلوب لإصلاح هذه المشكلات مع عدم وجود آثار جانبية على ما يبدو؟

وبالنظر إلى الشوكة الخاصة بك ، فإن هذا الالتزام هو الآن التغيير الوحيد الضروري لـ 4.7.x و / أو 4.8.x PR؟

Koslun picture Koslun في ١٣ فبراير ٢٠١٧

Koslun الشوكة يجب أن تكون غير ضرورية الآن. الإصلاح إلى حد كبير هو مجرد تعيين socketTimeout إلى 0 لخيارات قاعدة البيانات socketOptions الآن.

هيريس كيف تبدو خيارات المقبس الخاصة بي الآن.

    var opts = {
      server: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
      },
      replSet: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
    }
jakesjews picture jakesjews في ١٣ فبراير ٢٠١٧
👍6 🎉3

jakesjews حسنًا ، شكرًا على التوضيح السريع :).

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

Koslun picture Koslun في ١٣ فبراير ٢٠١٧
👍2

أي تحديثات بخصوص تعليق Koslun ؟

Serfenia picture Serfenia في ٣٠ مارس ٢٠١٧

أي تحديثات لهذه القضية؟

tiant167 picture tiant167 في ١٦ مايو ٢٠١٧
👍3

لا يزال الإصدار مفتوحًا من عام 2016: open_mouth:

أتساءل ما إذا كان لا يزال من الممكن حدوث هذه المشكلة مع mongoose 5.x مع برنامج تشغيل mongodb 3.3.4 وخادم MongoDB في الإصدار 4.x؟ : التفكير:

szabolcs-szilagyi picture szabolcs-szilagyi في ١٠ ديسمبر ٢٠١٩

هل يعلم أي شخص ، إذا تمت إعادة تعيين محاولات إعادة الاتصال عند نجاح إعادة الاتصال.

مثيل Fox ، إذا تم تعيين إعادة الاتصال إلى 30 ، وحاول النمس مرة واحدة قطع الاتصال 5 مرات وكان الاتصال ناجحًا.
في المرة القادمة التي يُفقد فيها الاتصال ، ما هو عداد عمليات إعادة المحاولة؟
هل ستحاول إعادة الاتصال 30 مرة؟
أو 25 مرة؟

bhaveshvyas007 picture bhaveshvyas007 في ١٣ ديسمبر ٢٠١٩

@ szabolcs-szilagyi نعم ، ولكن فقط إذا لم تقم بتعيين useUnifiedTopology إلى true .

@ bhaveshvyas007 نعم يفعل. إليك الكود ذي الصلة

vkarpov15 picture vkarpov15 في ٢٠ ديسمبر ٢٠١٩

للأجيال القادمة:

إذا كنت تقوم بتشغيل Mongoose 5.x بدون useUnifiedTopology ، فاقرأ هذا الدليل لإدارة اتصالات MongoDB .

إذا كنت تقوم بتشغيل Mongoose 5.x باستخدام useUnifiedTopology ، فلن تؤثر هذه المشكلة عليك.

vkarpov15 picture vkarpov15 في ٢٠ ديسمبر ٢٠١٩
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

AraanBranco picture AraanBranco  ·  3تعليقات
varunjayaraman picture varunjayaraman  ·  3تعليقات
ArThoX picture ArThoX  ·  3تعليقات
gustavomanolo picture gustavomanolo  ·  3تعليقات
ghost picture ghost  ·  3تعليقات