डीबीए के अधिकांश लोग अपने डेटाबेस पर समय-समय पर स्वास्थ्य जांच करते हैं। आमतौर पर, यह दैनिक या साप्ताहिक आधार पर होता। हमने पहले चर्चा की थी कि ऐसे चेक क्यों महत्वपूर्ण हैं और उन्हें क्या शामिल करना चाहिए।
यह सुनिश्चित करने के लिए कि आपके सिस्टम अच्छे आकार में हैं, आपको बहुत सारी जानकारी - होस्ट आँकड़े, MySQL आँकड़े, कार्यभार आँकड़े, बैकअप की स्थिति, डेटाबेस पैकेज, लॉग आदि से गुज़रना होगा। ऐसा डेटा हर उचित निगरानी वाले वातावरण में उपलब्ध होना चाहिए, हालांकि कभी-कभी यह कई स्थानों पर बिखरा हुआ होता है - आपके पास MySQL स्थिति की निगरानी के लिए एक उपकरण हो सकता है, सिस्टम आंकड़े एकत्र करने के लिए एक और उपकरण, शायद स्क्रिप्ट का एक सेट, उदाहरण के लिए, की स्थिति की जांच करने के लिए आपके बैकअप। इससे स्वास्थ्य जांच में जितना समय लगना चाहिए उससे कहीं अधिक समय लगता है - सिस्टम की स्थिति को समझने के लिए DBA को अलग-अलग टुकड़ों को एक साथ रखना होगा।
ClusterControl जैसे एकीकृत टूल का एक फायदा यह है कि सभी बिट्स एक ही स्थान पर (या एक ही एप्लिकेशन में) स्थित होते हैं। इसका अभी भी मतलब यह नहीं है कि वे एक-दूसरे के बगल में स्थित हैं - वे यूआई के विभिन्न वर्गों में स्थित हो सकते हैं और डीबीए को सभी दिलचस्प डेटा तक पहुंचने के लिए यूआई के माध्यम से क्लिक करने में कुछ समय बिताना पड़ सकता है।
ऑपरेशनल रिपोर्ट बनाने के पीछे का पूरा विचार सभी सबसे महत्वपूर्ण डेटा को एक ही दस्तावेज़ में रखना है, जिसकी डेटाबेस की स्थिति को समझने के लिए जल्दी से समीक्षा की जा सकती है।
ऑपरेशनल रिपोर्ट्स मेनू साइड मेन्यू -> ऑपरेशनल रिपोर्ट्स:
. से उपलब्ध हैं
एक बार जब आप वहां जाते हैं, तो आपको पूर्वनिर्धारित शेड्यूल के आधार पर मैन्युअल रूप से या स्वचालित रूप से बनाई गई रिपोर्ट की एक सूची प्रस्तुत की जाएगी:
यदि आप मैन्युअल रूप से एक नई रिपोर्ट बनाना चाहते हैं, तो आप 'बनाएं' विकल्प का उपयोग करेंगे। रिपोर्ट का प्रकार चुनें, क्लस्टर नाम (प्रति-क्लस्टर रिपोर्ट के लिए), ईमेल प्राप्तकर्ता (वैकल्पिक - यदि आप चाहते हैं कि रिपोर्ट आपको वितरित की जाए), और आपने बहुत कुछ किया है:
रिपोर्ट को नियमित आधार पर बनाने के लिए भी शेड्यूल किया जा सकता है:
इस समय, 5 प्रकार की रिपोर्टें उपलब्ध हैं:
- उपलब्धता रिपोर्ट - सभी क्लस्टर।
- बैकअप रिपोर्ट - सभी क्लस्टर।
- स्कीमा परिवर्तन रिपोर्ट - केवल MySQL/MariaDB-आधारित क्लस्टर।
- दैनिक सिस्टम रिपोर्ट - प्रति क्लस्टर।
- पैकेज अपग्रेड रिपोर्ट - प्रति क्लस्टर।
उपलब्धता रिपोर्ट
उपलब्धता रिपोर्ट अच्छी तरह से उपलब्धता पर केंद्रित है। इसमें तीन खंड शामिल हैं। पहला, उपलब्धता सारांश:
आप अपने डेटाबेस के उपलब्धता आंकड़ों, क्लस्टर प्रकार, कुल अपटाइम और डाउनटाइम, क्लस्टर की वर्तमान स्थिति और उस स्थिति को पिछली बार कब बदला, के बारे में जानकारी देख सकते हैं।
एक अन्य खंड प्रत्येक क्लस्टर के लिए उपलब्धता के बारे में अधिक विवरण देता है। नीचे दिया गया स्क्रीनशॉट केवल एक डेटाबेस क्लस्टर दिखाता है:
हम देख सकते हैं कि एक नोड ने कब स्थिति बदली और संक्रमण क्या था। यह जांचने के लिए एक अच्छी जगह है कि क्या क्लस्टर के साथ हाल ही में कोई समस्या हुई है। इसी तरह का डेटा इस रिपोर्ट के तीसरे खंड में दिखाया गया है, जहां आप क्लस्टर स्थिति में बदलाव के इतिहास को देख सकते हैं।
बैकअप रिपोर्ट
दूसरे प्रकार की रिपोर्ट सभी समूहों का एक कवरिंग बैकअप है। इसमें दो खंड होते हैं - बैकअप सारांश और बैकअप विवरण, जहां पूर्व मूल रूप से आपको एक संक्षिप्त सारांश देता है कि अंतिम बैकअप कब बनाया गया था, यदि यह सफलतापूर्वक या विफल हुआ, बैकअप सत्यापन स्थिति, सफलता दर और अवधारण अवधि:
ClusterControl बैकअप नीति के उदाहरण भी प्रदान करता है यदि यह किसी भी मॉनिटर किए गए डेटाबेस क्लस्टर को बिना किसी शेड्यूल किए बैकअप या विलंबित स्लेव कॉन्फ़िगर किए हुए पाता है। आगे बैकअप विवरण हैं:
आप निर्दिष्ट अंतराल के भीतर उनके राज्य, प्रकार और आकार के साथ क्लस्टर पर निष्पादित बैकअप की सूची भी देख सकते हैं। यह उतना ही करीब है जितना आप निश्चित हो सकते हैं कि पूर्ण पुनर्प्राप्ति परीक्षण चलाए बिना बैकअप सही ढंग से काम करता है। हम निश्चित रूप से अनुशंसा करते हैं कि इस तरह के परीक्षण समय-समय पर किए जाएं। अच्छी खबर यह है कि क्लस्टरकंट्रोल बैकअप -> रिस्टोर बैकअप के तहत एक स्टैंडअलोन होस्ट पर MySQL-आधारित बहाली और सत्यापन का समर्थन करता है।
दैनिक सिस्टम रिपोर्ट
इस प्रकार की रिपोर्ट में किसी विशेष क्लस्टर के बारे में विस्तृत जानकारी होती है। यह क्लस्टर से संबंधित विभिन्न अलर्ट के सारांश के साथ शुरू होता है:
अगला भाग उन नोड्स की स्थिति के बारे में है जो क्लस्टर का हिस्सा हैं:
आपके पास क्लस्टर में नोड्स, उनके प्रकार, भूमिका (मास्टर या स्लेव), नोड की स्थिति, अपटाइम और OS की एक सूची है।
रिपोर्ट का एक अन्य भाग बैकअप सारांश है, जैसा कि हमने ऊपर चर्चा की थी। अगला क्लस्टर में शीर्ष प्रश्नों का सारांश प्रस्तुत करता है:
अंत में, हम एक "नोड स्थिति अवलोकन" देखते हैं जिसमें आपको प्रत्येक नोड के लिए OS और MySQL मेट्रिक्स से संबंधित ग्राफ़ प्रस्तुत किए जाएंगे।
जैसा कि आप देख सकते हैं, हमारे पास होस्ट पर लोड के सभी पहलुओं को कवर करने वाले ग्राफ हैं - सीपीयू, मेमोरी, नेटवर्क, डिस्क, सीपीयू लोड और डिस्क फ्री। यह अंदाजा लगाने के लिए काफी है कि हाल ही में कुछ अजीब हुआ या नहीं। आप MySQL वर्कलोड के बारे में कुछ विवरण भी देख सकते हैं - कितने प्रश्न निष्पादित किए गए, किस प्रकार की क्वेरी, डेटा कैसे एक्सेस किया गया (किस हैंडलर के माध्यम से)? दूसरी ओर, यह MySQL की ओर से अधिकांश मुद्दों को चुनने के लिए पर्याप्त होना चाहिए। आप जो देखना चाहते हैं वह सभी स्पाइक्स और डिप्स हैं जो आपने अतीत में नहीं देखे हैं। हो सकता है कि मिश्रण में एक नई क्वेरी जोड़ी गई हो और, परिणामस्वरूप, handler_read_rnd_next आसमान छू गया? हो सकता है कि सीपीयू लोड में वृद्धि हुई हो और अधिक संख्या में कनेक्शन MySQL पर बढ़े हुए लोड की ओर इशारा कर रहे हों, लेकिन किसी तरह के विवाद के लिए भी। जांच के लिए एक अप्रत्याशित पैटर्न अच्छा हो सकता है, ताकि आप जान सकें कि क्या हो रहा है।
पैकेज अपग्रेड रिपोर्ट
यह रिपोर्ट मॉनिटर किए गए होस्ट पर रिपॉजिटरी मैनेजर द्वारा अपग्रेड के लिए उपलब्ध पैकेजों का सारांश देती है। एक सटीक रिपोर्टिंग के लिए, सुनिश्चित करें कि आप हर होस्ट पर हमेशा स्थिर और विश्वसनीय रिपॉजिटरी का उपयोग करते हैं। कुछ अवांछनीय अवसरों में, मॉनिटर किए गए होस्ट को अपग्रेड के बाद एक पुराने रिपॉजिटरी के साथ कॉन्फ़िगर किया जा सकता है (उदाहरण के लिए, प्रत्येक मारियाडीबी प्रमुख संस्करण अलग-अलग रिपॉजिटरी का उपयोग करता है), अधूरा आंतरिक रिपॉजिटरी (जैसे, अपस्ट्रीम से आंशिक रूप से प्रतिबिंबित) या ब्लीडिंग एज रिपॉजिटरी (आमतौर पर अस्थिर के लिए) रात्रिकालीन पैकेज बनाएं)।
पहला खंड अपग्रेड सारांश है:
यह अपग्रेड के लिए उपलब्ध पैकेजों की कुल संख्या के साथ-साथ क्लस्टर के लिए संबंधित प्रबंधित सेवा जैसे लोड बैलेंसर, वर्चुअल आईपी एड्रेस और मध्यस्थ को सारांशित करता है। इसके बाद, ClusterControl प्रत्येक होस्ट के लिए पैकेज प्रकार द्वारा समूहीकृत एक विस्तृत पैकेज सूची प्रदान करता है:
यह रिपोर्ट उपलब्ध संस्करण प्रदान करती है और हमारी रखरखाव विंडो को कुशलतापूर्वक योजना बनाने में हमारी सहायता कर सकती है। सुरक्षा और डेटाबेस पैकेज जैसे महत्वपूर्ण अपग्रेड के लिए, हम इसे गैर-महत्वपूर्ण अपग्रेड पर प्राथमिकता दे सकते हैं, जिसे अन्य कम प्राथमिकता वाले रखरखाव विंडो के साथ समेकित किया जा सकता है।
स्कीमा परिवर्तन रिपोर्ट
यह रिपोर्ट तालिका संरचना में चयनित MySQL/MariaDB डेटाबेस परिवर्तनों की तुलना करती है जो दो अलग-अलग उत्पन्न रिपोर्ट के बीच हुआ था। MySQL/MariaDB पुराने संस्करणों में, DDL ऑपरेशन एक गैर-परमाणु ऑपरेशन (पूर्व 8.0) है और इसके लिए पूर्ण तालिका प्रतिलिपि की आवश्यकता होती है (अधिकांश संचालन के लिए पूर्व 5.6) - जब तक यह पूरा नहीं हो जाता तब तक अन्य लेनदेन को अवरुद्ध करना। एक बार जब आपकी टेबल को महत्वपूर्ण मात्रा में डेटा मिल जाता है तो स्कीमा परिवर्तन एक बड़ा दर्द बन सकता है और विशेष रूप से क्लस्टर्ड सेटअप में सावधानीपूर्वक योजना बनाई जानी चाहिए। बहु-स्तरीय विकास वातावरण में, हमने ऐसे कई मामले देखे हैं जहां डेवलपर्स चुपचाप तालिका संरचना को संशोधित करते हैं, जिसके परिणामस्वरूप क्वेरी प्रदर्शन पर महत्वपूर्ण प्रभाव पड़ता है।
ClusterControl के लिए एक सटीक रिपोर्ट तैयार करने के लिए, संबंधित क्लस्टर के लिए CMON कॉन्फ़िगरेशन फ़ाइल के अंदर विशेष विकल्प कॉन्फ़िगर किए जाने चाहिए:
- schema_change_detection_address - यह निर्धारित करने के लिए कि क्या स्कीमा बदल गया है, SHOW TABLES/SHOW CREATE TABLE का उपयोग करके चेक निष्पादित किए जाएंगे। चेक निर्दिष्ट पते पर निष्पादित किए जाते हैं और प्रारूप HOSTNAME:PORT के होते हैं। स्कीमा_चेंज_डिटेक्शन_डेटाबेस भी सेट किया जाना चाहिए। एक बदली हुई तालिका का एक अंतर बनाया गया है (diff का उपयोग करके)।
- स्कीमा_चेंज_डिटेक्शन_डेटाबेस - स्कीमा परिवर्तनों की निगरानी के लिए डेटाबेस की अल्पविराम से अलग की गई सूची। अगर खाली है, तो कोई जांच नहीं की जाती है।
इस उदाहरण में, हम अपने मारियाडीबी क्लस्टर पर क्लस्टर आईडी 27 के साथ डेटाबेस "myapp" और "sbtest" के लिए स्कीमा परिवर्तनों की निगरानी करना चाहेंगे। डेटाबेस नोड्स में से एक को schema_change_detection_address के मान के रूप में चुनें। . MySQL प्रतिकृति के लिए, यह मास्टर होस्ट या डेटाबेस रखने वाला कोई भी दास होस्ट होना चाहिए (यदि आंशिक प्रतिकृति सक्रिय है)। फिर, /etc/cmon.d/cmon_27.cnf के अंदर, निम्नलिखित दो पंक्तियाँ जोड़ें:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestपरिवर्तन लोड करने के लिए CMON सेवा को पुनरारंभ करें:
$ systemctl restart cmonपहली और सबसे महत्वपूर्ण रिपोर्ट के लिए, ClusterControl केवल मेटाडेटा संग्रह का परिणाम देता है, जैसा कि नीचे दिया गया है:
आधार रेखा के रूप में पहली रिपोर्ट के साथ, बाद की रिपोर्टें वह आउटपुट लौटाएंगी जिसकी हम अपेक्षा कर रहे हैं:
ध्यान दें कि रिपोर्ट में केवल नई तालिकाएँ या परिवर्तित तालिकाएँ मुद्रित की जाती हैं। पहली रिपोर्ट केवल बाद के दौर में तुलना के लिए मेटाडेटा संग्रह के लिए है, इस प्रकार अंतर देखने के लिए हमें इसे कम से कम दो बार चलाना होगा।
इस रिपोर्ट के साथ, अब आप डेटाबेस संरचना के पदचिह्न एकत्र कर सकते हैं और समझ सकते हैं कि आपका डेटाबेस समय के साथ कैसे विकसित हुआ है।
अंतिम विचार
ऑपरेशनल रिपोर्ट आपके डेटाबेस इन्फ्रास्ट्रक्चर की स्थिति को समझने का एक व्यापक तरीका है। यह परिचालन या प्रबंधकीय कर्मचारियों दोनों के लिए बनाया गया है, और आपके डेटाबेस संचालन का विश्लेषण करने में बहुत उपयोगी हो सकता है। रिपोर्ट्स को अपने स्थान पर तैयार किया जा सकता है या ईमेल के माध्यम से आपको डिलीवर किया जा सकता है, जो रिपोर्टिंग साइलो होने पर चीजों को आसानी से आसान बना देता है।
रिपोर्ट में आप जो कुछ भी शामिल करना चाहते हैं, उसमें क्या कमी है और क्या नहीं है, इस बारे में हमें आपका फ़ीडबैक सुनना अच्छा लगेगा।
