SCUMM डैशबोर्ड के साथ MySQL की प्रभावी निगरानी:भाग एक

हमने ClusterControl 1.7.0 की नवीनतम रिलीज़ में MySQL के लिए कई नए डैशबोर्ड जोड़े हैं। - और अपने पिछले ब्लॉग में, हमने आपको दिखाया था कि प्रोमेथियस और क्लस्टरकंट्रोल के साथ अपने प्रॉक्सीएसक्यूएल की निगरानी कैसे करें।

इस ब्लॉग में, हम MySQL अवलोकन डैशबोर्ड को देखेंगे।

इसलिए, हमने नोड्स में मेट्रिक्स एकत्र करना शुरू करने के लिए डैशबोर्ड टैब के तहत एजेंट आधारित निगरानी को सक्षम किया है। ध्यान दें कि एजेंट आधारित निगरानी को सक्षम करते समय, आपके पास "स्क्रैप अंतराल (सेकंड) सेट करने के विकल्प होते हैं। ” और “डेटा प्रतिधारण (दिन) " स्क्रैपिंग अंतराल वह जगह है जहां आप यह सेट करना चाहते हैं कि प्रोमेथियस लक्ष्य से डेटा को कितनी आक्रामक तरीके से एकत्रित करेगा और डेटा प्रतिधारण यह है कि आप अपने डेटा को हटाए जाने से पहले प्रोमेथियस द्वारा एकत्र किए गए डेटा को कितनी देर तक रखना चाहते हैं।

सक्षम होने पर, आप पहचान सकते हैं कि किस क्लस्टर में एजेंट हैं और किस क्लस्टर में एजेंट रहित निगरानी है।

एजेंट रहित दृष्टिकोण की तुलना में, ग्राफ़ में आपके डेटा की ग्रैन्युलैरिटी एजेंटों के साथ अधिक होगी।

MySQL ग्राफ़

ClusterControl 1.7.0 के नवीनतम संस्करण (जिसे आप मुफ्त में डाउनलोड कर सकते हैं - ClusterControl समुदाय) में निम्नलिखित MySQL डैशबोर्ड हैं, जिसके लिए आप अपने MySQL सर्वर के लिए जानकारी एकत्र कर सकते हैं। ये हैं MySQL ओवरव्यू, MySQL InnoDB मेट्रिक्स, MySQL परफॉर्मेंस स्कीमा, और MySQL प्रतिकृति।

हम MySQL ओवरव्यू डैशबोर्ड में उपलब्ध ग्राफ़ को विस्तार से कवर करेंगे।

MySQL अवलोकन डैशबोर्ड

इस डैशबोर्ड में आपके MySQL नोड के स्वास्थ्य के संबंध में सामान्य महत्वपूर्ण चर या जानकारी है। इस डैशबोर्ड पर निहित ग्राफ़ डैशबोर्ड को देखने पर चुने गए नोड के लिए विशिष्ट हैं जैसा कि नीचे देखा गया है:

इसमें 26 रेखांकन होते हैं, लेकिन समस्याओं का निदान करते समय आपको इन सभी की आवश्यकता नहीं हो सकती है। हालाँकि, ये ग्राफ़ आपके MySQL सर्वर के लिए समग्र मेट्रिक्स का एक महत्वपूर्ण प्रतिनिधित्व प्रदान करते हैं। आइए बुनियादी बातों पर ध्यान दें, क्योंकि ये शायद सबसे आम चीजें हैं जिन्हें एक डीबीए नियमित रूप से देखता है।

MySQL के अपटाइम, क्वेरी प्रति सेकंड और बफर पूल जानकारी के साथ ऊपर दिखाए गए पहले चार ग्राफ़ सबसे बुनियादी पॉइंटर्स हैं जिनकी हमें आवश्यकता हो सकती है। ऊपर प्रदर्शित ग्राफ़ से, यहाँ उनके प्रतिनिधित्व हैं:

• MySQL कनेक्शन
  यह वह जगह है जहां आप एक विशिष्ट अवधि में अब तक आवंटित अपने कुल क्लाइंट कनेक्शन की जांच करना चाहते हैं।
