أرخص طريقة لتحديد ما إذا كان اتصال MySQL لا يزال على قيد الحياة

Question

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

الحيلة هي: البيئة التي أقوم بترميزها تعطيني فقط واجهة برمجة تطبيقات مجردة للغاية في الاتصال. لا يمكنني تنفيذ عبارات SQL إلا في الأساس. ليس لدي إمكانية الوصول إلى المقبس الفعلي أو الوصول المباشر إلى واجهة برمجة تطبيقات عميل MySQL.

لذا ، فإن السؤال هو: ما هو أرخص بيان MySQL الذي يمكنني تنفيذه على الاتصال لتحديد ما إذا كان يعمل. علي سبيل المثال SELECT 1; يجب أن تعمل ، لكنني أتساءل عما إذا كان هناك شيء أرخص؟ ربما شيء لا يمر عبر السلك ، ولكن يتم التعامل معه في LIB عميل MySQL ويجيب بشكل فعال على نفس السؤال؟

توضيح: لست قلقًا بشأن التحقق مما إذا كان خادم MySQL يعمل ، أو إذا كان تكوين قاعدة البيانات قد ارتفع بما يكفي للإجابة على الاستعلامات. إذا انخفضت هذه الأشياء ، فإن SQL اللاحق تنفيذ الخدمة ستحصل على الخطأ المناسب والتعامل معه. أنا مهتم حقًا فقط إذا كان اتصال TCP مفتوحًا ... لأنه إذا أغلقه الخادم ، فإن SQL لخدمة الويب ستحصل على خطأ يعني "مجرد إعادة الاتصال وحاول مرة أخرى" ، وسيكون ذلك غير مريح للقيام به مرة واحدة. الوحل من رمز الخدمة.

إنهاء: ال /* ping */ الاختراق هو بالضبط نوع الشيء الذي كنت أبحث عنه ، ولكن للأسف لا يتوفر إلا عبر JDBC. من خلال قراءة المستندات لهذا الاختراق ، من الواضح أنه تم وضعه هناك بالضبط نفس السبب الذي أردته. من أجل الفضوليين ، أنا أعمل في هاسكل, ، استخدام HDBC و HDBC-MYSQL. سأطلب من مؤلف HDBC-MySQL إضافة طريقة للاتصال mysql_ping() إما مباشرة أو عبر اختراق مماثل.

فلاد DO 1 كان أيضًا نوع الشيء الذي كنت عليه ، وبما أن الاختراق الآخر غير متوفر خارج JDBC ، فسأستخدمه.

شكرا على كل المناقشة الرائعة ، وخاصة VLAD!

Answer 1

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

هذا ما يقال ، أود أن أزعم ذلك Pinging اتصال قبل إن التحقق من ذلك من المسبح ليس هو أفضل طريقة.

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

لذلك ، من المشكوك فيه ، في رأيي ، ما هي قيمة اختبار حالة الاتصال قبل التحقق من اتصال من التجمع بالفعل. قد يكون من المفيد اختبار حالة الاتصال قبل فحص الاتصال مرة أخرى إلى حمام السباحة, ، ولكن يمكن القيام بذلك ضمنيًا بمجرد وضع علامة على الاتصال على أنه قذر عندما ينشأ خطأ صلب SQL (أو استثناء مكافئ) (ما لم تكن واجهة برمجة التطبيقات التي تستخدمها بالفعل تعرض أ is-bad-مثل دعوة لك.)

لذلك أوصي:

• تنفيذ policty من جانب العميل
• عدم إجراء أي شيكات عند التحقق من الاتصالات من التجمع
• إجراء فحوصات قذرة قبل إرجاع الاتصال إلى حمام السباحة
• دع رمز التطبيق يتعامل مع شروط اتصال استثنائية أخرى (غير زمنية)

تحديث

سيظهر من تعليقاتك أنك حقًا هل حقا هل تريد ربط الاتصال (أفترض أن هذا ليس لديك سيطرة كاملة على خصائص المهلة على خادم MySQL أو معرفتها على خادم MySQL أو معدات الشبكة المتداخلة مثل الوكلاء وما إلى ذلك)

