सामान्य MySQL त्रुटि:"संचार पैकेट पढ़ने में त्रुटि हुई"

ओरेकल के पीछे डीबी इंजन वेबसाइट के अनुसार MySQL दुनिया का दूसरा प्रसिद्ध डेटाबेस है। जो बात MySQL को प्रसिद्ध बनाती है, वह शायद इसलिए है क्योंकि यह एक बहुत तेज़, विश्वसनीय और लचीली डेटाबेस प्रबंधन प्रणाली है। MySQL भी ClusterControl में समर्थित डेटाबेस में से एक है। आप ClusterControl के साथ आसानी से परिनियोजित कर सकते हैं, स्केल कर सकते हैं, मॉनिटर कर सकते हैं और बहुत कुछ कर सकते हैं।

आज हम उनमें से किसी के बारे में बात नहीं करने जा रहे हैं, लेकिन हम MySQL के लिए सामान्य त्रुटियों में से एक और संभावित समस्या निवारण युक्तियों पर चर्चा करेंगे। टिकटों के साथ काम करते समय, बहुत बार जब हम त्रुटि रिपोर्ट या लॉग की जांच करते हैं, तो हमें यह लाइन "संचार पैकेट पढ़ने में त्रुटि मिली" अक्सर दिखाई देती है। हमें लगता है कि अगर हम इस त्रुटि से संबंधित ब्लॉग न केवल अपने ग्राहकों के लिए बल्कि अन्य पाठकों के लिए भी लिखें तो यह फायदेमंद होगा। आइए अब और प्रतीक्षा न करें, यह और अधिक गोता लगाने का समय है!

MySQL क्लाइंट/सर्वर प्रोटोकॉल

सबसे पहले, हमें यह समझने की जरूरत है कि MySQL क्लाइंट और सर्वर के बीच कैसे संचार करता है। क्लाइंट और सर्वर दोनों MySQL प्रोटोकॉल का उपयोग कर रहे हैं जो कनेक्टर्स, MySQL प्रॉक्सी और मास्टर और स्लेव प्रतिकृति सर्वर के बीच संचार द्वारा कार्यान्वित किया जाता है। MySQL प्रोटोकॉल एसएसएल के माध्यम से पारदर्शी एन्क्रिप्शन, पारदर्शी संपीड़न, एक कनेक्शन चरण और साथ ही एक कमांड चरण जैसी सुविधाओं का समर्थन करता है।

पूर्णांक और तार दोनों मूल डेटा प्रकार हैं जिनका उपयोग पूरे MySQL प्रोटोकॉल में किया जाता है। जब भी MySQL क्लाइंट और सर्वर एक-दूसरे से संवाद करना चाहते हैं या डेटा भेजना चाहते हैं, तो यह डेटा को 16MB के अधिकतम आकार के पैकेट में विभाजित करेगा और प्रत्येक चंक के लिए एक पैकेट हेडर भी तैयार करेगा। प्रत्येक पैकेट के अंदर, एक पेलोड होगा, जहां डेटा प्रकार (पूर्णांक/स्ट्रिंग) अपनी भूमिका निभाते हैं।

क्लाइंट द्वारा सर्वर को भेजे जाने वाले लगभग प्रत्येक कमांड के लिए CLIENT_PROTOCOL_41 सक्षम होने पर विचार करते हुए, सर्वर प्रतिक्रिया के रूप में निम्नलिखित में से किसी भी पैकेट का उत्तर देगा:

समस्याओं का निदान कैसे करें

आमतौर पर, दो प्रकार की कनेक्शन समस्याएं होती हैं जो संचार त्रुटियां या निरस्त कनेक्शन हैं। जब भी इनमें से कोई भी कनेक्शन समस्या होती है, तो जानकारी के निम्नलिखित स्रोत समस्या निवारण और विश्लेषण के लिए अच्छा प्रारंभिक बिंदु होते हैं:

• त्रुटि लॉग

• सामान्य क्वेरी लॉग

• Aborted_xxx और Connection_errors_xxx स्थिति चर

• होस्ट कैश

कनेक्शन त्रुटियां और संभावित कारण

