ومرة أخرى خطأ 1040 ...
يتلقى الدعم الفني العديد من الشكاوى حول هذا الخطأ السيئ السمعة: ERROR 1040: Too many connections - الكثير من الاتصالات. المشكلة واضحة: التطبيق أو المستخدمون ينشئون اتصالات أكثر مما يسمح به الخادم ، أي أن العدد الحالي للاتصالات يتجاوز قيمة متغير max_connections .
يمثل الموقف بحد ذاته مشكلة بالنسبة للمستخدمين النهائيين ، ولكن إذا كنت لا تزال غير قادر على الوصول إلى الخادم لتشخيص السبب وتصحيحه ، يصبح كل شيء سيئًا للغاية. عادة ، يجب عليك إكمال المثيل وإعادة تشغيله من أجل استرداد.
لا يمكن للمستخدم الجذر الاتصال إما! لماذا؟
في بيئة مكونة بشكل صحيح ، سيتمكن المستخدم الذي SUPER امتياز SUPER من الوصول إلى المثيل وتشخيص سبب الخطأ 1040 بسبب عدم وجود اتصالات كافية. هذا موصوف في الدليل:
mysqld يسمح max_connections + 1 اتصالات العميل. محجوز اتصال إضافي للحسابات مع امتيازات SUPER . عندما يتم منح هذه الامتيازات للمسؤولين ، وليس للمستخدمين العاديين (الذين لا يحتاجون إليها) ، يمكن للمسؤول الذي لديه امتياز PROCESS الاتصال بالخادم واستخدام SHOW PROCESSLIST لتشخيص المشكلات ، حتى لو تم توصيل الحد الأقصى لعدد العملاء دون امتيازات.
لكن الكثير من الأشخاص يمنحون امتيازات SUPER لمستخدميهم للتطبيق أو البرنامج النصي - نظرًا لمتطلبات التطبيق (خطير!) أو قلة المعرفة بالنتائج ، ثم يشغل المستخدم العادي الاتصال المحجوز ، ولا يمكن للمستخدم الإداري (عادةً root ) الاتصال.
كيفية ضمان الوصول إلى مثيل
يمكنك استخدام الاختراق المشهور مع GDB ، التي نصحت Aurimas منذ 100 عام بالخطأ 1040 ، ولكن الآن هناك حلول أفضل. صحيح ، يجب أن يتم تشغيلها أولاً.
باستخدام Percona Server 5.5.29 والإصدارات الأحدث و MySQL 8.0.14 والإصدارات الأحدث ، يمكنك تكوين منفذ آخر بعدد إضافي من الاتصالات. لن يستخدم التطبيق هذه الواجهات. وهي مخصصة فقط لمسؤولي قواعد البيانات ووكلاء المراقبة والتحقق من الصحة (انظر الملاحظة أدناه).
تكوين خادم Percona
بدءًا من Percona Server 5.5.29 ، يمكنك ببساطة إضافة extra_port إلى my.cnf ، وفي المرة التالية التي تقوم فيها بإعادة التشغيل ، سيكون المنفذ متاحًا ويتوقع بيانات على bind_address مثل الاتصالات العادية. إذا لم تقم بتكوين متغير extra_port ، فلن يكون هناك منفذ إضافي افتراضيًا.
يمكنك أيضًا تحديد extra_max_connections لتحديد عدد الاتصالات التي سيتعامل معها هذا المنفذ. الرقم الافتراضي هو 1.
على سبيل المثال ، أخذت جميع الاتصالات بمنفذ المستخدمين العاديين من المثيل الذي قمت فيه بالفعل بتكوين extra_port و extra_max_connections في my.cnf :
يؤدي
بالمناسبة ، تمت إزالة extra_port في Percona Server 8.0.14 والإصدارات الأحدث ، لأنه يتم تنفيذ admin_port بنفس الوظائف في مجتمع MySQL. لذا قم بتحرير my.cnf عند الترقية إلى Percona Server 8.0.14 أو أعلى إذا كنت قد حددت بالفعل extra_port.
كما قلت ، يتطلب هذا MySQL 8.0.14 ، حيث يتم استخدام WorkLog 12138 .
لتمكين واجهة المشرف ، تحتاج إلى تعريف admin_addres ، والذي يجب أن يكون العنوان الوحيد والفريد (بدون أحرف البدل) IPv4 أو IPv6 أو IPv4 المعين أو اسم المضيف الذي تنتظر عنده واجهة المشرف إرسال البيانات. إذا لم يتم تعريف هذا المتغير ، فلن يتم تمكين الواجهة.
لا يزال بإمكانك تحديد المنفذ ، ولكن هذا ليس ضروريًا. بشكل افتراضي ، هذا هو المنفذ 33062 . إذا كان هذا المنفذ مجانيًا ، فلن تحتاج إلى تكوين هذه القيمة. إذا قمت بالتكوين ، فضع كلا المتغيرين في قسم [mysqld] في my.cnf .
أخيرًا ، يمكنك تكوين create_admin_listener_thread (يتم تعطيله افتراضيًا) ، مما يؤدي إلى إنشاء مؤشر ترابط منفصل لمعالجة الاتصالات الواردة. قد يكون هذا مفيدًا في بعض الحالات.
الفرق الآخر هو أن وثائق Oracle تقول:
عدد الاتصالات الإدارية غير محدود.
(ولدينا القيمة الافتراضية 1). لست متأكدًا مما يعنيه ذلك ، لكنني سأحرص على عدم إنشاء مليون اتصال بطريق الخطأ. بالطبع ، ليست محدودة ، لكنها لا تزال تستهلك الموارد.
استخدام لرصد والفحوصات الصحية
ملائمًا ، لا يمكن للأشخاص فقط استخدام واجهة أو منفذ إضافي في حالات الطوارئ عندما نصل إلى max_connections . يمكن توصيل نظام مراقبة اكتشاف وكيل / موازن / خدمة اكتشافه.
ستكون البرامج النصية الخاصة بالمراقبة قادرة على استرداد البيانات الخاصة بالرسومات التخطيطية حتى تتمكن من معرفة مصدر الكثير من الاتصالات. وستقوم البرامج النصية الخاصة بالتحقق من الصحة بالإبلاغ عن حالة الخادم المتدهورة ، وقد تشير بعض الرموز إلى أن هناك الكثير من الاتصالات ، ولكن الخادم يدير (أي ، يمكنه معرفة ذلك ومن الأفضل الانتظار لفترة أطول قليلاً قبل أن يفشل).
تأكد من تثبيت اتصال واحد فقط في كل مرة للمراقبة والفحوصات الصحية ، حتى لا تسد ext_max_connections في Percona Server ولا تنشئ مليون مؤشر ترابط في MySQL. بمعنى ، لا يجب توصيل البرامج النصية مرة أخرى إذا كان الطلب السابق أو الاتصال بقاعدة البيانات لا يزال نشطًا.
هنا هو نفس المثال ، ولكن مع الخلية .
بالنسبة إلى Percona Server 8.0.14 والإصدارات الأحدث ، ستكون العملية هي نفسها في MySQL Community.
مساعدة! أحتاج إلى الدخول ، لكن جميع المنافذ مشغولة!
إذا كان هذا هو السبب في قيامك بقراءة هذا المنشور ، فاستخدم مجنونة مجنونة مع GDB (لا جريمة ، Aurimas ، فهي تبدو محفوفة بالمخاطر :-D) أو إنهاء المثيل. لحسن الحظ ، يمكن دائمًا إنهاء مثيل بدقة مع SIGTERM (-15) بدلاً من SIGKILL (-9). وبالتالي ، سيتوقف الخادم عن العمل تمامًا ، وستتاح له الخيوط فرصة لإيقاف التشغيل بشكل طبيعي. فقط اتبع التعليمات:
1) الحصول على PID:
marcos.albe in ~/ pgrep -x mysqld; 650
2) أرسل SIGTERM إلى PID:
marcos.albe in ~/ kill -15 650;
3) تحقق في سجل الأخطاء كيف يتم تنفيذ الاغلاق. سيبدو شيء مثل هذا:
2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully 2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads 2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients
هذا يمثل بداية عملية الاكتمال. سيتم إكمال المثيل عندما ترى سطرًا مشابهًا:
2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete