क्लस्टर नियंत्रण के साथ मारियाडीबी प्रतिकृति की निगरानी के लिए युक्तियाँ

MariaDB प्रतिकृति, MariaDB के लिए सबसे लोकप्रिय उच्च उपलब्धता समाधानों में से एक है और Booking.com और Google जैसी शीर्ष कंपनियों द्वारा व्यापक रूप से उपयोग की जाती है। सॉफ़्टवेयर अपग्रेड, स्कीमा परिवर्तन, टोपोलॉजी परिवर्तन, फ़ेलओवर और पुनर्प्राप्ति जैसे चल रहे रखरखाव पर कुछ ट्रेड-ऑफ के साथ इसे स्थापित करना बहुत आसान है, जो हमेशा मुश्किल रहा है। फिर भी, सही टूलसेट के साथ, आपको टोपोलॉजी को आसानी से संभालने में सक्षम होना चाहिए। इस ब्लॉग पोस्ट में, हम ClusterControl का उपयोग करके प्रभावी ढंग से MariaDB प्रतिकृति की निगरानी के लिए कुछ युक्तियों पर गौर करने जा रहे हैं।

टोपोलॉजी व्यूअर का उपयोग करना

प्रतिकृति सेटअप में कई भूमिकाएं होती हैं। प्रतिकृति सेटअप में एक नोड निम्न हो सकता है:

• मास्टर - प्राथमिक लेखक/पाठक।
• बैकअप मास्टर - अर्ध-सिंक प्रतिकृति के साथ केवल-पढ़ने वाला दास, केवल मास्टर अतिरेक के लिए।
• इंटरमीडिएट मास्टर - एक मास्टर से प्रतिकृति, जबकि अन्य दास इस नोड से दोहराते हैं।
• Binlog सर्वर - बिना डेटा दिए केवल बिनलॉग एकत्रित/संग्रहीत करें।
• गुलाम - एक मास्टर से कॉपी करें, और आमतौर पर केवल-पढ़ने के लिए सेट करें।
• मल्टी-सोर्स स्लेव - मल्टीपल मास्टर्स से रेप्लिकेट करें।

प्रत्येक भूमिका की अपनी जिम्मेदारी और सीमा होती है और डेटाबेस नोड्स के साथ काम करते समय सही टोपोलॉजी को समझना चाहिए। यह एप्लिकेशन के लिए भी सही है, जहां एप्लिकेशन को किसी भी समय केवल मास्टर नोड को लिखना होता है। इस प्रकार, यह एक सिंहावलोकन होना महत्वपूर्ण है कि कौन सा नोड किस भूमिका में है, इसलिए हम अपने डेटाबेस को खराब नहीं करते हैं।

ClusterControl में, टोपोलॉजी व्यूअर आपको प्रतिकृति टोपोलॉजी और उसकी स्थिति का एक सिंहावलोकन दे सकता है, जैसा कि निम्नलिखित स्क्रीनशॉट में दिखाया गया है:

ClusterControl मारियाडीबी प्रतिकृति को समझता है और सही प्रतिकृति डेटा प्रवाह के साथ टोपोलॉजी की कल्पना करने में सक्षम है, जैसा कि दास नोड्स को इंगित किए गए तीरों द्वारा दर्शाया गया है। हम अपने प्रतिकृति सेटअप में आसानी से अंतर कर सकते हैं कि कौन सा नोड मास्टर, दास और लोड बैलेंसर (मैक्सस्केल) है। हरा बॉक्स इंगित करता है कि सभी महत्वपूर्ण सेवाएं नियत भूमिका के साथ अपेक्षित रूप से चल रही हैं।

निम्नलिखित स्क्रीनशॉट पर विचार करें जहां हमारे कई नोड्स में समस्याएं आ रही हैं:

ClusterControl तुरंत आपको बताएगा कि वर्तमान टोपोलॉजी में क्या गलत है। दासों में से एक (लाल बॉक्स) मास्टर से दोहराने के लिए कुछ कनेक्टिविटी समस्या को इंगित करने के लिए "स्लेव आईओ रनिंग" को नहीं के रूप में दिखा रहा है। जबकि पीला बॉक्स दिखाता है कि हमारी मैक्सस्केल सेवा नहीं चल रही है। हम यह भी बता सकते हैं कि MaxScale संस्करण दोनों नोड्स के लिए समान नहीं हैं। आप सीधे गियर आइकन (प्रत्येक बॉक्स के ऊपर दाईं ओर) पर क्लिक करके भी प्रबंधन कार्य कर सकते हैं, जिससे गलत नोड लेने का जोखिम कम हो जाता है।

प्रतिकृति अंतराल

यदि आप डेटा प्रतिकृति संगतता पर भरोसा करते हैं तो यह सबसे महत्वपूर्ण बात है। प्रतिकृति अंतराल तब होता है जब दास मास्टर पर होने वाले अपडेट के साथ नहीं रह सकते। गुलामों के रिले लॉग में अनुपयुक्त परिवर्तन जमा हो जाते हैं और दास पर डेटाबेस का संस्करण मास्टर से तेजी से भिन्न हो जाता है।