• MySQL क्लाइंट थ्रेड गतिविधि
  कई बार आपका MySQL सर्वर बहुत व्यस्त हो सकता है। उदाहरण के लिए, यह किसी विशिष्ट समय पर ट्रैफ़िक में वृद्धि प्राप्त करने की उम्मीद कर सकता है, और आप अपनी चल रही थ्रेड गतिविधि की निगरानी करना चाहते हैं। यह ग्राफ देखना वाकई महत्वपूर्ण है। कई बार आपकी क्वेरी का प्रदर्शन दक्षिण में जा सकता है, उदाहरण के लिए, एक बड़े अपडेट के कारण अन्य थ्रेड्स को लॉक प्राप्त करने की प्रतीक्षा करनी पड़ती है। इससे आपके चल रहे थ्रेड्स की संख्या में वृद्धि होगी। कैश छूट दर की गणना Threads_created/Connections के रूप में की जाती है।
• MySQL प्रश्न
  ये एक विशिष्ट अवधि में चलने वाली क्वेरी हैं। एक थ्रेड कई प्रश्नों से बना एक लेन-देन हो सकता है और यह देखने के लिए एक अच्छा ग्राफ हो सकता है।
• MySQL थ्रेड कैशे
  यह ग्राफ़ थ्रेड_कैश_साइज़ मान, कैश किए गए थ्रेड (पुन:उपयोग किए जाने वाले थ्रेड), और बनाए गए थ्रेड (नए थ्रेड) दिखाता है। आप इस तरह के उदाहरणों के लिए इस ग्राफ पर जांच कर सकते हैं जैसे आने वाले कनेक्शनों की एक बड़ी संख्या को देखते हुए आपको अपने पढ़ने वाले प्रश्नों को ट्यून करने की आवश्यकता होती है और आपके द्वारा बनाए गए धागे तेजी से बढ़ते हैं। उदाहरण के लिए, यदि आपका Threads_running / thread_cache_size> 2 तो अपने thread_cache_size को बढ़ाने से आपके सर्वर के प्रदर्शन को बढ़ावा मिल सकता है। ध्यान दें कि धागे का निर्माण और विनाश महंगा है। हालाँकि, MySQL के हाल के संस्करणों (>=5.6.8) में, इस चर में डिफ़ॉल्ट रूप से ऑटोसाइज़िंग है जिसे आप इसे अछूता मान सकते हैं।

अगले चार ग्राफ़ हैं MySQL Temporary Objects, MySQL Select Types, MySQL Sorts, और MySQL Slow querys। ये ग्राफ़ एक-दूसरे से संबंधित हैं, खासकर यदि आप लंबे समय से चल रहे प्रश्नों और बड़ी क्वेरी का निदान कर रहे हैं जिन्हें अनुकूलन की आवश्यकता है।

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

हमारे पास अगले ग्राफ़ में नेटवर्क गतिविधि, टेबल लॉक और अंतर्निहित आंतरिक मेमोरी है जो MySQL MySQL की गतिविधि के दौरान उपभोग कर रहा है।

• MySQL निरस्त कनेक्शन
  निरस्त कनेक्शनों की संख्या इस ग्राफ़ पर प्रदर्शित होगी। यह निरस्त किए गए क्लाइंट को कवर करता है जैसे कि जहां नेटवर्क अचानक बंद हो गया था या जहां इंटरनेट कनेक्शन डाउन या बाधित हो गया था। यह क्लाइंट से कनेक्शन स्थापित करने पर निरस्त कनेक्शन या गलत पासवर्ड या खराब पैकेट जैसे प्रयासों को भी रिकॉर्ड करता है।
• MySQL टेबल लॉक्स
  टेबल के लिए रुझान जो तत्काल प्रदान किए गए टेबल लॉक के लिए अनुरोध करते हैं और उन तालिकाओं के लिए जो तुरंत प्राप्त नहीं किए गए लॉक के लिए अनुरोध करते हैं। उदाहरण के लिए, यदि आपके पास MyISAM टेबल पर टेबल-लेवल लॉक हैं और एक ही टेबल के आने वाले अनुरोध हैं, तो इन्हें तुरंत नहीं दिया जा सकता है।
