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

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

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

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

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

नियमित MySQL तालिकाओं से विभाजित तालिकाओं में माइग्रेट करना

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

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

अजीब बात यह है कि तालिकाओं की संरचना ही इसमें हमारी सहायता के लिए आई। उदाहरण के लिए, तालिका 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, और फिर तालिका का नाम बदलें history в history_old, और तालिका history_tmp в history, जिसके बाद हम वह डेटा भरेंगे जो हमने अभी तक नहीं भरा है history_old в history और हटाएं history_old. आप यह पूरी तरह से सुरक्षित रूप से कर सकते हैं, हम कुछ भी नहीं खोएंगे, क्योंकि ऊपर निर्दिष्ट फ़ील्ड आइटमआईडी и घड़ी किसी क्रमिक संख्या के बजाय, किसी विशिष्ट मीट्रिक और विशिष्ट समय के बीच एक लिंक प्रदान करें।

संक्रमण प्रक्रिया स्वयं

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

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

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

तो, चलिए एक खाली टेबल बनाते हैं history_tmp तालिका संरचना के आधार पर history.

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 अब काम पूरा हो गया, चलिए तालिकाओं का नाम बदलना शुरू करते हैं:

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

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

अब हमारे पास एक नई तालिका है 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;

दिनांक सीमा वाले DELETE FROM स्टेटमेंट के विपरीत, DROP PARTITION को पूरा होने में कुछ सेकंड लगते हैं और यह पूरी तरह से अनलोड हो जाता है। सेवक और MySQL रेप्लिकेशन का उपयोग करते समय भी यह उतनी ही सहजता से काम करता है।