डेटाबेस स्कीमा कुछ ऐसा नहीं है जो पत्थर में लिखा हो। यह किसी दिए गए एप्लिकेशन के लिए डिज़ाइन किया गया है, लेकिन तब आवश्यकताएं बदल सकती हैं और आमतौर पर बदल जाती हैं। एप्लिकेशन में नए मॉड्यूल और कार्यात्मकताएं जोड़ी जाती हैं, अधिक डेटा एकत्र किया जाता है, कोड और डेटा मॉडल रिफैक्टरिंग की जाती है। जिससे इन परिवर्तनों के अनुकूल होने के लिए डेटाबेस स्कीमा को संशोधित करने की आवश्यकता है; कॉलम जोड़ना या संशोधित करना, नई टेबल बनाना या बड़े को विभाजित करना। जैसे-जैसे डेवलपर डेटा के साथ इंटरैक्ट करने के लिए उपयोगकर्ताओं के लिए नए तरीके जोड़ते हैं, क्वेरी में भी बदलाव होता है - नई क्वेरीज़ नए, अधिक कुशल इंडेक्स का उपयोग कर सकती हैं, इसलिए हम एप्लिकेशन को सर्वश्रेष्ठ डेटाबेस प्रदर्शन प्रदान करने के लिए उन्हें बनाने के लिए जल्दी करते हैं।
तो, हम स्कीमा परिवर्तन के लिए सर्वोत्तम तरीके से कैसे संपर्क कर सकते हैं? कौन से उपकरण उपयोगी हैं? उत्पादन डेटाबेस पर प्रभाव को कम कैसे करें? स्कीमा डिज़ाइन के साथ सबसे आम समस्याएँ क्या हैं? आपकी स्कीमा के शीर्ष पर बने रहने के लिए कौन से टूल आपकी मदद कर सकते हैं? इस ब्लॉग पोस्ट में हम आपको एक संक्षिप्त अवलोकन देंगे कि MySQL और MariaDB में स्कीमा परिवर्तन कैसे करें। कृपया ध्यान दें कि हम गैलेरा क्लस्टर के संदर्भ में स्कीमा परिवर्तनों पर चर्चा नहीं करेंगे। हमने पिछले ब्लॉग पोस्ट में पहले ही कुल ऑर्डर अलगाव, रोलिंग स्कीमा अपग्रेड और आरएसयू से प्रभाव को कम करने के सुझावों पर चर्चा की थी। हम स्कीमा डिज़ाइन से संबंधित युक्तियों और युक्तियों पर भी चर्चा करेंगे और कैसे ClusterControl सभी स्कीमा परिवर्तनों के शीर्ष पर बने रहने में आपकी सहायता कर सकता है।
स्कीमा परिवर्तन के प्रकार
सबसे पहली बात। विषय में खुदाई करने से पहले, हमें यह समझना होगा कि MySQL और MariaDB स्कीमा परिवर्तन कैसे करते हैं। आप देखिए, एक स्कीमा परिवर्तन दूसरे स्कीमा परिवर्तन के बराबर नहीं है।
आपने ऑनलाइन परिवर्तन, तत्काल परिवर्तन या इन-प्लेस परिवर्तन के बारे में सुना होगा। यह सब उस कार्य का परिणाम है जो उत्पादन डेटाबेस पर स्कीमा परिवर्तनों के प्रभाव को कम करने के लिए जारी है। ऐतिहासिक रूप से, लगभग सभी स्कीमा परिवर्तन अवरुद्ध हो रहे थे। यदि आपने एक स्कीमा परिवर्तन निष्पादित किया है, तो सभी क्वेरीज़ ढेर होने लगेंगी, ALTER के पूरा होने की प्रतीक्षा में। जाहिर है, इसने उत्पादन परिनियोजन के लिए गंभीर मुद्दे पेश किए। ज़रूर, लोग तुरंत समाधान तलाशने लगते हैं, और हम बाद में इस ब्लॉग में उनकी चर्चा करेंगे, क्योंकि आज भी वे प्रासंगिक हैं। लेकिन साथ ही, अन्य प्रश्नों पर अधिक प्रभाव डाले बिना डीडीएल (डेटा परिभाषा भाषा) चलाने के लिए MySQL की क्षमता में सुधार करने के लिए काम शुरू हुआ।
तत्काल परिवर्तन
कभी-कभी टेबलस्पेस में किसी भी डेटा को छूने की आवश्यकता नहीं होती है, क्योंकि केवल मेटाडेटा को बदलना पड़ता है। यहां एक उदाहरण इंडेक्स को छोड़ना या कॉलम का नाम बदलना होगा। इस तरह के ऑपरेशन त्वरित और कुशल हैं। आमतौर पर, उनका प्रभाव सीमित होता है। हालांकि यह बिना किसी प्रभाव के नहीं है। कभी-कभी मेटाडेटा में परिवर्तन करने में कुछ सेकंड लगते हैं और इस तरह के परिवर्तन के लिए मेटाडेटा लॉक प्राप्त करने की आवश्यकता होती है। यह लॉक प्रति-टेबल के आधार पर है, और यह अन्य कार्यों को अवरुद्ध कर सकता है जिन्हें इस टेबल पर निष्पादित किया जाना है। आप इसे प्रक्रिया सूची में "टेबल मेटाडेटा लॉक की प्रतीक्षा कर रहे हैं" प्रविष्टियों के रूप में देखेंगे।
इस तरह के बदलाव का एक उदाहरण तत्काल ADD COLUMN हो सकता है, जिसे MariaDB 10.3 और MySQL 8.0 में पेश किया गया है। यह बिना किसी देरी के इस काफी लोकप्रिय स्कीमा परिवर्तन को निष्पादित करने की संभावना देता है। मारियाडीबी और ओरेकल दोनों ने टेनसेंट गेम से कोड शामिल करने का फैसला किया जो तालिका में तुरंत एक नया कॉलम जोड़ने की अनुमति देता है। यह कुछ विशिष्ट परिस्थितियों में है; कॉलम को अंतिम के रूप में जोड़ा जाना है, तालिका में पूर्ण टेक्स्ट इंडेक्स मौजूद नहीं हो सकते हैं, पंक्ति प्रारूप को संपीड़ित नहीं किया जा सकता है - आप मारियाडीबी दस्तावेज़ीकरण में तत्काल ऐड कॉलम कैसे काम करता है, इस बारे में अधिक जानकारी प्राप्त कर सकते हैं। MySQL के लिए, केवल आधिकारिक संदर्भ mysqlserverteam.com ब्लॉग पर पाया जा सकता है, हालांकि आधिकारिक दस्तावेज़ीकरण को अपडेट करने के लिए एक बग मौजूद है।
स्थानीय परिवर्तन
कुछ परिवर्तनों के लिए टेबलस्पेस में डेटा के संशोधन की आवश्यकता होती है। इस तरह के संशोधन डेटा पर ही किए जा सकते हैं, और नई डेटा संरचना के साथ एक अस्थायी तालिका बनाने की कोई आवश्यकता नहीं है। इस तरह के परिवर्तन, आम तौर पर (हालांकि हमेशा नहीं) तालिका को छूने वाले अन्य प्रश्नों को निष्पादित करने की अनुमति देते हैं, जबकि स्कीमा परिवर्तन चल रहा है। इस तरह के ऑपरेशन का एक उदाहरण तालिका में एक नया माध्यमिक सूचकांक जोड़ना है। इस ऑपरेशन को करने में कुछ समय लगेगा लेकिन डीएमएल को निष्पादित करने की अनुमति देगा।
टेबल रीबिल्ड
यदि जगह में बदलाव करना संभव नहीं है, तो InnoDB नई, वांछित संरचना के साथ एक अस्थायी तालिका बनाएगा। यह तब मौजूदा डेटा को नई तालिका में कॉपी करेगा। यह ऑपरेशन सबसे महंगा है और डीएमएल को लॉक करने की संभावना है (हालांकि यह हमेशा नहीं होता है)। नतीजतन, इस तरह के स्कीमा परिवर्तन बाहरी उपकरणों की मदद के बिना, स्टैंडअलोन सर्वर पर एक बड़ी टेबल पर निष्पादित करने के लिए बहुत मुश्किल है - आम तौर पर आप अपने डेटाबेस को लंबे समय तक या घंटों तक लॉक नहीं कर सकते हैं। इस तरह के ऑपरेशन का एक उदाहरण कॉलम डेटा प्रकार को बदलना होगा, उदाहरण के लिए INT से VARCHAR।
स्कीमा परिवर्तन और प्रतिकृति
ठीक है, तो हम जानते हैं कि InnoDB ऑनलाइन स्कीमा परिवर्तन की अनुमति देता है और यदि हम MySQL दस्तावेज़ीकरण से परामर्श करते हैं, तो हम देखेंगे कि अधिकांश स्कीमा परिवर्तन (कम से कम सबसे आम लोगों में से) ऑनलाइन किए जा सकते हैं। ऑनलाइन स्कीमा परिवर्तन उपकरण जैसे gh-ost बनाने के लिए विकास के घंटे समर्पित करने के पीछे क्या कारण है? हम स्वीकार कर सकते हैं कि पीटी-ऑनलाइन-स्कीमा-परिवर्तन पुराने, बुरे समय का अवशेष है लेकिन जीएच-ओस्ट एक नया सॉफ्टवेयर है।
उत्तर जटिल है। दो मुख्य मुद्दे हैं।
शुरुआत के लिए, एक बार जब आप एक स्कीमा परिवर्तन शुरू करते हैं, तो आपका उस पर नियंत्रण नहीं होता है। आप इसे रोक सकते हैं लेकिन आप इसे रोक नहीं सकते। आप इसका गला घोंट नहीं सकते। जैसा कि आप कल्पना कर सकते हैं, तालिका का पुनर्निर्माण एक महंगा ऑपरेशन है और भले ही InnoDB DML को निष्पादित करने की अनुमति देता है, DDL से अतिरिक्त I/O कार्यभार अन्य सभी प्रश्नों को प्रभावित करता है और इस प्रभाव को उस स्तर तक सीमित करने का कोई तरीका नहीं है जो स्वीकार्य है आवेदन।
दूसरा, और भी गंभीर मुद्दा, प्रतिकृति है। यदि आप एक गैर-अवरुद्ध ऑपरेशन निष्पादित करते हैं, जिसके लिए एक टेबल पुनर्निर्माण की आवश्यकता होती है, तो यह वास्तव में डीएमएल को लॉक नहीं करेगा लेकिन यह केवल मास्टर पर ही सच है। मान लें कि इस तरह के डीडीएल को पूरा होने में 30 मिनट लगते हैं - ALTER गति हार्डवेयर पर निर्भर करती है लेकिन 20GB आकार की सीमा के टेबल पर इस तरह के निष्पादन समय को देखना काफी सामान्य है। फिर इसे सभी दासों के लिए दोहराया जाता है और, जिस क्षण से उन दासों पर डीडीएल शुरू होता है, प्रतिकृति इसके पूरा होने की प्रतीक्षा करेगी। इससे कोई फर्क नहीं पड़ता कि आप MySQL या MariaDB का उपयोग करते हैं, या यदि आपके पास बहु-थ्रेडेड प्रतिकृति है। दास पिछड़ जाएंगे - वे शेष बिनलॉग घटनाओं को लागू करने से पहले डीडीएल को पूरा करने के लिए उन 30 मिनट की प्रतीक्षा करेंगे। जैसा कि आप कल्पना कर सकते हैं, 30 मिनट का अंतराल (कभी-कभी 30 सेकंड भी स्वीकार्य नहीं होगा - यह सब आवेदन पर निर्भर करता है) कुछ ऐसा है जो स्केल-आउट के लिए उन दासों का उपयोग करना असंभव बनाता है। बेशक, वर्कअराउंड हैं - आप प्रतिकृति श्रृंखला के नीचे से ऊपर तक स्कीमा परिवर्तन कर सकते हैं लेकिन यह आपके विकल्पों को गंभीरता से सीमित करता है। विशेष रूप से यदि आप पंक्ति-आधारित प्रतिकृति का उपयोग करते हैं, तो आप केवल इस तरह से संगत स्कीमा परिवर्तन निष्पादित कर सकते हैं। पंक्ति-आधारित प्रतिकृति की सीमाओं के कुछ उदाहरण; आप किसी भी कॉलम को ड्रॉप नहीं कर सकते जो आखिरी नहीं है, आप कॉलम को आखिरी के अलावा किसी अन्य स्थिति में नहीं जोड़ सकते हैं। आप कॉलम प्रकार भी नहीं बदल सकते (उदाहरण के लिए, INT -> VARCHAR)।
जैसा कि आप देख सकते हैं, प्रतिकृति जटिलता को जोड़ती है कि आप स्कीमा परिवर्तन कैसे कर सकते हैं। संचालन जो स्टैंडअलोन होस्ट पर गैर-अवरुद्ध होते हैं, दासों पर निष्पादित होने पर अवरुद्ध हो जाते हैं। आइए कुछ तरीकों पर एक नज़र डालते हैं जिनका उपयोग आप स्कीमा परिवर्तनों के प्रभाव को कम करने के लिए कर सकते हैं।
ऑनलाइन स्कीमा परिवर्तन उपकरण
जैसा कि हमने पहले उल्लेख किया है, ऐसे उपकरण हैं, जिनका उद्देश्य स्कीमा परिवर्तन करना है। सबसे लोकप्रिय हैं पीटी-ऑनलाइन-स्कीमा-चेंज, जो पेरकोना द्वारा बनाया गया है और जीएच-ओस्ट, गीथहब द्वारा बनाया गया है। ब्लॉग पोस्ट की एक श्रृंखला में हमने उनकी तुलना की और चर्चा की कि स्कीमा परिवर्तन करने के लिए gh-ost का उपयोग कैसे किया जा सकता है और आप किसी मौजूदा माइग्रेशन को कैसे थ्रॉटल और पुन:कॉन्फ़िगर कर सकते हैं। यहां हम विवरण में नहीं जाएंगे, लेकिन फिर भी हम उन उपकरणों के उपयोग के कुछ सबसे महत्वपूर्ण पहलुओं का उल्लेख करना चाहेंगे। शुरुआत के लिए, pt-osc या gh-ost के माध्यम से निष्पादित एक स्कीमा परिवर्तन सभी डेटाबेस नोड्स पर एक ही बार में होगा। परिवर्तन कब लागू किया जाएगा, इसके संदर्भ में कोई देरी नहीं है। यह उन उपकरणों का उपयोग स्कीमा परिवर्तनों के लिए भी संभव बनाता है जो पंक्ति-आधारित प्रतिकृति के साथ असंगत हैं। टेबल पर वे टूल ट्रैक परिवर्तन कैसे ट्रैक करते हैं, इसके बारे में सटीक तंत्र अलग है (पीटी-ओएससी बनाम बिनलॉग पार्सिंग इन जीएच-ओस्ट में ट्रिगर) लेकिन मुख्य विचार वही है - वांछित स्कीमा के साथ एक नई तालिका बनाई गई है और मौजूदा डेटा है पुरानी तालिका से कॉपी किया गया। इस बीच, डीएमएल को ट्रैक किया जाता है (एक तरह से या दूसरा) और नई तालिका पर लागू किया जाता है। एक बार सभी डेटा माइग्रेट हो जाने के बाद, तालिकाओं का नाम बदल दिया जाता है और नई तालिका पुराने को बदल देती है। यह परमाणु संचालन है इसलिए यह अनुप्रयोग के लिए दृश्यमान नहीं है। दोनों उपकरणों में लोड को थ्रॉटल करने और संचालन को रोकने का विकल्प होता है। Gh-ost सभी गतिविधि को रोक सकता है, pt-osc केवल पुरानी और नई तालिका के बीच डेटा की प्रतिलिपि बनाने की प्रक्रिया को रोक सकता है - ट्रिगर सक्रिय रहेंगे और वे डेटा को डुप्लिकेट करना जारी रखेंगे, जो कुछ ओवरहेड जोड़ता है। नाम बदलने की तालिका के कारण, दोनों उपकरणों में विदेशी कुंजियों के संबंध में कुछ सीमाएँ हैं - gh-ost द्वारा समर्थित नहीं, आंशिक रूप से pt-osc द्वारा या तो नियमित ALTER के माध्यम से समर्थित, जो प्रतिकृति अंतराल का कारण हो सकता है (यदि चाइल्ड टेबल बड़ी है तो संभव नहीं है) या द्वारा नई तालिका का नाम बदलने से पहले पुरानी तालिका को छोड़ना - यह खतरनाक है क्योंकि रोलबैक का कोई तरीका नहीं है, अगर किसी कारण से, डेटा को नई तालिका में सही तरीके से कॉपी नहीं किया गया था। ट्रिगर का समर्थन करना भी मुश्किल होता है।
वे MySQL 5.7 में gh-ost, pt-osc में समर्थित नहीं हैं और नए में मौजूदा ट्रिगर वाली तालिकाओं के लिए सीमित समर्थन है। ऑनलाइन स्कीमा परिवर्तन टूल के लिए अन्य महत्वपूर्ण सीमाएं यह है कि तालिका में अद्वितीय या प्राथमिक कुंजी मौजूद होनी चाहिए। इसका उपयोग पुरानी और नई तालिकाओं के बीच प्रतिलिपि बनाने के लिए पंक्तियों की पहचान करने के लिए किया जाता है। वे उपकरण भी प्रत्यक्ष ALTER की तुलना में बहुत धीमे हैं - एक परिवर्तन जिसमें ALTER चलाते समय घंटों लग जाते हैं, pt-osc या gh-ost का उपयोग करके किए जाने में कुछ दिन लग सकते हैं।
दूसरी ओर, जैसा कि हमने उल्लेख किया है, जब तक आवश्यकताएं पूरी होती हैं और सीमाएं लागू नहीं होतीं, आप किसी एक टूल का उपयोग करके सभी स्कीमा परिवर्तन चला सकते हैं। सभी मेजबानों पर एक ही समय में होगा इस प्रकार आपको अनुकूलता के बारे में चिंता करने की आवश्यकता नहीं है। प्रक्रिया को कैसे निष्पादित किया जाता है, इस पर आपका कुछ स्तर का नियंत्रण भी होता है (पीटी-ओएससी में कम, जीएच-ओस्ट में बहुत अधिक)।
आप स्कीमा परिवर्तन के प्रभाव को कम कर सकते हैं, आप उन्हें रोक सकते हैं और उन्हें केवल पर्यवेक्षण के तहत चलने दे सकते हैं, आप वास्तव में इसे करने से पहले परिवर्तन का परीक्षण कर सकते हैं। आप उन्हें ट्रैक प्रतिकृति अंतराल और विराम का पता लगा सकते हैं एक प्रभाव का पता लगाया जाना चाहिए। यह उन उपकरणों को MySQL प्रतिकृति के साथ काम करते हुए DBA के शस्त्रागार में वास्तव में एक बढ़िया अतिरिक्त बनाता है।
रोलिंग स्कीमा परिवर्तन
आम तौर पर, एक डीबीए ऑनलाइन स्कीमा परिवर्तन टूल में से एक का उपयोग करेगा। लेकिन जैसा कि हमने पहले चर्चा की, कुछ परिस्थितियों में, उनका उपयोग नहीं किया जा सकता है और प्रत्यक्ष परिवर्तन ही एकमात्र व्यवहार्य विकल्प है। यदि हम स्टैंडअलोन MySQL के बारे में बात कर रहे हैं, तो आपके पास कोई विकल्प नहीं है - यदि परिवर्तन गैर-अवरुद्ध है, तो यह अच्छा है। यदि ऐसा नहीं है, तो ठीक है, आप इसके बारे में कुछ नहीं कर सकते। लेकिन फिर, ऐसा नहीं है कि बहुत से लोग MySQL को एकल उदाहरण के रूप में चलाते हैं, है ना? प्रतिकृति के बारे में कैसे? जैसा कि हमने पहले चर्चा की, गुरु पर सीधा परिवर्तन संभव नहीं है - अधिकांश मामलों में यह दास पर पिछड़ जाएगा और यह स्वीकार्य नहीं हो सकता है। हालाँकि, जो किया जा सकता है, वह है परिवर्तन को एक रोलिंग फैशन में निष्पादित करना। आप दासों के साथ शुरू कर सकते हैं और, एक बार उन सभी पर परिवर्तन लागू होने के बाद, दासों में से एक को एक नए स्वामी के रूप में बढ़ावा दें, पुराने स्वामी को एक दास के रूप में पदावनत करें और उस पर परिवर्तन निष्पादित करें। निश्चित रूप से, परिवर्तन संगत होना चाहिए, लेकिन सच कहूं तो, सबसे आम मामले जहां आप ऑनलाइन स्कीमा परिवर्तनों का उपयोग नहीं कर सकते हैं, प्राथमिक या अद्वितीय कुंजी की कमी के कारण हैं। अन्य सभी मामलों के लिए, किसी प्रकार का समाधान है, विशेष रूप से पीटी-ऑनलाइन-स्कीमा-परिवर्तन में क्योंकि gh-ost की अधिक कठिन सीमाएँ हैं। यह एक ऐसा समाधान है जिसे आप "ऐसा ही" या "आदर्श से बहुत दूर" कहेंगे, लेकिन यदि आपके पास चुनने के लिए कोई अन्य विकल्प नहीं है तो यह काम करेगा। यह भी महत्वपूर्ण है, यदि आप अपने स्कीमा की निगरानी करते हैं और तालिका के बढ़ने से पहले मुद्दों को पकड़ लेते हैं, तो अधिकांश सीमाओं से बचा जा सकता है। यहां तक कि अगर कोई प्राथमिक कुंजी के बिना एक तालिका बनाता है, तो सीधा परिवर्तन चलाने में कोई समस्या नहीं है, जिसमें आधा सेकंड या उससे कम समय लगता है, क्योंकि तालिका लगभग खाली है।
यदि यह बढ़ता है, तो यह एक गंभीर समस्या बन जाएगी, लेकिन यह डीबीए पर निर्भर है कि वह इस तरह के मुद्दों को वास्तव में समस्या पैदा करने से पहले पकड़ ले। हम यह सुनिश्चित करने के लिए कुछ टिप्स और ट्रिक्स को कवर करेंगे कि आप इस तरह के मुद्दों को समय पर पकड़ लेंगे। हम आपके स्कीमा को कैसे डिज़ाइन करें, इस बारे में सामान्य सुझाव भी साझा करेंगे।
टिप्स और ट्रिक्स
स्कीमा डिज़ाइन
जैसा कि हमने इस पोस्ट में दिखाया है, प्रतिकृति सेटअप के साथ काम करते समय ऑनलाइन स्कीमा परिवर्तन उपकरण काफी महत्वपूर्ण होते हैं इसलिए यह सुनिश्चित करना काफी महत्वपूर्ण है कि आपका स्कीमा इस तरह से डिज़ाइन किया गया है कि यह स्कीमा परिवर्तन करने के लिए आपके विकल्पों को सीमित नहीं करेगा। तीन महत्वपूर्ण पहलू हैं। सबसे पहले, प्राथमिक या अद्वितीय कुंजी मौजूद होनी चाहिए - आपको यह सुनिश्चित करने की ज़रूरत है कि आपके डेटाबेस में प्राथमिक कुंजी के बिना कोई तालिका नहीं है। आपको इसकी नियमित रूप से निगरानी करनी चाहिए, नहीं तो यह भविष्य में गंभीर समस्या बन सकती है। दूसरा, आपको गंभीरता से विचार करना चाहिए कि क्या विदेशी चाबियों का उपयोग करना एक अच्छा विचार है। ज़रूर, उनके अपने उपयोग हैं लेकिन वे आपके डेटाबेस में ओवरहेड भी जोड़ते हैं और वे ऑनलाइन स्कीमा परिवर्तन टूल का उपयोग करने में समस्या पैदा कर सकते हैं। आवेदन द्वारा संबंधों को लागू किया जा सकता है। भले ही इसका मतलब अधिक काम हो, फिर भी विदेशी कुंजियों का उपयोग शुरू करने की तुलना में यह एक बेहतर विचार हो सकता है और यह गंभीर रूप से सीमित हो सकता है कि किस प्रकार के स्कीमा परिवर्तन किए जा सकते हैं। तीसरा, ट्रिगर। विदेशी चाबियों की तरह ही कहानी। उनके पास एक अच्छी विशेषता है, लेकिन वे एक बोझ बन सकते हैं। आपको गंभीरता से विचार करने की आवश्यकता है कि क्या उनका उपयोग करने से होने वाले लाभ उनकी सीमाओं से अधिक हैं।
स्कीमा परिवर्तनों को ट्रैक करना
स्कीमा परिवर्तन प्रबंधन केवल स्कीमा परिवर्तन चलाने के बारे में नहीं है। आपको अपनी स्कीमा संरचना के शीर्ष पर भी रहना होगा, खासकर यदि आप परिवर्तन करने वाले अकेले नहीं हैं।
ClusterControl उपयोगकर्ताओं को कुछ सबसे सामान्य स्कीमा डिज़ाइन समस्याओं को ट्रैक करने के लिए उपकरण प्रदान करता है। यह उन तालिकाओं को ट्रैक करने में आपकी सहायता कर सकता है जिनमें प्राथमिक कुंजी नहीं है:
जैसा कि हमने पहले चर्चा की, ऐसी तालिकाओं को जल्दी पकड़ना बहुत महत्वपूर्ण है क्योंकि प्राथमिक कुंजी को प्रत्यक्ष परिवर्तन का उपयोग करके जोड़ा जाना है।
ClusterControl डुप्लिकेट इंडेक्स को ट्रैक करने में भी आपकी मदद कर सकता है। आम तौर पर, आप कई इंडेक्स नहीं चाहते हैं जो अनावश्यक हैं। ऊपर के उदाहरण में, आप देख सकते हैं कि (k, c) पर एक इंडेक्स है और (k) पर एक इंडेक्स भी है। कोई भी क्वेरी जो कॉलम 'के' पर बनाए गए इंडेक्स का उपयोग कर सकती है, कॉलम (के, सी) पर बनाए गए समग्र इंडेक्स का भी उपयोग कर सकती है। ऐसे मामले हैं जहां अनावश्यक अनुक्रमणिका रखना फायदेमंद होता है लेकिन आपको मामले के आधार पर मामले से संपर्क करना होगा। MySQL 8.0 से शुरू करके, यह जल्दी से जांचना संभव है कि किसी इंडेक्स की वास्तव में आवश्यकता है या नहीं। आप एक अनावश्यक अनुक्रमणिका को चलाकर 'अदृश्य' बना सकते हैं:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 INVISIBLE;यह MySQL को उस अनुक्रमणिका को अनदेखा कर देगा और, निगरानी के माध्यम से, आप जांच सकते हैं कि क्या डेटाबेस के प्रदर्शन पर कोई नकारात्मक प्रभाव पड़ा है। यदि सब कुछ कुछ समय (कुछ दिन या सप्ताह) के लिए योजना के अनुसार काम करता है, तो आप अनावश्यक सूचकांक को हटाने की योजना बना सकते हैं। यदि आपको पता चलता है कि कुछ सही नहीं है, तो आप इस अनुक्रमणिका को चलाकर हमेशा पुन:सक्षम कर सकते हैं:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 VISIBLE;वे ऑपरेशन तत्काल होते हैं और सूचकांक हर समय होता है, और अभी भी बनाए रखा जाता है - यह केवल इतना है कि इसे ऑप्टिमाइज़र द्वारा ध्यान में नहीं रखा जाएगा। इस विकल्प के लिए धन्यवाद, MySQL 8.0 में इंडेक्स को हटाना ज्यादा सुरक्षित ऑपरेशन होगा। पिछले संस्करणों में, गलत तरीके से निकाले गए इंडेक्स को फिर से जोड़ने पर बड़ी टेबल पर दिन नहीं तो घंटे लग सकते हैं।
ClusterControl आपको MyISAM तालिकाओं के बारे में भी बता सकता है।
जबकि MyISAM के अभी भी इसके उपयोग हो सकते हैं, आपको यह ध्यान रखना होगा कि यह एक ट्रांजेक्शनल स्टोरेज इंजन नहीं है। जैसे, यह आसानी से एक प्रतिकृति सेटअप में नोड्स के बीच डेटा असंगति का परिचय दे सकता है।
ClusterControl की एक और बहुत उपयोगी विशेषता परिचालन रिपोर्ट में से एक है - एक स्कीमा परिवर्तन रिपोर्ट।
एक आदर्श दुनिया में, एक डीबीए सभी स्कीमा परिवर्तनों की समीक्षा, अनुमोदन और कार्यान्वयन करता है। दुर्भाग्य से ऐसा हमेशा नहीं होता है। इस तरह की समीक्षा प्रक्रिया चुस्त विकास के साथ अच्छी तरह से नहीं चलती है। इसके अलावा, डेवलपर-टू-डीबीए अनुपात आम तौर पर काफी अधिक होता है जो एक समस्या भी बन सकता है क्योंकि डीबीए एक बाधा नहीं बनने के लिए संघर्ष करेगा। इसलिए डीबीए के ज्ञान के बाहर किए गए स्कीमा परिवर्तनों को देखना असामान्य नहीं है। फिर भी, डीबीए आमतौर पर डेटाबेस के प्रदर्शन और स्थिरता के लिए जिम्मेदार होता है। स्कीमा परिवर्तन रिपोर्ट के लिए धन्यवाद, वे अब स्कीमा परिवर्तनों पर नज़र रख सकते हैं।
सबसे पहले कुछ विन्यास की जरूरत है। किसी दिए गए क्लस्टर (/etc/cmon.d/cmon_X.cnf) के लिए कॉन्फ़िगरेशन फ़ाइल में, आपको यह परिभाषित करना होगा कि किस होस्ट ClusterControl को परिवर्तनों को ट्रैक करना चाहिए और कौन से स्कीमा की जाँच की जानी चाहिए।
schema_change_detection_address=10.0.0.126
schema_change_detection_databases=sbtestएक बार ऐसा करने के बाद, आप नियमित रूप से निष्पादित होने वाली रिपोर्ट को शेड्यूल कर सकते हैं। एक उदाहरण आउटपुट नीचे जैसा हो सकता है:
जैसा कि आप देख सकते हैं, रिपोर्ट के पिछले रन के बाद से दो टेबल बदल गए हैं। पहले वाले में, कॉलम (k, c) पर एक नया कंपोजिट इंडेक्स बनाया गया है। दूसरी तालिका में, एक कॉलम जोड़ा गया था।
बाद के रन में हमें नई टेबल के बारे में जानकारी मिली, जो बिना किसी इंडेक्स या प्राइमरी की के बनाई गई थी। इस तरह की जानकारी का उपयोग करके, जब आवश्यक हो तो हम आसानी से कार्य कर सकते हैं और इससे पहले कि वे वास्तव में अवरोधक बनने लगें, समस्याओं का समाधान करें।