किसी भी कनेक्शन त्रुटि होने की स्थिति में और त्रुटियों के आधार पर, यह स्थिति चर में Aborted_clients या Aborted_connects के लिए स्थिति काउंटर में वृद्धि करेगा। जैसा कि MySQL प्रलेखन से लिया गया है, Aborted_clients का अर्थ उन कनेक्शनों की संख्या है जो निरस्त कर दिए गए थे क्योंकि क्लाइंट ठीक से कनेक्शन बंद किए बिना मर गया था। Aborted_connects के लिए, इसका अर्थ है MySQL सर्वर से कनेक्ट करने के असफल प्रयासों की संख्या।

यदि आप --log-चेतावनी विकल्प के साथ MySQL सर्वर प्रारंभ करते हैं, तो संभावना है कि आप अपने त्रुटि लॉग में निम्न संदेश का उदाहरण देखेंगे। जैसा कि आपने देखा, संदेश ने स्पष्ट रूप से कहा कि यह निरस्त कनेक्शन से संबंधित है, इसलिए Aborted_connects स्थिति काउंटर स्थिति चर में वृद्धि की जाएगी:

[चेतावनी] डीबी से 154669 कनेक्शन निरस्त किया गया:'वर्डप्रेस' उपयोगकर्ता:'wpuser' होस्ट:'होस्टनाम' (संचार पैकेट पढ़ने में त्रुटि मिली)

आम तौर पर, निम्न कारणों से असफल कनेक्शन प्रयास हो सकते हैं। जब आपने इस पर ध्यान दिया, तो यह संभवतः इंगित करता है कि एक अनधिकृत व्यक्ति डेटाबेस को भंग करने वाला है और आप इसे जल्द से जल्द देखना चाहेंगे:

• एक क्लाइंट के पास डेटाबेस तक पहुंचने का कोई विशेषाधिकार नहीं है।

• एक गलत क्रेडेंशियल का उपयोग किया गया है।

• एक कनेक्शन पैकेट जिसमें गलत जानकारी है।

• कनेक्ट करने के लिए Connect_timeout की सीमा तक पहुंचने के कारण।

Aborted_clients के लिए स्थिति चर को सर्वर द्वारा बढ़ाया जाएगा यदि क्लाइंट कनेक्ट करने का प्रबंधन करता है लेकिन डिस्कनेक्ट हो जाता है या अनुचित तरीके से समाप्त हो जाता है। इसके अलावा, सर्वर त्रुटि लॉग में एक निरस्त कनेक्शन संदेश भी लॉग करेगा। इस प्रकार की त्रुटि के लिए, आमतौर पर यह निम्न कारणों से हो सकता है:

• क्लाइंट बाहर निकलने से पहले कनेक्शन को ठीक से बंद नहीं करता (mysql_close () को कॉल नहीं करता)।

• क्लाइंट ने wait_timeout या इंटरैक्टिव_timeout सेकंड को पार कर लिया है।

• क्लाइंट प्रोग्राम या एप्लिकेशन डेटा ट्रांसफर के बीच में अचानक समाप्त हो गया।

पहले के कारणों के अलावा, निरस्त कनेक्शन और निरस्त क्लाइंट मुद्दों दोनों के अन्य संभावित कारण निम्न में से किसी से संबंधित हो सकते हैं:

• TCP/IP कॉन्फ़िगरेशन गड़बड़ है।

• max_allowed_packet के लिए वैरिएबल मान बहुत छोटा है।

• क्वेरी के लिए अपर्याप्त मेमोरी आवंटन।

• ईथरनेट, स्विच, केबल आदि जैसे दोषपूर्ण हार्डवेयर।

• थ्रेड लाइब्रेरी की समस्याएं।

• डुप्लेक्स सिंड्रोम मुद्दा जिससे स्थानांतरण बर्स्ट-पॉज़-बर्स्ट-पॉज़ मोड में चला जाता है (यदि आप ईथरनेट प्रोटोकॉल का उपयोग करते हैं) Linux के साथ, आधा और पूर्ण द्वैध दोनों).