في هذه الحالة يمكنك استخدامها DO 1 كبديل عن SELECT 1; ؛ أنه هامشي أسرع - أقصر للحالة ، ولا يعيد البيانات الفعلية (على الرغم من أنك إرادة احصل على TCP ackS ، لذلك ستظل تقوم بالتحقق من صحة Roundtrip التي لا تزال الاتصال.)

تحديث 2

متعلق وظيفة جوشوا, ، إليك آثار التقاط الحزم لسيناريوهات مختلفة:

SELECT 1;
13:51:01.463112 IP client.45893 > server.mysql: P 2270604498:2270604511(13) ack 2531191393 win 1460 <nop,nop,timestamp 2983462950 59680547>
13:51:01.463682 IP server.mysql > client.45893: P 1:57(56) ack 13 win 65306 <nop,nop,timestamp 59680938 2983462950>
13:51:01.463698 IP client.45893 > server.mysql: . ack 57 win 1460 <nop,nop,timestamp 2983462951 59680938>

DO 1;
13:51:27.415520 IP client.45893 > server.mysql: P 13:22(9) ack 57 win 1460 <nop,nop,timestamp 2983488906 59680938>
13:51:27.415931 IP server.mysql > client.45893: P 57:68(11) ack 22 win 65297 <nop,nop,timestamp 59681197 2983488906>
13:51:27.415948 IP client.45893 > server.mysql: . ack 68 win 1460 <nop,nop,timestamp 2983488907 59681197>

mysql_ping
14:54:05.545860 IP client.46156 > server.mysql: P 69:74(5) ack 78 win 1460 <nop,nop,timestamp 2987247459 59718745>
14:54:05.546076 IP server.mysql > client.46156: P 78:89(11) ack 74 win 65462 <nop,nop,timestamp 59718776 2987247459>
14:54:05.546092 IP client.46156 > server.mysql: . ack 89 win 1460 <nop,nop,timestamp 2987247459 59718776>

كما ترون ، باستثناء حقيقة أن mysql_ping الحزمة هي 5 بايت بدلا من DO 1;بايت 9 ، عدد المستديرة (وبالتالي ، الكمون الناجم عن الشبكة) هو نفسه بالضبط. التكلفة الإضافية الوحيدة التي تدفعها DO 1 في مقابل mysql_ping هو تحليل DO 1, ، وهو تافهة.

Answer 2

لست متأكدًا من واجهة برمجة التطبيقات (API) التي تستخدمها حاليًا (أو ما هي اللغة) ، ولكن بالنسبة لـ Java ، هناك خدعة خاصة يمكن أن يقوم بها برنامج تشغيل JDBC.

استعلام الاختبار القياسي هو:

select 1

كما أشرت. إذا قمت بتعديلها إلى:

/* ping */ select 1

سيلاحظ برنامج تشغيل JDBC هذا ، وإرسال حزمة واحدة فقط إلى خادم MySQL للحصول على استجابة.

لقد تعلمت عن هذا في حلقة Sun 'Deep Dive' بعنوان بعنوان نصائح MySQL لمطوري Java مع Mark Matthews.

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

Answer 3

"الاتصال" في هذه الحالة له معاني متعددة. يستمع MySQL على مقبس- هذا هو "اتصال" على مستوى الشبكة. تحافظ MySQL على "اتصالات قاعدة البيانات" ، والتي تتضمن سياقًا لتنفيذ الاستعلام وغيرها من النفقات العامة.

إذا كنت تريد فقط معرفة ما إذا كانت الخدمة تستمع ، فيجب أن تتمكن من تنفيذ مكالمة على مستوى الشبكة لمعرفة ما إذا كان المنفذ (لا يعرف ما هو افتراضي) يستمع إلى IP المستهدف. إذا كنت ترغب في الحصول على محرك MySQL للرد ، أعتقد أن SELECT 1 الفكرة جيدة- فهي لا تجلب بالفعل أي بيانات من قاعدة البيانات ولكنها تؤكد أن المحرك يتم نسجه والاستجابة له.