• MySQL नेटवर्क ट्रैफ़िक
  यह ग्राफ MySQL सर्वर में इनबाउंड और आउटबाउंड नेटवर्क गतिविधि के रुझान को दर्शाता है। "इनबाउंड" MySQL सर्वर द्वारा प्राप्त किया गया डेटा है जबकि "आउटबाउंड" MySQL सर्वर से सर्वर द्वारा भेजा या स्थानांतरित किया गया डेटा है। यह ग्राफ़ यह जांचने के लिए सबसे अच्छा है कि क्या आप अपने नेटवर्क ट्रैफ़िक की निगरानी करना चाहते हैं, खासकर जब आपका ट्रैफ़िक का निदान करते समय मध्यम है लेकिन आप सोच रहे हैं कि इसमें बहुत अधिक आउटबाउंड स्थानांतरित डेटा क्यों है, उदाहरण के लिए, BLOB डेटा।
• MySQL नेटवर्क उपयोग प्रति घंटा
  नेटवर्क ट्रैफ़िक के समान जो प्राप्त और भेजे गए डेटा को दिखाता है। ध्यान दें कि यह 'प्रति घंटे' पर आधारित है और 'अंतिम दिन' के साथ लेबल किया गया है, जो आपके द्वारा तिथि चयनकर्ता में चुने गए समय की अवधि का पालन नहीं करेगा।
• MySQL आंतरिक मेमोरी अवलोकन
  यह ग्राफ़ एक अनुभवी MySQL DBA से परिचित है। बार ग्राफ़ में इनमें से प्रत्येक किंवदंती बहुत महत्वपूर्ण है, खासकर यदि आप अपने मेमोरी उपयोग, अपने बफर पूल उपयोग, या अपने अनुकूली हैश इंडेक्स आकार की निगरानी करना चाहते हैं।

निम्नलिखित रेखांकन उन काउंटरों को दिखाते हैं जिन पर एक डीबीए भरोसा कर सकता है जैसे कि उदाहरण के लिए आँकड़ों की जाँच करना, चयन के लिए आँकड़े, सम्मिलित करना, अद्यतन करना, निष्पादित की गई मास्टर स्थिति की संख्या, निष्पादित किए गए SHOW VARIABLES की संख्या, जाँच करना। यदि आपके पास टेबल स्कैन या टेबल को पढ़ने में गलत प्रश्न हैं, जो रीड_ * काउंटर आदि को देखकर इंडेक्स का उपयोग नहीं कर रहे हैं।

• शीर्ष कमान काउंटर (प्रति घंटा)
  ये वे ग्राफ़ हैं जिनकी आपको जाँच करनी होगी जब भी आप अपने इंसर्ट, डिलीट, अपडेट, निष्पादित कमांड जैसे कि प्रोसेसलिस्ट इकट्ठा करना, स्लेव स्टेटस, शो स्टेटस (MySQL सर्वर के स्वास्थ्य आँकड़े) के आँकड़े देखना चाहते हैं। ), और बहुत सारे। यह एक अच्छी जगह है यदि आप यह जांचना चाहते हैं कि किस प्रकार के MySQL कमांड काउंटर सबसे ऊपर हैं और यदि कुछ प्रदर्शन ट्यूनिंग या क्वेरी ऑप्टिमाइज़ेशन की आवश्यकता है। यह आपको यह पहचानने की अनुमति भी दे सकता है कि कौन से कमांड की आवश्यकता नहीं होने पर आक्रामक तरीके से चल रहे हैं।
• MySQL हैंडलर्स
  अक्सर, एक डीबीए इन हैंडलर्स पर जाता है और जांचता है कि आपके MySQL सर्वर में क्वेश्चन कैसा प्रदर्शन कर रहे हैं। मूल रूप से, यह ग्राफ MySQL के हैंडलर एपीआई से काउंटरों को कवर करता है। MySQL में स्टोरेज API के लिए DBA के लिए सबसे आम हैंडलर काउंटर हैं Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd, और Handler_read_rnd_next। जाँच करने के लिए बहुत सारे MySQL हैंडलर हैं। आप उनके बारे में यहां दस्तावेज़ीकरण में पढ़ सकते हैं।
