गैलेरा-आधारित क्लस्टर जैसे Percona XtraDB क्लस्टर (PXC) या MariaDB Galera Cluster के लिए अपने डेटाबेस को अपग्रेड करना चुनौतीपूर्ण हो सकता है, खासकर उत्पादन-आधारित वातावरण के लिए। आप अपनी उच्च उपलब्धता की स्थिति को खोने और इसे जोखिम में डालने का जोखिम नहीं उठा सकते।
एक अपग्रेड प्रक्रिया को अच्छी तरह से प्रलेखित किया जाना चाहिए, और आदर्श रूप से, अपग्रेड से पहले प्रलेखन, कठोर परीक्षण और बेंचमार्किंग की जानी चाहिए। सबसे महत्वपूर्ण बात यह है कि इसके डेटाबेस वर्जन अपग्रेड के चेंजलॉग के आधार पर सुरक्षा और सुधारों की भी पहचान की जानी है।
सभी चिंताओं के साथ, स्वचालन एक अधिक कुशल अपग्रेड प्रक्रिया प्राप्त करने में मदद करता है, और मानवीय त्रुटि से बचने में मदद करता है और आरटीओ में सुधार करता है।
पीएक्ससी/मारियाडीबी गैलेरा क्लस्टर अपग्रेड प्रक्रिया को कैसे प्रबंधित करें
अपने PXC/MariaDB Galera Cluster को अपग्रेड करने के लिए उचित दस्तावेज़ीकरण और प्रक्रिया प्रवाह की आवश्यकता होती है जो कि किए जाने वाले कामों को सूचीबद्ध करता है और अगर चीजें दक्षिण में जाती हैं तो क्या करना है। इसका मतलब है कि एक व्यापार निरंतरता योजना तैयार की जानी चाहिए जिसमें आपकी आपदा वसूली योजना भी शामिल हो। परेशानी की स्थिति में आप अपना व्यवसाय खोने का जोखिम नहीं उठा सकते।
सामान्य रूप से सबसे पहले परीक्षण वातावरण के साथ शुरुआत करना है। परीक्षण परिवेश में आपके उत्पादन परिवेश के समान सटीक सेटिंग्स और कॉन्फ़िगरेशन होना चाहिए। आप उत्पादन परिवेश के उन्नयन के साथ सीधे आगे नहीं बढ़ सकते क्योंकि आप सुनिश्चित नहीं हैं कि यदि चीजें योजना के अनुरूप नहीं होती हैं तो इसका क्या प्रभाव और प्रभाव होगा।
उत्पादन परिवेश के साथ काम करना अत्यधिक संवेदनशील होता है, इसलिए अधिकांश मामलों में, अत्यधिक प्रभाव से बचने के लिए डाउनटाइम और रखरखाव विंडो हमेशा मौजूद रहती है।
पीसीएक्स या मारियाडीबी गैलेरा क्लस्टर के लिए दो प्रकार के अपग्रेड हैं जिनके बारे में आपको जानकारी होनी चाहिए। ये प्रमुख रिलीज़ अपग्रेड और मामूली रिलीज़ अपग्रेड या अक्सर इन-प्लेस अपग्रेड के रूप में संदर्भित होते हैं। एक इन-प्लेस अपग्रेड वह है जहां आप अपने डेटाबेस संस्करण को अपने डेटाबेस के समान बाइनरी डेटा का उपयोग करके अपने नवीनतम लघु संस्करण में अपग्रेड कर सकते हैं। डेटा में कोई भौतिक परिवर्तन नहीं होगा, लेकिन केवल इसके डेटाबेस बाइनरी या अंतर्निहित सॉफ़्टवेयर पैकेज पर होगा।
PCX या MariaDB गैलेरा क्लस्टर को एक प्रमुख रिलीज़ में अपग्रेड करना
एक प्रमुख रिलीज में अपग्रेड करना चुनौतीपूर्ण हो सकता है, खासकर उत्पादन परिवेश के लिए। इसमें एक जटिल प्रकार का डेटाबेस कॉन्फ़िगरेशन और पीएक्ससी या मारियाडीबी गैलेरा क्लस्टर की विशेष अंतर्निहित विशेषताएं शामिल हैं। Spatiotemporal, टाइम-स्टैम्प्ड डेटा, मशीन डेटा, या कोई भी बहुआयामी डेटा बहुत ही रूढ़िवादी और अपग्रेड के प्रति संवेदनशील होते हैं। आप इस प्रक्रिया के लिए इन-प्लेस अपग्रेड लागू नहीं कर सकते क्योंकि कई बड़े बदलाव किए गए होंगे। जब तक आपके पास बहुत छोटा डेटा या डेटा नहीं होता है जिसमें बेवकूफ या डेटा होता है जिसे आसानी से उत्पन्न किया जा सकता है, तब तक ऐसा करना सुरक्षित हो सकता है जब तक आप जानते हैं कि प्रभाव आपके डेटा को प्रभावित नहीं करेगा।
यदि आपका डेटा वॉल्यूम बड़ा है, तो अपग्रेड प्रक्रिया को स्वचालित रखना सबसे अच्छा है। हालांकि, अपग्रेड प्रक्रिया में सभी अनुक्रमों को स्वचालित करने के लिए यह एक आदर्श समाधान नहीं हो सकता है क्योंकि प्रमुख अपग्रेड चरण के दौरान अनपेक्षित मुद्दे सामने आ सकते हैं। एक प्रमुख अपग्रेड में ज्ञात परिणामों के साथ दोहराए जाने वाले चरणों और प्रक्रियाओं को स्वचालित करना सबसे अच्छा है। किसी भी समय, यह मूल्यांकन करने के लिए संसाधन की आवश्यकता होती है कि अपग्रेड प्रक्रिया में किसी भी रुकावट से बचने के लिए स्वचालन प्रक्रिया सुरक्षित है या नहीं। अपग्रेड के बाद स्वचालित परीक्षण भी उतना ही महत्वपूर्ण है, और इसे पोस्ट-अपग्रेड प्रक्रिया के एक भाग के रूप में शामिल किया जाना चाहिए।
पीसीएक्स या मारियाडीबी गैलेरा क्लस्टर को मामूली रिलीज में अपग्रेड करना
इन-प्लेस्ड अपग्रेड के रूप में संदर्भित एक छोटा रिलीज अपग्रेड आमतौर पर अपग्रेड प्रक्रिया को करने के लिए एक सुरक्षित तरीका है। इसका कारण यह है कि, इस रिलीज़ के लिए सबसे आम परिवर्तन सुरक्षा और शोषण पैच या सुधार, बग (आमतौर पर गंभीर वाले), या संगतता समस्याएं हैं जिनके लिए पैच की आवश्यकता होती है, खासकर यदि वर्तमान हार्डवेयर या ओएस में परिवर्तन लागू होते हैं जो डेटाबेस को भी नहीं कर सकते हैं सही से काम करना। हालांकि प्रभाव आमतौर पर न्यूनतम प्रभाव पर पुनर्प्राप्त करने योग्य हो सकता है, फिर भी यह आवश्यक है कि आपको उस चैंज को देखना और पढ़ना होगा जिसे विशिष्ट लघु संस्करण अपग्रेड के लिए धकेला गया था।
अपग्रेड प्रक्रिया को करने के लिए कार्य को परिनियोजित करना स्वचालन के लिए एक आदर्श उदाहरण है। सामान्य प्रवाह बहुत दोहराव वाला होता है और अधिकतर आपके मौजूदा पीएक्ससी या मारियाडीबी गैलेरा क्लस्टर को कोई नुकसान नहीं पहुंचाता है। सबसे महत्वपूर्ण बात यह है कि अपग्रेड के बाद, स्वचालित परीक्षण यह निर्धारित करने के लिए आगे बढ़ेगा कि सेटअप, कॉन्फ़िगरेशन, दक्षता और कार्यक्षमता टूटी नहीं है।
असफलता से बचें! तैयार रहें, इसे स्वचालित करें!
हमारा एक ग्राहक सहायता के लिए हमारे पास पहुंचा, क्योंकि डेटाबेस के मामूली अपग्रेड के बाद, एक सुविधा जो वे डेटाबेस में उपयोग कर रहे हैं वह ठीक से काम नहीं कर रही है। उन्होंने डाउनग्रेड कैसे किया जाए और यह कितना सुरक्षित होगा, इस पर कदम और प्रक्रियाओं के लिए कहा। उनके ग्राहक शिकायत कर रहे थे कि उनका आवेदन पूरी तरह से काम नहीं कर रहा है, यह सामान्य है कि यह उपयोगी नहीं है।
इतनी छोटी सी गड़बड़ी के लिए भी, नाराज ग्राहक आपके उत्पाद के बारे में गलत टिप्पणी कर सकता है। इस परिदृश्य से सीखा गया सबक यह है कि अपग्रेड के बाद परीक्षण में विफल होने से यह धारणा बन जाती है कि डेटाबेस में सभी फ़ंक्शन अपेक्षित रूप से काम कर रहे हैं।
मान लीजिए कि आपके पास अपग्रेड प्रक्रिया को स्वचालित करने की योजना है, तो ध्यान दें कि ऑटोमेशन प्रक्रिया का प्रकार आपके द्वारा किए जाने वाले अपग्रेड के प्रकार पर निर्भर करता है। जैसा कि पहले उल्लेख किया गया है, एक प्रमुख अपग्रेड बनाम एक मामूली अपग्रेड के अलग-अलग दृष्टिकोण हैं। इसलिए हो सकता है कि आपका ऑटोमेटन सेटअप दोनों डेटाबेस सॉफ़्टवेयर अपग्रेड पर लागू न हो।
अपग्रेड प्रक्रिया के बाद स्वचालित करना
इस समय, यह अपेक्षा की जाती है कि आपने अपनी अपग्रेड प्रक्रिया आदर्श रूप से स्वचालन के माध्यम से पूरी कर ली है। अब जब आपका डेटाबेस क्लाइंट कनेक्शन प्राप्त करने के लिए तैयार है, तो इसे एक कठोर परीक्षण चरण के साथ पालन करना होगा।
mysql_upgrad चलाएं
अपग्रेड प्रक्रिया पूरी होने के बाद mysql_upgrad को निष्पादित करना बहुत महत्वपूर्ण और अत्यधिक अनुशंसित है। mysql_upgrad निम्न चीज़ें करके अपग्रेड किए गए MySQL सर्वर के साथ असंगतताओं की तलाश करता है:
-
यह सिस्टम टेबल को mysql स्कीमा में अपग्रेड करता है ताकि आप उन नए विशेषाधिकारों या क्षमताओं का लाभ उठा सकें, जो शायद जोड़े गए हैं।
-
यह प्रदर्शन स्कीमा और sys स्कीमा को अपग्रेड करता है।
-
यह उपयोगकर्ता स्कीमा की जांच करता है।
mysql_upgrad यह निर्धारित करता है कि किसी तालिका में अपग्रेड के बाद नवीनतम संस्करण में परिवर्तन के कारण असंगतता जैसी समस्याएं हैं या नहीं और तालिका की मरम्मत करके इसे हल करने का प्रयास करता है। अन्यथा, यदि यह विफल हो जाता है, तो आपके स्वचालन परीक्षण को विफल होना होगा और किसी अन्य चीज़ पर आगे नहीं बढ़ना चाहिए। पहले इसकी जांच की जानी चाहिए और मैन्युअल मरम्मत करनी चाहिए।
त्रुटि लॉग जांचें
एक बार mysql_upgrad हो जाने के बाद, आपको हुई त्रुटियों की जांच और सत्यापन करने की आवश्यकता है। आप इसे एक स्क्रिप्ट में डाल सकते हैं और त्रुटि लॉग में किसी भी "त्रुटि" या "चेतावनी" लेबल की जांच कर सकते हैं। यह निर्धारित करना बहुत महत्वपूर्ण है कि क्या ऐसा है। आपके स्वचालित परीक्षण में त्रुटि जाल को पकड़ने की क्षमता होनी चाहिए या तो यह उपयोगकर्ता इनपुट के जारी रहने की प्रतीक्षा कर सकता है यदि त्रुटि बहुत कम या अपेक्षित है, अन्यथा अपग्रेड प्रक्रिया को रोक दें।
एक इकाई परीक्षण करें
एक टीडीडी (परीक्षण संचालित विकास) डेटाबेस वातावरण एक सॉफ्टवेयर विकास दृष्टिकोण है जहां सत्यापित होने के लिए परीक्षण मामलों की एक श्रृंखला होती है और यह निर्धारित करती है कि सत्यापन सत्य है (पास) या गलत (असफल)। कुछ ऐसा जो हमारे पास नीचे स्क्रीनशॉट में है:
गुरु99.com के सौजन्य से
यह एक प्रकार का यूनिट परीक्षण है जो आपके एप्लिकेशन और आपके डेटाबेस में अवांछित बग या तार्किक त्रुटियों से बचने में मदद करता है। याद रखें, यदि डेटाबेस में अमान्य डेटा संग्रहीत है, तो यह सभी व्यावसायिक विश्लेषणों और लेनदेन को नुकसान पहुंचाएगा, खासकर यदि इसमें जटिल वित्तीय गणना या गणितीय समीकरण शामिल हों।
यदि आप पूछें, तो क्या अपग्रेड के बाद यूनिट परीक्षण करना वास्तव में आवश्यक है? निश्चित रूप से यह है! जरूरी नहीं कि आपको इसे उत्पादन परिवेश में चलाना पड़े। परीक्षण चरणों के दौरान, यानी पहले अपने क्यूए को अपग्रेड करना, विकास/मंचन पर्यावरण, इसे उस क्षेत्र में लागू किया जाना है। डेटा को कम से कम या उसके उत्पादन परिवेश के समान ही एक सटीक प्रति होना चाहिए। यहां आपका लक्ष्य अवांछित परिणामों और निश्चित रूप से गलत तार्किक परिणामों से बचना है। आपको निश्चित रूप से अपने डेटा का अच्छी तरह से ध्यान रखना होगा और यह निर्धारित करना होगा कि क्या परिणाम सत्यापन परीक्षा पास करते हैं।
यदि आप अपने उत्पादन के साथ चलने का इरादा रखते हैं, तो इसे करें। हालांकि, क्यूए, विकास, या स्टेजिंग वातावरण में लागू होने वाले आपके परीक्षण चरण के रूप में कठोर न हों। ऐसा इसलिए है क्योंकि आपको उपलब्ध रखरखाव विंडो के आधार पर अपने समय की योजना बनानी होगी और देरी और लंबे समय तक आरटीओ से बचना होगा।
मेरे अनुभव में, अपग्रेड चरण के दौरान, ग्राहक एक त्वरित दृष्टिकोण का चयन करते हैं जो यह निर्धारित करने के लिए महत्वपूर्ण होगा कि क्या ऐसी सुविधा सही परिणाम प्रदान करती है। इसके अलावा, आपके पास परीक्षण को स्वचालित करने के लिए व्यावसायिक तार्किक कार्यों या संग्रहीत प्रक्रियाओं का एक सेट हो सकता है क्योंकि यह प्रश्नों को कैश करने और आपके डेटाबेस को गर्म करने में मदद करता है।
अपने डेटाबेस के लिए यूनिट टेस्ट की तैयारी करते समय, पहिया को फिर से बनाने से बचें। इसके बजाय, उन उपलब्ध टूल पर एक नज़र डालें जिन्हें आप चुन सकते हैं कि क्या यह आपकी आवश्यकताओं और ज़रूरतों के लिए अच्छा है। सेलेनियम देखें, या इस ब्लॉग को देखें।
क्वेरी की पहचान सत्यापित करें
आप जिस सबसे सामान्य टूल का उपयोग कर सकते हैं, वह है पेरकोना का पीटी-अपग्रेड। यह सत्यापित करता है कि क्वेरी परिणाम विभिन्न सर्वरों पर समान हैं। यह दिए गए लॉग और आपूर्ति किए गए कनेक्शन (या डीएसएन कहा जाता है) के आधार पर प्रश्नों को निष्पादित करता है, फिर परिणामों की तुलना करता है और किसी भी महत्वपूर्ण अंतर की रिपोर्ट करता है। उदाहरण के लिए, यह tcpdump के माध्यम से प्रश्नों को एकत्र करने या उनका विश्लेषण करने के लिए आपके विकल्पों से अधिक प्रदान करता है।
पीटी-अपग्रेड का उपयोग करना आसान है। उदाहरण के लिए, आप निम्न आदेश के साथ चला सकते हैं:
## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log
## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517
## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535 -x -n -q -tttt \
| pt-query-digest --type tcpdump --no-report --print \
| pt-upgrade h=host1 h=host2यह एक अच्छा अभ्यास है कि एक बार एक अपग्रेड, विशेष रूप से एक प्रमुख रिलीज अपग्रेड किया गया है, पीटी-अपग्रेड का उपयोग आगे बढ़ने और परिणामों के आधार पर अंतर की पहचान करने वाले क्वेरी विश्लेषण करने के लिए किया जाता है। परीक्षण चरण के दौरान इसे अपने क्यूए या स्टेजिंग और विकास पर्यावरण पर करते समय ऐसा करना एक अच्छा अभ्यास है ताकि आप तय कर सकें कि आगे बढ़ना सुरक्षित है या नहीं। आप इसे अपने ऑटोमेशन टूल में जोड़ सकते हैं और जब यह अपना कर्तव्य निभाने के लिए तैयार हो जाए तो इसे एक प्लेबुक के रूप में चला सकते हैं।
परीक्षण प्रक्रिया को स्वचालित कैसे करें?
अपने पिछले ब्लॉगों में, हमने आपके डेटाबेस को स्वचालित करने के विभिन्न तरीके प्रस्तुत किए हैं। सबसे आम उपकरण जो प्रचलन में हैं, ये IaC (इन्फ्रास्ट्रक्चर कोड के रूप में) परिनियोजन सॉफ़्टवेयर उपकरण हैं। आप काम करने के लिए कठपुतली, बावर्ची, साल्टस्टैक, या Ansible का उपयोग कर सकते हैं।
मेरी प्राथमिकता हमेशा अपना स्वचालित परीक्षण करने के लिए उत्तरदायी रही है, यह मुझे अपनी नौकरी की भूमिका से प्लेबुक बनाने की अनुमति देता है। बेशक, मैं एक पूरी चीज automaton नहीं बना सकता जो सभी चीजें करेगा क्योंकि स्थिति और पर्यावरण भिन्न होता है। पहले दिए गए अपग्रेड प्रकारों (मेजर बनाम माइनर अपग्रेड) के आधार पर, आपको इसकी प्रक्रिया में अंतर करना चाहिए। भले ही यह केवल एक इन-प्लेस अपग्रेड है, फिर भी आपको यह सुनिश्चित करना होगा कि आपकी प्लेबुक सही काम करेगी।
ClusterControl आपका डेटाबेस ऑटोमेशन मित्र है!
ClusterControl बुनियादी और स्वचालित परीक्षण करने के लिए एक अच्छा विकल्प है। ClusterControl परीक्षण के लिए एक ढांचा नहीं है; यह इकाई परीक्षण प्रदान करने का उपकरण नहीं है। हालाँकि, यह एक डेटाबेस प्रबंधन और निगरानी उपकरण है जिसमें उपयोगकर्ता या सॉफ़्टवेयर के व्यवस्थापक से अनुरोधित ट्रिगर्स के आधार पर बहुत सारे स्वचालित परिनियोजन शामिल होते हैं।
ClusterControl लघु संस्करण उन्नयन प्रदान करता है, जो उन्नयन करते समय DBA को सुविधा प्रदान करता है। यह फ्लाई पर भी mysql_upgrad करता है। तो आपको इसे मैन्युअल रूप से करने की आवश्यकता नहीं है। ClusterControl अपग्रेड किए जाने वाले नए संस्करणों का भी पता लगाता है और आपके लिए अगले चरणों की अनुशंसा करता है। विफलता के मामले में, अपग्रेड आगे नहीं बढ़ेगा।
यहाँ मामूली अपग्रेड कार्य का एक उदाहरण दिया गया है:
यदि आप ध्यान से देखें तो mysql_upgrad सफलतापूर्वक चलता है। हालांकि, यह अनुशंसा नहीं करता है और मास्टर के स्वचालित उन्नयन करता है, ऐसा इसलिए है क्योंकि यह आगे बढ़ने का सही तरीका नहीं है। उस स्थिति में, आपको नए दास को बढ़ावा देना होगा, फिर उन्नयन करने के लिए स्वामी को दास के रूप में अवनत करना होगा।
निष्कर्ष
ClusterControl के साथ सबसे अच्छी बात यह है कि आप त्रुटि लॉग की जाँच शामिल कर सकते हैं, एक इकाई परीक्षण कर सकते हैं, सलाहकार बनाकर प्रश्नों की पहचान सत्यापित कर सकते हैं। ऐसा करना मुश्किल नहीं है। आप SELinux और मेल्टडाउन/स्पेक्टर के लिए जाँच बनाने के लिए ClusterControl सलाहकार का उपयोग करके हमारे पिछले ब्लॉग का संदर्भ ले सकते हैं:भाग एक। यह उदाहरण देता है कि आप कैसे लाभ उठा सकते हैं और या तो अपग्रेड निष्पादित होने के बाद अगला कार्य करने के लिए ट्रिगर कर सकते हैं। ClusterControl में अंतर्निहित अलर्ट या अलार्म हैं जो आपके स्वचालित परीक्षण की वर्तमान स्थिति के बारे में आपको सूचित करने के लिए आपके पसंदीदा तृतीय-पक्ष अलर्ट सिस्टम में एकीकृत हो सकते हैं।