ClusterControl में, आप अवलोकन के अंतर्गत प्रतिकृति लैग हिस्टोग्राम पा सकते हैं -> प्रतिकृति लैग जहां ClusterControl लगातार "SLAVE STATUS दिखाएं" आउटपुट से Seconds_Behind_Master मान का नमूना लेता है:

प्रतिकृति अंतराल तब होता है जब I/O थ्रेड या SQL थ्रेड उस पर रखी गई मांगों का सामना नहीं कर सकता है। यदि I / O थ्रेड पीड़ित है, तो इसका मतलब है कि मास्टर और उसके दासों के बीच नेटवर्क कनेक्शन धीमा है या समस्या है। आप नेटवर्क ट्रैफ़िक को संपीड़ित करने के लिए या अपने नेटवर्क व्यवस्थापक को रिपोर्ट करने के लिए गुलाम_संपीड़ित_प्रोटोकॉल को सक्षम करने पर विचार कर सकते हैं।

यदि यह SQL थ्रेड है तो समस्या शायद खराब-अनुकूलित प्रश्नों के कारण है जो दास को लागू करने में बहुत लंबा समय ले रहे हैं। लंबे समय तक चलने वाले लेन-देन या बहुत अधिक I/O गतिविधि हो सकती है। ROW या MIXED प्रतिकृति प्रारूप का उपयोग करते समय स्लेव टेबल पर कोई प्राथमिक कुंजी नहीं होना भी इस थ्रेड पर अंतराल का एक सामान्य कारण है। जांचें कि टेबल के मास्टर और स्लेव संस्करणों में प्राथमिक कुंजी है।

इस ब्लॉग पोस्ट में कुछ और टिप्स और ट्रिक्स शामिल हैं, मल्टी-क्लाउड परिनियोजन में प्रतिकृति अंतराल को कैसे कम करें।

बाइनरी/रिले लॉग आकार

बाइनरी और रिले लॉग डिस्क आकार की निगरानी करना महत्वपूर्ण है क्योंकि यह प्रतिकृति क्लस्टर में प्रत्येक नोड पर काफी मात्रा में भंडारण का उपभोग कर सकता है। आमतौर पर, कोई दिए गए दिनों के बाद बाइनरी लॉग फ़ाइलों को स्वचालित रूप से समाप्त करने के लिए एक्सपायर_लॉग्स_डे सिस्टम वैरिएबल सेट करेगा, उदाहरण के लिए, एक्सपायर_लॉग्स_डे =7। बाइनरी लॉग का आकार पूरी तरह से बनाई गई बाइनरी घटनाओं (आने वाले लेखन) की संख्या पर निर्भर है और बहुत कम है कि हम जानते हैं कि मारियाडीबी द्वारा लॉग की समय सीमा समाप्त होने से पहले यह कितना डिस्क स्थान का उपभोग करेगा। ध्यान रखें कि यदि आप दासों पर log_slave_updates सक्षम करते हैं, तो लॉग का आकार लगभग दोगुना हो जाएगा क्योंकि एक ही सर्वर पर बाइनरी और रिले लॉग दोनों मौजूद हैं।

ClusterControl के लिए, हम नीचे दी गई चेतावनी और महत्वपूर्ण सूचनाएं प्राप्त करने के लिए ClusterControl -> सेटिंग्स -> थ्रेशोल्ड के तहत डिस्क स्थान उपयोग सीमा निर्धारित कर सकते हैं:

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

मॉनिटरिंग डैशबोर्ड सक्षम करें

ClusterControl डेटाबेस नोड्स के नमूने के लिए दो निगरानी विकल्प प्रदान करता है - एजेंट रहित या एजेंट-आधारित। डिफ़ॉल्ट एजेंट रहित होता है जहां नमूना केवल-पुल तंत्र में SSH के माध्यम से होता है। एजेंट-आधारित निगरानी के लिए प्रोमेथियस सर्वर के चलने की आवश्यकता होती है, और सभी मॉनिटर किए गए नोड्स को कम से कम तीन निर्यातकों के साथ कॉन्फ़िगर किया जाना चाहिए:

• प्रक्रिया निर्यातक (पोर्ट 9011)
• नोड/सिस्टम मेट्रिक्स निर्यातक (पोर्ट 9100)
• MySQL/MariaDB निर्यातक (पोर्ट 9104)

एजेंट-आधारित मॉनिटरिंग डैशबोर्ड को सक्षम करने के लिए, क्लस्टरकंट्रोल -> डैशबोर्ड -> एजेंट आधारित मॉनिटरिंग सक्षम करें पर जाना होगा। एक बार सक्षम होने पर, आप हमारे मारियाडीबी प्रतिकृति के लिए कॉन्फ़िगर किए गए डैशबोर्ड का एक सेट देखेंगे जो हमें हमारे प्रतिकृति सेटअप पर एक बेहतर अंतर्दृष्टि प्रदान करता है। निम्न स्क्रीनशॉट दिखाता है कि आप मास्टर नोड के लिए क्या देखेंगे:

