Knex: الحصول على "Knex: مهلة الحصول على اتصال. المسبح ممتلئ على الأرجح." خطأ

أنا أيضا أواجه هذه المشكلة.

لدي نفس المشكلة.

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

بمعنى آخر ، هناك العديد من الأشياء التي يمكن أن تسبب الخطأ. اثنان من الأكثر شيوعًا هما:

1. تنسى تنفيذ المعاملات / تنسى استدعاء .transacing(trx) على أدوات إنشاء الاستعلام أثناء وجودك بالفعل في أقصى تجمع والذي لا يؤدي فقط إلى توقف المعاملة عن العمل ولكن أيضًا يلقي بالخطأ حيث لا يمكن الحصول على اتصال.
2. يظل المسبح مشغولاً باستمرار بأقصى سعة لمدة 60 ثانية على الأقل (افتراضيًا) بدون توقف ، على سبيل المثال بسبب حركة المرور الكثيفة أو إجراءات التشغيل الطويلة.

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

أنا أيضا أواجه هذا الخطأ.

rejecter(new _bluebird2.default.TimeoutError('Knex: Timeout acquiring a connection. The pool is probably full. ' + 'Are you missing a .transacting(trx) call?')); ^ TimeoutError: Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?

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

rsfernandes طالما أنك تستخدم معالجات catch على أدوات الإنشاء الخاصة بك ، فأنا لا أرى كيف سيؤدي هذا الخطأ إلى تعطل التطبيق بأكمله.

بالنسبة للمكدس ، أوصي بـ longStackTraces . لا يوجد شيء مضمّن في knex خصيصًا لمجموعة الأخطاء هذه.

FWIW لقد تلقيت هذا الخطأ مع خدمة قاعدة بيانات AWS Aurora ، وكان سببه ميزة الإغلاق التلقائي التي تنهي قاعدة البيانات بعد عدم النشاط (يستغرق بدء التشغيل التلقائي لقاعدة البيانات دقيقة أو نحو ذلك ، مما تسبب في انقضاء مهلة knex)

https://github.com/tgriesser/knex/issues/3159 توجد قائمة ببعض الأعمال حول اقتراحات الشفق.

تضمين التغريدة

1. يظل المسبح مشغولاً باستمرار بأقصى سعة لمدة 60 ثانية على الأقل (افتراضيًا) بدون توقف ، على سبيل المثال بسبب حركة المرور الكثيفة أو إجراءات التشغيل الطويلة.

إذا كانت هذه هي المشكلة ، فما هي التوصيات التي يمكن اتخاذها إذا لم يكن بإمكانك القيام بعمل أقل؟ 😅

زيادة المهلة أو السعة القصوى؟

لم تكن مشكلتي مع knex ولكن مع قاعدة مجموعة الأمان الواردة على aws RDS. تم تعيينه على عنوان IP للجهاز المحلي الخاص بي فقط ولذا لم أتمكن من الاتصال به من مثيل ec2. كان محبطًا لأن رسالة الخطأ لم تكن مفيدة.
إذا كانت لديك رسالة الخطأ هذه ، فقد تكون مرتبطة بحقيقة أن knex لا يمكنه إنشاء اتصال. لذا تحقق من شبكاتك أيضًا!

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

لقد قمت بحل المشكلة مع هذه الإصدارات:

"knex": "^0.21.1",
"objection": "^2.1.3",
"pg": "^8.0.3"

قد تضطر إلى التبديل إلى Node 12 NOT Node 14

كان لدي حد لتجمع قاعدة البيانات ، يمكنني إصلاح المشكلة عن طريق تعيين الحد الأدنى والحد الأقصى

لدي نفس المشكلة على جهاز Mac الخاص بي. كنت أقوم بتشغيل knex من محطة سطر الأوامر وفجأة بدأت في رؤية مشكلة Knex: Timeout ... اكتشفت أن المشكلة كانت الانتقال إلى zsh shell بدلاً من bash. لقد كنت أستخدم bash لفترة طويلة ، وحاولت مؤخرًا التبديل إلى zsh وفقًا لإرشادات Apple. بمجرد أن عدت إلى باش تم إصلاحه.

أتمنى أن يساعد شخص ما.

قد تضطر إلى التبديل إلى Node 12 NOT Node 14

لقد نجح هذا بالنسبة لي على عقدة تكوين عامل الإرساء لنظام التشغيل Mac: 12 بدلاً من العقدة (الإصدار 14). شكرا.

كنت أحاول فرض استخدام إصدار عقدة الخادم باستخدام nvm exec 12 node ./src/index... وكان الخطأ أعلاه.

من خلال إطلاق العقدة مباشرة ، اختفى الخطأ وتم إنشاء الاتصال.

لذا تأكد من أنك تستخدم إعدادًا عاديًا عاديًا وربما العقدة 12.

batadamnjanovic لقد أنقذتني بعد يومين كاملين من البحث. تاي !!