बड़ी संख्या में निगरानी वस्तुओं के साथ Zabbix के लिए MySQL में विभाजन का उपयोग करना

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

Zabbix के साथ MySQL डेटाबेस का उपयोग करने में समस्याएं

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

यह एक ज्ञात समस्या है, लगभग हर कोई जो ज़ाबिक्स पर निगरानी के बड़े संस्करणों के साथ काम करता है, एक ही बात का सामना करना पड़ा। कई समाधान भी थे: उदाहरण के लिए, MySQL को PostgreSQL या यहां तक ​​कि इलास्टिसर्च के साथ बदलना, लेकिन सबसे सरल और सबसे सिद्ध समाधान था कि विभाजन के टेबल को स्विच करना जो MySQL डेटाबेस में मीट्रिक डेटा को स्टोर करता है। हमने इस तरह से जाने का फैसला किया।

विभाजन के लिए नियमित MySQL तालिकाओं से पलायन

ज़ैबिक्स को अच्छी तरह से प्रलेखित किया गया है और तालिकाएं जहां यह मैट्रिक्स स्टोर करता है। ये सारणी हैं: history , जहां फ्लोट मान संग्रहीत किए जाते हैं, history_str , जहां छोटे स्ट्रिंग मान संग्रहीत किए जाते हैं, history_text , जहां लंबे पाठ मान संग्रहीत किए जाते हैं, और history_uint , जहां पूर्णांक मान संग्रहीत होते हैं। एक trends टेबल भी है जो परिवर्तनों की गतिशीलता को संग्रहीत करता है, लेकिन हमने इसे नहीं छूने का फैसला किया, क्योंकि इसका आकार छोटा है और थोड़ी देर बाद हम इसे वापस कर देंगे।

सामान्य तौर पर, संसाधित करने के लिए किन तालिकाओं की आवश्यकता होती है, यह स्पष्ट था। हमने प्रत्येक सप्ताह के लिए विभाजन करने का फैसला किया, आखिरी के अपवाद के साथ, महीने की संख्या के आधार पर, अर्थात। प्रति माह चार विभाजन: पहली से 7 वीं तक, 8 वीं से 14 वीं तक, 15 वीं से 21 वीं और 22 वीं से पहली (अगले महीने) तक। कठिनाई यह थी कि ज़ैबिक्स सर्वर को बाधित किए बिना और मेट्रिक्स को इकट्ठा किए बिना हमें "फ़्लाय पर विभाजन" में आवश्यक तालिकाओं को चालू करना था।