• MySQL ट्रांजेक्शन हैंडलर्स
  यदि आपका MySQL सर्वर XA लेनदेन, SAVEPOINT, ROLLBACK TO SAVEPOINT स्टेटमेंट का उपयोग कर रहा है। फिर यह ग्राफ देखने के लिए एक अच्छा संदर्भ है। आप इस ग्राफ का उपयोग अपने सर्वर के सभी आंतरिक कमिटों की निगरानी के लिए भी कर सकते हैं। ध्यान दें कि हैंडलर_कॉमिट के लिए काउंटर सेलेक्ट स्टेटमेंट के लिए भी इंक्रीमेंट करता है, लेकिन COMMIT स्टेटमेंट पर कॉल के दौरान बाइनरी लॉग में जाने वाले इन्सर्ट/अपडेट/डिलीट स्टेटमेंट्स से अलग है।

अगला ग्राफ प्रक्रिया राज्यों और उनके प्रति घंटा उपयोग के बारे में रुझान दिखाएगा। बार ग्राफ़ लेजेंड में यहाँ बहुत सारे प्रमुख बिंदु हैं जो एक DBA जाँच करेगा। डिस्क स्थान समस्याओं का सामना करना, कनेक्शन समस्याएं और देखें कि आपका कनेक्शन पूल अपेक्षित रूप से काम कर रहा है या नहीं, उच्च डिस्क I/O, नेटवर्क समस्याएं, आदि।

• प्रक्रिया राज्य/शीर्ष प्रक्रिया राज्य प्रति घंटा
  यह ग्राफ़ वह जगह है जहां आप प्रक्रिया सूची में चल रहे अपने प्रश्नों की शीर्ष थ्रेड स्थितियों की निगरानी कर सकते हैं। यह ऐसे डीबीए कार्यों के लिए बहुत जानकारीपूर्ण और सहायक है जहां आप यहां किसी भी बकाया स्थिति की जांच कर सकते हैं जिसके लिए समाधान की आवश्यकता है। उदाहरण के लिए, शुरुआती टेबल राज्य बहुत अधिक है और इसका न्यूनतम मूल्य लगभग अधिकतम मूल्य के करीब है। यह संकेत दे सकता है कि आपको table_open_cache को समायोजित करने की आवश्यकता है। यदि आंकड़े उच्च है और आप अपने सर्वर की धीमी गति को देख रहे हैं, यह संकेत दे सकता है कि आपका सर्वर डिस्क-बाउंड है और आपको अपने बफर पूल को बढ़ाने पर विचार करने की आवश्यकता हो सकती है। यदि आपके पास tmp तालिका बनाने . की संख्या अधिक है तो आपको अपने धीमे लॉग की जांच करनी पड़ सकती है और आपत्तिजनक प्रश्नों को अनुकूलित करना पड़ सकता है। आप यहां MySQL थ्रेड स्टेट्स की पूरी सूची के लिए मैनुअल चेकआउट कर सकते हैं।

अगला ग्राफ़ जिसकी हम जाँच कर रहे हैं, वह क्वेरी कैश, MySQL टेबल डेफिनिशन कैश, कितनी बार MySQL सिस्टम फ़ाइलों को खोलता है, के बारे में है।

• MySQL क्वेरी कैश मेमोरी/गतिविधि
  ये ग्राफ एक दूसरे से संबंधित हैं। यदि आपके पास query_cache_size <> 0 और query_cache_type <> 0 है, तो यह ग्राफ मदद का हो सकता है। हालाँकि, MySQL के नए संस्करणों में, क्वेरी कैश को पदावनत के रूप में चिह्नित किया गया है क्योंकि MySQL क्वेरी कैश को प्रदर्शन समस्याओं का कारण माना जाता है। हो सकता है कि आपको भविष्य में इसकी आवश्यकता न हो। MySQL 8.0 के नवीनतम संस्करण में भारी सुधार हुआ है; यह प्रदर्शन को बढ़ाता है क्योंकि यह मेमोरी बफ़र्स में कैशे जानकारी को संभालने के लिए कई रणनीतियों के साथ आता है।