सामान्य, कैश और InnoDB मेट्रिक्स जैसे मारियाडीबी मानक निगरानी डैशबोर्ड के अलावा, आप प्रतिकृति डैशबोर्ड के साथ प्रस्तुत किया जाएगा। मास्टर नोड के लिए, हम मास्टर की स्थिति, राइट थ्रूपुट और बिनलॉग निर्माण आवृत्ति के बारे में बहुत सारी उपयोगी जानकारी प्राप्त कर सकते हैं।

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

MariaDB त्रुटि लॉग को समझना

MariaDB त्रुटि लॉग के अंदर अपनी महत्वपूर्ण घटनाओं को लॉग करता है, जो यह समझने के लिए उपयोगी है कि सर्वर के साथ क्या चल रहा था, विशेष रूप से टोपोलॉजी परिवर्तन से पहले, उसके दौरान और बाद में। ClusterControl, ClusterControl -> Logs -> System Logs को प्रत्येक डेटाबेस नोड से खींचकर त्रुटि लॉग का एक केंद्रीकृत दृश्य प्रदान करता है। आप सर्वर से नवीनतम लॉग खींचने के लिए कार्य को ट्रिगर करने के लिए "रिफ्रेश लॉग्स" पर क्लिक करते हैं।

एकत्रित फ़ाइलों को नेविगेशन ट्री संरचना और बेहतर पठनीयता के लिए सिंटैक्स हाइलाइटिंग वाले टेक्स्ट क्षेत्र में दर्शाया जाता है:

उपरोक्त स्क्रीनशॉट से, हम घटनाओं के क्रम को समझ सकते हैं और टोपोलॉजी परिवर्तन घटना के दौरान इस नोड का क्या हुआ। उपरोक्त त्रुटि लॉग की अंतिम 12 पंक्तियों से, दास को एक बार मास्टर से कनेक्ट करने में त्रुटि हुई और अंतिम बाइनरी लॉग फ़ाइल और स्थिति को रोकने से पहले लॉग में दर्ज किया गया। फिर GTID जानकारी के साथ एक नया CHANGE MASTER कमांड निष्पादित किया गया, जैसा कि "पिछला उपयोग_Gtid=No. New Use_Gtid=Slave_Pos" पंक्ति में दिखाया गया है और फिर प्रतिकृति फिर से शुरू होती है जैसा हम चाहते थे।

MariaDB अलर्ट और नोटिफिकेशन

चेतावनी और सूचनाओं के बिना निगरानी अधूरी है। ClusterControl द्वारा उत्पन्न सभी ईवेंट और अलार्म ईमेल या किसी अन्य समर्थित तृतीय-पक्ष टूल पर भेजे जा सकते हैं। ईमेल सूचनाओं के लिए, कोई यह कॉन्फ़िगर कर सकता है कि ईवेंट का प्रकार तुरंत वितरित किया जाएगा, अनदेखा किया जाएगा या पचाया जाएगा (एक दैनिक सारांशित रिपोर्ट):

सभी गंभीर गंभीरता वाली घटनाओं के लिए, सब कुछ "डिलीवर" पर सेट करने की अनुशंसा की जाती है ताकि आपको जल्द से जल्द सूचनाएं मिल सकें। "डाइजेस्ट" को चेतावनी ईवेंट पर सेट करें ताकि आप क्लस्टर स्वास्थ्य और स्थिति से अच्छी तरह अवगत हों।

आप ClusterControl -> इंटीग्रेशन -> तृतीय पक्ष सूचनाओं के अंतर्गत सूचना प्रबंधन सुविधा का उपयोग करके अपने पसंदीदा संचार और संदेश उपकरण को ClusterControl के साथ एकीकृत कर सकते हैं। ClusterControl, PagerDuty, VictorOps, OpsGenie, Slack, Telegram, ServiceNow या किसी भी उपयोगकर्ता द्वारा पंजीकृत वेबहुक पर अलार्म और ईवेंट भेज सकता है।

निम्नलिखित स्क्रीनशॉट से पता चलता है कि सभी महत्वपूर्ण घटनाओं को हमारे मारियाडीबी 10.3 प्रतिकृति क्लस्टर के लिए कॉन्फ़िगर किए गए टेलीग्राम चैनल पर धकेल दिया जाएगा:

ClusterControl चैटबॉट एकीकरण का भी समर्थन करता है, जहां आप सीधे अपने मैसेजिंग टूल से s9s क्लाइंट के माध्यम से नियंत्रक सेवा के साथ बातचीत कर सकते हैं, जैसा कि इस ब्लॉग पोस्ट में दिखाया गया है, CCBot के साथ अपने डेटाबेस को स्वचालित करें:ClusterControl Hubot Integration।

निष्कर्ष

ClusterControl आपके डेटाबेस क्लस्टर के लिए सक्रिय निगरानी उपकरणों का एक पूरा सेट प्रदान करता है। अपने मारियाडीबी प्रतिकृति सेटअप की निगरानी के लिए क्लस्टरकंट्रोल का उपयोग करें क्योंकि सामुदायिक संस्करण में अधिकांश निगरानी सुविधाएं मुफ्त में उपलब्ध हैं। उन्हें याद मत करो!