अजीब तरह से पर्याप्त है, इन तालिकाओं की बहुत संरचना इसमें हमारी सहायता के लिए आई थी। उदाहरण के लिए, history तालिका में निम्नलिखित संरचना है:

 `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT '0', `value` double(16,4) NOT NULL DEFAULT '0.0000', `ns` int(11) NOT NULL DEFAULT '0', 

जब

 KEY `history_1` (`itemid`,`clock`) 

जैसा कि आप देख सकते हैं, प्रत्येक मीट्रिक अंततः एक तालिका में दर्ज की जाती है जिसमें हमारे लिए आइटम और घड़ी फ़ील्ड दो बहुत महत्वपूर्ण और सुविधाजनक हैं। इस प्रकार, हम अच्छी तरह से एक अस्थायी तालिका बना सकते हैं, उदाहरण के लिए, history_tmp नाम के साथ, इसके लिए एक history_tmp सेट करें और फिर history टेबल से सभी डेटा को वहां स्थानांतरित करें, और फिर history तालिका का नाम बदलकर history_old , और history_tmp तालिका को history में जोड़ें, फिर डेटा जोड़ें जिसे हमने history_old से history और history_old को हटा history_old । आप इसे पूरी तरह से सुरक्षित रूप से कर सकते हैं, हम कुछ भी नहीं खो सकते हैं, क्योंकि ऊपर दिखाए गए आइटम और घड़ी फ़ील्ड एक विशिष्ट समय के लिए लिंक मीट्रिक प्रदान करते हैं, और किसी प्रकार के सीरियल नंबर के लिए नहीं।

संक्रमण प्रक्रिया ही

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

इसलिए, कुछ भी बंद या बंद न करें। मुख्य बात यह है कि MySQL सर्वर पर पर्याप्त मात्रा में मुफ्त डिस्क स्थान होना चाहिए, अर्थात। उपरोक्त तालिका के प्रत्येक history , history_text , history_str , history_uint , के लिए, कम से कम, पर्याप्त जगह है ताकि प्रत्यय "_tmp" के साथ एक तालिका बनाई जा सके, यह देखते हुए कि यह मूल तालिका के समान राशि होगी।

हम उपरोक्त तालिका में से प्रत्येक के लिए कई बार सब कुछ का वर्णन नहीं करेंगे और उनमें से केवल एक के उदाहरण के साथ सब कुछ पर विचार करें - history तालिका।

इसलिए, history तालिका की संरचना के आधार पर एक खाली history_tmp तालिका बनाएं।

 CREATE TABLE `history_tmp` LIKE `history`; 

हम अपनी आवश्यकता के विभाजन बनाते हैं। उदाहरण के लिए, इसे एक महीने के लिए करते हैं। प्रत्येक विभाजन को विभाजन नियम के आधार पर बनाया जाता है, जो घड़ी क्षेत्र के मूल्य के आधार पर होता है, जिसकी हम टाइमस्टैम्प से तुलना करते हैं:

 ALTER TABLE `history_tmp` PARTITION BY RANGE( clock ) ( PARTITION p20190201 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-01 00:00:00")), PARTITION p20190207 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-07 00:00:00")), PARTITION p20190214 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-14 00:00:00")), PARTITION p20190221 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-21 00:00:00")), PARTITION p20190301 VALUES LESS THAN (UNIX_TIMESTAMP("2019-03-01 00:00:00")) ); 

यह ऑपरेटर हमारे द्वारा बनाए गए history_tmp तालिका में विभाजन जोड़ता है। आइए हम स्पष्ट करें कि वह डेटा जिसके लिए क्लॉक फ़ील्ड का मान "2019-02-01 00:00:00" से कम है, विभाजन p20190201 में गिर जाएगा, फिर वह डेटा जिसके लिए घड़ी के क्षेत्र का मूल्य "2019-02-01 00:00:00" से अधिक है, लेकिन कम "2019-02-07 00:00:00" पार्टी p20190207 और इतने पर गिर जाएगी।

महत्वपूर्ण नोट: और क्या होगा यदि हमारे पास विभाजन तालिका में डेटा है जहां घड़ी क्षेत्र का मूल्य "2019-03-01 00:00:00" से अधिक या बराबर है? चूंकि इस डेटा के लिए कोई उपयुक्त विभाजन नहीं है, वे टेबल में नहीं गिरेंगे और खो जाएंगे। इसलिए, इस तरह के डेटा हानि (जिसके बारे में नीचे) से बचने के लिए, आपको समय पर ढंग से अतिरिक्त विभाजन बनाने के लिए नहीं भूलना चाहिए।

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

 INSERT IGNORE INTO `history_tmp` SELECT * FROM history; 

प्रारंभिक भरने के दौरान IGNORE कीवर्ड की आवश्यकता नहीं है, क्योंकि तालिका में अभी भी कोई डेटा नहीं है, हालांकि, डेटा जोड़ते समय आपको इसकी आवश्यकता होगी। इसके अलावा, यह उपयोगी हो सकता है यदि आपको इस प्रक्रिया को बाधित करना और डेटा में भरने के दौरान फिर से शुरू करना है।

तो, कुछ समय बाद (शायद कुछ घंटे भी), पहला डेटा अपलोड हो चुका है। जैसा कि आप समझते हैं, अब history_tmp तालिका में history तालिका से सभी डेटा शामिल नहीं हैं, लेकिन क्वेरी शुरू होने के समय केवल उसमें मौजूद डेटा। यहां, वास्तव में, आपके पास एक विकल्प है: या तो हम एक और पास बनाते हैं (यदि भरने की प्रक्रिया लंबे समय तक चली), या हम तुरंत ऊपर वर्णित तालिकाओं का नाम बदलने के लिए आगे बढ़ते हैं। पहला, चलो दूसरा पास लेते हैं। सबसे पहले, हमें history_tmp में अंतिम सम्मिलित रिकॉर्ड के समय को समझने की आवश्यकता है:

 SELECT max(clock) FROM history_tmp; 

मान लीजिए कि आपने प्राप्त किया: 1551045645 । अब हम डेटा भरने के दूसरे पास में प्राप्त मूल्य का उपयोग करते हैं:

 INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645; 

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

अंत में, हम फिर से history_tmp में रिकॉर्ड के अंतिम प्रविष्टि के समय को प्राप्त करने का कार्य करते हैं:

 SELECT max(clock) FROM history_tmp; 

मान लीजिए कि आपको 1551085645 मिले । इस मान को रखें - हमें फिर से भरने के लिए इसकी आवश्यकता होगी।

और अब, वास्तव में, जब history_tmp में प्राथमिक डेटा भरना history_tmp , तो हम तालिकाओं का नाम बदलने के लिए आगे बढ़ते हैं:

 BEGIN; RENAME TABLE history TO history_old; RENAME TABLE history_tmp TO history; COMMIT; 

हमने इस ब्लॉक को एक लेन-देन के रूप में डिज़ाइन किया है ताकि डेटा को एक गैर-तालिका में डालने से बचा जा सके, क्योंकि पहले RENAME के ​​बाद जब तक दूसरा RENAME निष्पादित नहीं होता है, history तालिका मौजूद नहीं होगी। लेकिन भले ही history तालिका में RENAME संचालन के बीच कुछ डेटा आता है और तालिका स्वयं अभी तक मौजूद नहीं है (नाम बदलने के कारण), हमें बहुत कम प्रविष्टि त्रुटियां मिलेंगी जिनकी उपेक्षा की जा सकती है (हमारे पास निगरानी है, बैंक नहीं)।

अब हमारे पास विभाजन के साथ एक नया history तालिका है, लेकिन इसमें पर्याप्त डेटा नहीं है जो history_tmp टेबल में डेटा डालने के अंतिम पास के दौरान प्राप्त हुआ था। लेकिन हमारे पास history_old तालिका में यह डेटा है और अब हम इसे वहां से साझा करते हैं। इसके लिए, हमें पहले से सहेजे गए मूल्य 1551085645 की आवश्यकता होगी। हमने इस मूल्य को क्यों बचाया और वर्तमान history तालिका से पहले से ही अधिकतम भरण समय का उपयोग नहीं किया? क्योंकि नया डेटा पहले से ही इसमें आ रहा है और हमें गलत समय मिलेगा। इसलिए, हम डेटा को मापते हैं:

 INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645; 

इस ऑपरेशन के अंत के बाद, हमारे पास नए, विभाजन किए गए history तालिका में सभी डेटा है जो पुराने एक में था, साथ ही तालिका के नाम बदलने के बाद आए डेटा। history_old तालिका की अब आवश्यकता नहीं है। आप इसे तुरंत हटा सकते हैं, या इसे हटाने से पहले आप इसकी बैकअप प्रति (यदि आपको व्यामोह है) कर सकते हैं।

ऊपर वर्णित पूरी प्रक्रिया को history_str , history_text और history_uint लिए दोहराया जाना चाहिए।

Zabbix सर्वर सेटिंग्स में क्या तय किया जाना चाहिए

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

समूह में "परिवर्तन की गतिशीलता" पर एक ही पृष्ठ पर ध्यान दें। यह सिर्फ trends टेबल है, जिसे हमने वापस करने का वादा किया था। यदि यह आपके लिए बहुत बड़ा हो गया है और इसे विभाजित करने की आवश्यकता है, तो इस समूह को भी अनचेक करें और फिर इस तालिका को ठीक उसी तरह संसाधित करें जैसा कि यह history* तालिकाओं के लिए किया था।

आगे डेटाबेस रखरखाव

जैसा कि पहले लिखा गया था, विभाजित तालिकाओं पर सामान्य संचालन के लिए, समय में विभाजन बनाने के लिए आवश्यक है। आप इसे इस तरह से कर सकते हैं:

 ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP("2019-03-07 00:00:00"))); 

इसके अलावा, चूंकि हमने विभाजन सारणी बनाई और उन्हें साफ करने के लिए ज़ैबिक्स सर्वर को मना किया, इसलिए पुराने डेटा को हटाना अब हमारी चिंता का विषय है। सौभाग्य से, वहाँ कोई समस्या नहीं हैं। यह विभाजन को हटाने के द्वारा किया जाता है जिसके डेटा की हमें अब कोई आवश्यकता नहीं है।

उदाहरण के लिए:

 ALTER TABLE history DROP PARTITION p20190201; 

दिनांक सीमा वाले विवरणों के विपरीत, DROP विभाजन कुछ सेकंड में किया जाता है, सर्वर को बिल्कुल भी लोड नहीं करता है और MySQL में प्रतिकृति का उपयोग करते समय आसानी से काम करता है।

निष्कर्ष

वर्णित समाधान समय-परीक्षण है। डेटा वॉल्यूम बढ़ रहा है, लेकिन प्रदर्शन में ध्यान देने योग्य मंदी नहीं है।