MySQL के BLACKHOLE इंजन का उद्देश्य क्या है?




(2)

मान लीजिए कि आपके पास दो कंप्यूटर हैं, प्रत्येक एक MySQL सर्वर चला रहा है। एक कंप्यूटर प्राथमिक डेटाबेस को होस्ट करता है, और दूसरा कंप्यूटर एक प्रतिकृति दास को होस्ट करता है जिसे आप बैकअप के रूप में उपयोग करते हैं।

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

लेकिन चूंकि प्रतिकृति फ़िल्टर केवल दास सर्वर पर लागू होते हैं , इसलिए मास्टर सर्वर पर निष्पादित सभी कथनों के बिनलॉग को अभी भी नेटवर्क पर प्रसारित करने की आवश्यकता है। यहां बैंडविड्थ बर्बाद हो रहा है; मास्टर सर्वर लेन-देन के लिए बिनलॉग भेज रहा है कि दास उन्हें प्राप्त करने पर बस फेंकने वाला है। क्या हम बेहतर कर सकते हैं, और अनावश्यक बैंडविड्थ उपयोग से बच सकते हैं?

हां, हम कर सकते हैं और वह स्थान जहां BLACKHOLE इंजन आता है। उसी कंप्यूटर पर जिस पर मास्टर सर्वर चल रहा है, हम एक दूसरा, डमी mysqld प्रक्रिया चलाते हैं, यह एक BLACKHOLE डेटाबेस को होस्ट करता है। हम मास्टर प्रक्रिया के बिनलॉग से दोहराने के लिए इस डमी प्रक्रिया को कॉन्फ़िगर करते हैं, असली गुलाम के रूप में समान प्रतिकृति विकल्पों के साथ और स्वयं के एक बिनलॉग का उत्पादन करने के लिए। डमी प्रक्रिया के बिनलॉग में अब केवल उन बयानों को शामिल किया गया है जो वास्तविक दास की जरूरत है, और इसने बिनलोग के अवांछित बयानों को छानने से परे कोई वास्तविक काम नहीं किया है (क्योंकि यह ब्लैकहोल इंजन का उपयोग कर रहा है)। अंत में, हम असली दास को डमी प्रक्रिया के बिनलॉग से दोहराने के लिए कॉन्फ़िगर करते हैं, बल्कि मूल मास्टर प्रक्रिया के बिनलॉग से। हमने अब मास्टर और दास सर्वरों की मेजबानी करने वाले दो कंप्यूटरों के बीच अनावश्यक नेटवर्क ट्रैफ़िक को समाप्त कर दिया है।

इस सेटअप को इस अनुच्छेद और चित्र द्वारा BLACKHOLE के ड्राफ्ट से वर्णित और सचित्र (बहुत अधिक) बताया जा रहा है:

मान लीजिए कि आपके एप्लिकेशन को दास-पक्ष फ़िल्टरिंग नियमों की आवश्यकता है, लेकिन दास को सभी बाइनरी लॉग डेटा को स्थानांतरित करने से बहुत अधिक ट्रैफ़िक होता है। ऐसे मामले में, मास्टर होस्ट को "डमी" गुलाम प्रक्रिया पर सेट करना संभव है, जिसका डिफ़ॉल्ट भंडारण इंजन ब्लैकहोल है, जिसे निम्नानुसार दर्शाया गया है:

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

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

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

आप कुछ ऐसा क्यों बचाएंगे जिसे आप बाद में पुनः प्राप्त नहीं कर सकते हैं? क्या बात है?


यह एक प्रतिकृति वातावरण में उपयोगी है जहां सभी एसक्यूएल बयान सभी नोड्स पर चलाए जाते हैं, लेकिन आप केवल कुछ नोड्स चाहते हैं जो वास्तव में परिणाम को संग्रहीत करते हैं। यह प्रलेखन में दिया गया एक उपयोग मामला है: http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

प्रलेखन में दिए गए अन्य उपयोगों में शामिल हैं:

  • डंप फ़ाइल सिंटैक्स का सत्यापन।
  • बाइनरी लॉगिंग से ओवरहेड का मापन, द्विआधारी लॉगिंग के साथ और बिना सक्षम किए गए BLACKHOLE का उपयोग करके प्रदर्शन की तुलना करके।
  • ब्लैकहोल अनिवार्य रूप से एक "नो-ऑप" स्टोरेज इंजन है, इसलिए इसका उपयोग स्टोरेज इंजन से संबंधित नहीं होने वाले प्रदर्शन बाधाओं को खोजने के लिए किया जा सकता है।




blackhole