• MySQL फ़ाइल खोलना
  यह ग्राफ़ MySQL सर्वर के अपटाइम के बाद से खोली गई फ़ाइलों के लिए रुझान दिखाता है लेकिन इसमें सॉकेट या पाइप जैसी फ़ाइलें शामिल नहीं हैं। इसमें वे फ़ाइलें भी शामिल नहीं हैं जो स्टोरेज इंजन द्वारा खोली गई हैं क्योंकि उनका अपना काउंटर है जो कि Innodb_num_open_files है।
• MySQL फ़ाइलें खोलें
  यह ग्राफ़ वह जगह है जहाँ आप अपनी वर्तमान में खुली हुई InnoDB फ़ाइलों, वर्तमान MySQL खुली फ़ाइलों और अपने open_files_limit चर की जाँच करना चाहते हैं।
• MySQL टेबल ओपन कैशे स्टेटस
  यदि आपके यहां बहुत कम table_open_cache सेट है, तो यह ग्राफ़ आपको उन तालिकाओं के बारे में बताएगा जो कैश (नई खुली हुई तालिकाएँ) में विफल हो जाती हैं या अतिप्रवाह के कारण छूट जाती हैं। यदि आप अपनी प्रक्रिया सूची में एक उच्च संख्या या बहुत अधिक "ओपनिंग टेबल" स्थिति का सामना करते हैं, तो यह ग्राफ़ इसे निर्धारित करने के लिए आपके संदर्भ के रूप में कार्य करेगा। यह आपको बताएगा कि क्या आपके table_open_cache वेरिएबल को बढ़ाने की आवश्यकता है।
• MySQL ओपन टेबल्स
  MySQL टेबल ओपन कैशे स्टेटस से संबंधित, यह ग्राफ कुछ अवसरों में उपयोगी होता है जैसे आप यह पहचानना चाहते हैं कि क्या आपके टेबल_ओपेन_कैश को बढ़ाने या इसे कम करने की आवश्यकता है यदि आप ओपन टेबल या ओपन_टेबल्स स्टेटस वेरिएबल की उच्च वृद्धि देखते हैं। . ध्यान दें कि table_open_cache बड़ी मात्रा में मेमोरी स्पेस ले सकता है इसलिए आपको इसे विशेष रूप से प्रोडक्शन सिस्टम में सावधानी से सेट करना होगा।
• MySQL तालिका परिभाषा कैश
  यदि आप अपने Open_table_definitions और Opened_table_definitions स्थिति चरों की संख्या की जाँच करना चाहते हैं, तो यह ग्राफ़ वही है जो आपको चाहिए। MySQL के नए संस्करणों (>=5.6.8) के लिए, आपको इस चर के मान को बदलने और डिफ़ॉल्ट मान का उपयोग करने की आवश्यकता नहीं हो सकती है क्योंकि इसमें ऑटोरेसाइज़िंग सुविधा है।

निष्कर्ष

ClusterControl 1.7.0 के नवीनतम संस्करण में SCUMM अतिरिक्त कई प्रमुख DBA कार्यों के लिए महत्वपूर्ण नए लाभ प्रदान करता है। नए ग्राफ़ उन समस्याओं के कारणों को आसानी से इंगित करने में मदद कर सकते हैं जिनसे DBA या sysadmins को आमतौर पर निपटना होगा और उचित समाधान तेज़ी से खोजने में मदद करेंगे।

हमें SCUMM के साथ ClusterControl 1.7.0 का उपयोग करने के बारे में आपके अनुभव और विचारों को सुनना अच्छा लगेगा (जिसे आप मुफ्त में डाउनलोड कर सकते हैं - ClusterControl समुदाय)।

इस ब्लॉग के भाग 2 में, मैं SCUMM डैशबोर्ड के साथ MySQL प्रतिकृति की प्रभावी निगरानी पर चर्चा करूँगा।