MySQL संचार त्रुटियों को कैसे ठीक करें

अब जबकि हमने बहुत सी ऐसी संभावनाएं सीख ली हैं जिनके कारण MySQL कनेक्शन त्रुटि हुई है। हमारे अनुभव के आधार पर, अधिकांश समय यह समस्या फ़ायरवॉल या नेटवर्क समस्याओं से संबंधित होती है। यह कहना भी उचित है कि इस तरह की समस्या का निदान करना आसान नहीं है। फिर भी, इस त्रुटि को हल करने में निम्नलिखित समाधान आपके लिए सहायक हो सकते हैं:

• यदि आपका एप्लिकेशन कनेक्शन बंद करने के लिए Wait_timeout पर निर्भर है, तो यह एप्लिकेशन तर्क को बदलने के लायक है ताकि यह किसी भी ऑपरेशन के अंत में ठीक से बंद।

• सुनिश्चित करना कि max_allowed_packet का मान स्वीकार्य सीमा के भीतर है ताकि क्लाइंट को इससे संबंधित कोई त्रुटि प्राप्त न हो "पैकेट बहुत बड़ा" है।

• कनेक्शन में देरी के मुद्दों के लिए जो DNS के कारण हो सकते हैं, यह जांचने योग्य है कि क्या आपके पास स्किप-नाम है- समाधान सक्षम किया गया।

• यदि आप PHP एप्लिकेशन या किसी अन्य प्रोग्रामिंग का उपयोग कर रहे हैं, तो यह सुनिश्चित करना सबसे अच्छा है कि यह निरस्त न हो कनेक्शन जो आमतौर पर max_execution_time पर सेट होते हैं।

• यदि आपने netstat से TIME_WAIT सूचनाओं का एक बहुत देखा है, तो यह पुष्टि करने योग्य है कि कनेक्शन अच्छी तरह से प्रबंधित हैं आवेदन समाप्त।

• यदि आप Linux का उपयोग कर रहे हैं और संदेह है कि समस्या नेटवर्किंग के कारण है, तो नेटवर्किंग इंटरफ़ेस की जांच करना सबसे अच्छा है ifconfig-a कमांड का उपयोग करके और किसी भी त्रुटि के लिए MySQL सर्वर पर आउटपुट की जांच करें।

• ClusterControl उपयोगकर्ताओं के लिए, आप क्लस्टर से ऑडिट लॉग सक्षम कर सकते हैं -> सुरक्षा -> ऑडिट लॉग। इस सुविधा को सक्षम करके, यह आपको यह पता लगाने में मदद कर सकता है कि कौन सी क्वेरी अपराधी है।

• tcpdump और Wireshark जैसे नेटवर्किंग टूल MySQL के लिए संभावित नेटवर्क मुद्दों, टाइमआउट और संसाधनों के मुद्दों की पहचान करने में उपयोगी हो सकते हैं।

• यह सुनिश्चित करके नियमित रूप से हार्डवेयर की जांच करें कि कहीं इथरनेट, हब, स्विच, केबल के लिए कोई दोषपूर्ण उपकरण तो नहीं है। आदि। यह सुनिश्चित करने के लिए कि कनेक्शन हर समय अच्छा है, दोषपूर्ण उपकरण को बदलने के लायक है।

निष्कर्ष

ऐसे कई कारण हैं जो शायद MySQL कनेक्शन पैकेट समस्याओं का कारण बन सकते हैं। जब भी यह समस्या आती है, तो निश्चित रूप से यह व्यवसाय और दिन-प्रतिदिन के कार्यों को प्रभावित करेगा। भले ही इस प्रकार की समस्या का निदान करना आसान नहीं है और अधिकांश समय यह नेटवर्क या फ़ायरवॉल के कारण होता है, यह उन सभी चरणों को ध्यान में रखने योग्य है जो समस्या को ठीक करने के लिए पहले सुझाए गए हैं। हम वास्तव में आशा करते हैं कि यह ब्लॉग पोस्ट आपकी किसी तरह से मदद कर सकता है, खासकर जब आप इस समस्या का सामना करते हैं।