जब आपको ऐसे डेटाबेस के साथ काम करने की आवश्यकता होती है जिससे आप 100% परिचित नहीं हैं, तो आप उपलब्ध सैकड़ों मीट्रिक से अभिभूत हो सकते हैं। कौन से सबसे महत्वपूर्ण हैं? मुझे क्या निगरानी करनी चाहिए, और क्यों? मेट्रिक्स में कौन से पैटर्न कुछ खतरे की घंटी बजाते हैं? इस ब्लॉग पोस्ट में हम आपको उत्पादन में MySQL या MariaDB चलाते समय नज़र रखने के लिए कुछ सबसे महत्वपूर्ण मेट्रिक्स से परिचित कराने का प्रयास करेंगे।
Com_* स्थिति काउंटर
हम कॉम_* काउंटर से शुरू करेंगे - जो MySQL द्वारा निष्पादित प्रश्नों की संख्या और प्रकार को परिभाषित करते हैं। हम यहां क्वेरी प्रकारों जैसे SELECT, INSERT, UPDATE और कई अन्य के बारे में बात कर रहे हैं। उन पर नज़र रखना काफी महत्वपूर्ण है क्योंकि अचानक स्पाइक्स या अप्रत्याशित बूंदों से संकेत मिलता है कि सिस्टम में कुछ गलत हो गया है।
हमारा सर्व-समावेशी डेटाबेस प्रबंधन सिस्टम ClusterControl आपको "अवलोकन" अनुभाग में सबसे सामान्य क्वेरी प्रकारों से संबंधित यह डेटा दिखाता है।
हैंडलर_* स्थिति काउंटर
मेट्रिक्स की एक श्रेणी जिस पर आपको नज़र रखनी चाहिए वह है हैंडलर_* MySQL में काउंटर। कॉम_* काउंटर आपको बताते हैं कि आपका MySQL इंस्टेंस किस प्रकार के प्रश्नों को निष्पादित कर रहा है, लेकिन एक चयन दूसरे से बिल्कुल अलग हो सकता है - चयन प्राथमिक कुंजी लुकअप हो सकता है, यदि इंडेक्स का उपयोग नहीं किया जा सकता है तो यह एक टेबल स्कैन भी हो सकता है। हैंडलर आपको बताते हैं कि MySQL कैसे संग्रहीत डेटा तक पहुंचता है - यह प्रदर्शन के मुद्दों की जांच करने और यह आकलन करने के लिए बहुत उपयोगी है कि क्वेरी समीक्षा और अतिरिक्त अनुक्रमण में संभावित लाभ है या नहीं।
जैसा कि आप ऊपर दिए गए ग्राफ़ से देख सकते हैं कि ट्रैक करने के लिए कई मीट्रिक हैं (और ClusterControl ग्राफ़ सबसे महत्वपूर्ण हैं) - हम उन सभी को यहां कवर नहीं करेंगे (आप MySQL दस्तावेज़ में विवरण पा सकते हैं) लेकिन हम हाइलाइट करना चाहते हैं सबसे महत्वपूर्ण।
Handler_read_rnd_next - जब भी MySQL एक इंडेक्स लुकअप के बिना एक पंक्ति तक पहुँचता है, क्रमिक क्रम में, यह काउंटर बढ़ा दिया जाएगा। यदि आपके वर्कलोड में हैंडलर_रीड_रंड_नेक्स्ट पूरे ट्रैफ़िक के उच्च प्रतिशत के लिए ज़िम्मेदार है, तो इसका मतलब है कि आपकी टेबल, सबसे अधिक संभावना है, कुछ अतिरिक्त इंडेक्स का उपयोग कर सकती है क्योंकि MySQL बहुत सारे टेबल स्कैन करता है।
हैंडलर_रीड_नेक्स्ट और हैंडलर_रीड_प्रेव - जब भी MySQL एक इंडेक्स स्कैन करता है - वे दो काउंटर अपडेट किए जाते हैं - आगे या पीछे। हैंडलर_रीड_फर्स्ट और हैंडलर_रीड_लास्ट कुछ और प्रकाश डाल सकते हैं कि वे किस तरह के इंडेक्स स्कैन हैं - अगर हम फुल इंडेक्स स्कैन (आगे या पीछे) के बारे में बात कर रहे हैं, तो वे दो काउंटर अपडेट हो जाएंगे।
Handler_read_key - दूसरी ओर, यह काउंटर, यदि इसका मान अधिक है, तो आपको बताता है कि आपकी तालिकाएँ अच्छी तरह से अनुक्रमित हैं क्योंकि कई पंक्तियों को एक अनुक्रमणिका लुकअप के माध्यम से एक्सेस किया गया था।
प्रतिकृति अंतराल
यदि आप MySQL प्रतिकृति के साथ काम कर रहे हैं, तो प्रतिकृति अंतराल एक मीट्रिक है जिसे आप निश्चित रूप से मॉनिटर करना चाहते हैं। प्रतिकृति अंतराल अपरिहार्य है और आपको इससे निपटना होगा, लेकिन इससे निपटने के लिए आपको यह समझने की आवश्यकता है कि ऐसा क्यों होता है। उसके लिए पहला कदम यह जानना होगा कि यह कब दिखाई दिया।
जब भी आप प्रतिकृति अंतराल की एक स्पाइक देखते हैं, तो आप अधिक सुराग प्राप्त करने के लिए अन्य ग्राफ़ की जांच करना चाहेंगे - ऐसा क्यों हुआ है? इसका क्या कारण हो सकता है? कारण अलग हो सकते हैं - लंबे, भारी डीएमएल, कम समय में निष्पादित डीएमएल की संख्या में उल्लेखनीय वृद्धि, सीपीयू या आई/ओ सीमाएं।
InnoDB I/O
I/O से संबंधित निगरानी के लिए कई महत्वपूर्ण मीट्रिक हैं।
ऊपर दिए गए ग्राफ़ में, आप कुछ मेट्रिक्स देख सकते हैं जो आपको बताते हैं कि I/O InnoDB किस प्रकार का करता है - डेटा लिखता है और पढ़ता है, लॉग लिखता है, fsyncs। वे मेट्रिक्स आपको यह तय करने में मदद करेंगे, उदाहरण के लिए, यदि प्रतिकृति अंतराल I/O के स्पाइक के कारण हुआ था या शायद किसी अन्य कारण से। उन मेट्रिक्स पर नज़र रखना और अपनी हार्डवेयर सीमाओं के साथ उनकी तुलना करना भी महत्वपूर्ण है - यदि आप अपने डिस्क की हार्डवेयर सीमा के करीब पहुंच रहे हैं, तो शायद यह आपके डेटाबेस के प्रदर्शन पर अधिक गंभीर प्रभाव डालने से पहले इस पर गौर करने का समय है। डेटाबेस प्रबंधन के लिए डिवाइप्स मार्गदर्शिका जानें कि आपको अपने ओपन सोर्स डेटाबेस को स्वचालित और प्रबंधित करने के लिए क्या जानना आवश्यक है मुफ्त में डाउनलोड करें
गैलेरा मेट्रिक्स - प्रवाह नियंत्रण और कतार
यदि आप गैलेरा क्लस्टर का उपयोग करते हैं (इससे कोई फर्क नहीं पड़ता कि आप किस स्वाद का उपयोग करते हैं), कुछ और मीट्रिक हैं जिन्हें आप बारीकी से मॉनिटर करना चाहते हैं, ये कुछ हद तक एक साथ बंधे हैं। उनमें से सबसे पहले प्रवाह नियंत्रण से संबंधित मीट्रिक हैं।
गैलेरा में प्रवाह नियंत्रण, क्लस्टर को सिंक में रखने का एक साधन है। जब भी कोई नोड रुक जाता है और बाकी क्लस्टर के साथ तालमेल नहीं रख पाता है, तो यह प्रवाह नियंत्रण संदेश भेजना शुरू कर देता है जिससे शेष क्लस्टर नोड्स धीमा हो जाता है। यह इसे पकड़ने की अनुमति देता है। यह क्लस्टर के प्रदर्शन को कम करता है, इसलिए यह बताने में सक्षम होना महत्वपूर्ण है कि किस नोड ने और कब प्रवाह नियंत्रण संदेश भेजना शुरू किया। यह उपयोगकर्ताओं द्वारा अनुभव की गई कुछ मंदी की व्याख्या कर सकता है या आगे की जांच के लिए उपयोग करने के लिए समय विंडो और होस्ट को सीमित कर सकता है।
मॉनिटर करने के लिए मेट्रिक्स का दूसरा सेट गैलेरा में क्यू भेजने और प्राप्त करने से संबंधित है।
गैलेरा नोड्स राइटसेट (लेनदेन) को कैश कर सकते हैं यदि वे उन सभी को तुरंत लागू नहीं कर सकते हैं। यदि आवश्यक हो, तो वे अन्य नोड्स को भेजे जाने वाले राइटसेट को भी कैश कर सकते हैं (यदि किसी दिए गए नोड को एप्लिकेशन से राइट्स प्राप्त होते हैं)। दोनों मामले धीमी गति के लक्षण हैं, जिसके परिणामस्वरूप, प्रवाह नियंत्रण संदेश भेजे जाने की सबसे अधिक संभावना है, और कुछ जांच की आवश्यकता है - ऐसा क्यों, किस नोड पर, किस समय हुआ?
यह, निश्चित रूप से, हिमशैल का सिरा है, जब हम उन सभी मेट्रिक्स पर विचार करते हैं जो MySQL उपलब्ध कराता है - फिर भी, यदि आप सीपीयू जैसे नियमित ओएस/हार्डवेयर मेट्रिक्स के अलावा, यहां कवर किए गए लोगों को देखना शुरू करते हैं, तो आप गलत नहीं हो सकते। , मेमोरी, डिस्क उपयोग और सेवाओं की स्थिति।
