"अपने डेटाबेस को नवीनतम संस्करण में अपग्रेड रखें - यह आपकी सुरक्षा के लिए है" ऐसा कुछ है जिसे आप अक्सर अच्छी सलाह और सर्वोत्तम अभ्यास के रूप में सुन सकते हैं जब डेटाबेस प्रबंधन की बात आती है। दूसरी ओर, अपने डेटाबेस को अपग्रेड करना एक समय लेने वाला कार्य हो सकता है। यहां तक कि एक छोटे संस्करण के उन्नयन के लिए आवश्यक है कि आप अपने उत्पादन सेटअप को अपग्रेड करने से पहले एक स्टेजिंग वातावरण में अपग्रेड का अच्छी तरह से परीक्षण करें। तो कौन सी बड़ी बात है? यदि आप केवल एक छोटे संस्करण से पिछड़ रहे हैं, तो इससे कोई फर्क नहीं पड़ना चाहिए, है ना? खैर, यह नहीं हो सकता... जब तक यह नहीं करता। और क्या आप वाकई उस तरह का जोखिम उठाने के लिए तैयार हैं?
इस साल की शुरुआत में, गैलेरा क्लस्टर (CVE-2021-27928) में एक नई संभावित खतरनाक भेद्यता की पहचान की गई थी। पहली नज़र में, हम देखते हैं कि गंभीरता को उच्च के रूप में चिह्नित किया गया था, और जब हम इस मुद्दे को और अधिक खोदना शुरू करते हैं, तो यह वास्तव में गंभीर लगता है। ऐसा प्रतीत होता है कि एक सुपर उपयोगकर्ता रनटाइम पर wsrep_provider और wsrep_notify_cmd वेरिएबल को बदलकर किसी भी मनमाने कोड को निष्पादित कर सकता है। यह उपयोगकर्ता को .so लाइब्रेरी को लोड करने और एक स्क्रिप्ट की ओर इंगित करने की अनुमति देता है जिसे सर्वर निष्पादित करेगा। जैसा कि आप कल्पना कर सकते हैं, यह एक अच्छी स्थिति नहीं है। निश्चित रूप से, आपको सुपर उपयोगकर्ता तक पहुंच की आवश्यकता है, और आपको डेटाबेस नोड पर निष्पादित करने के लिए कुछ उपलब्ध होना चाहिए, लेकिन तथ्य यह है कि गैलेरा को मनमाने ढंग से कोड निष्पादित करने के लिए कॉन्फ़िगर किया जा सकता है क्योंकि 'mysql' उपयोगकर्ता इसके लिए काफी खराब है अपना।
हमेशा की तरह, इस तरह के मामलों में, सुधार किए गए हैं, और सॉफ़्टवेयर के नए संस्करण, भेद्यता से अप्रभावित, धकेल दिए गए हैं। यह विशेष समस्या MariaDB 10.5.9, 10.4.18, 10.3.28, और 10.2.37, साथ ही Percona XtraDB क्लस्टर 5.6.51-28.46, Percona XtraDB क्लस्टर 5.7.33-31.49, और Percona XtraDB क्लस्टर में तय की गई है। 8.0.22-13.1। सब कुछ सामान्य होता दिख रहा है। सही?
गलत। उत्पादन पर चल रहे अनगिनत सिस्टम हैं जिन्हें अभी तक नए, अप्रभावित संस्करण में अपग्रेड नहीं किया गया है। कईनाइन सपोर्ट टीम जंगली में कई डेटाबेस वातावरणों के संपर्क में है, और हम क्लस्टरकंट्रोल द्वारा प्रबंधित वातावरण में माइग्रेट करने में उनकी मदद करने के लिए लगातार संभावनाओं के साथ काम कर रहे हैं। हम सभी प्रकार के MySQL (और न केवल MySQL) को पुराने संस्करणों में चलते हुए देखते हैं, कभी-कभी ऐसे संस्करण भी जो अपने जीवन के अंत तक पहुँच चुके होते हैं और अब सुरक्षा अद्यतन प्राप्त नहीं कर रहे हैं। ऐसा नहीं होना चाहिए, खासकर यदि आप ClusterControl उपयोगकर्ता हैं।
ClusterControl सुविधाओं के एक सेट के साथ आता है जो आपको सभी सुरक्षा सुधारों के साथ अद्यतित रहने में मदद करेगा। आइए एक नज़र डालते हैं:
सबसे पहले, ClusterControl ऑपरेशनल रिपोर्ट के साथ आता है, उनमें से एक पैकेज अपग्रेड रिपोर्ट है:
क्लस्टरकंट्रोल की सभी परिचालन रिपोर्ट की तरह, पैकेज अपग्रेड रिपोर्ट को निम्न के लिए शेड्यूल किया जा सकता है नियमित रूप से निष्पादित किया जाए और फिर ईमेल के माध्यम से वितरित किया जाए। इसमें नोड्स पर स्थापित पैकेज संस्करणों के बारे में जानकारी होगी और यदि किसी प्रकार का उन्नयन किया जाना चाहिए:
पैकेज अपग्रेड रिपोर्ट उन पैकेजों की सूची प्रस्तुत करती है जिन्हें सभी के लिए अद्यतन किया जाना चाहिए डेटाबेस, लोडबैलेंसर, सुरक्षा सुधार, और नोड पर स्थापित कोई अन्य पैकेज। सभी सिस्टम पैकेजों के लिए, समाधान उन्हें मानक विधियों (उपयुक्त, यम) का उपयोग करके अपग्रेड करना है। जब डेटाबेस और लोड बैलेंसर्स की बात आती है, तो ClusterControl कार्यक्षमता के साथ आता है जो आपको UI से सीधे मामूली संस्करण अपग्रेड करने की अनुमति देता है।
इससे पहले कि हम वहां जाएं, मान लें कि डेटाबेस को अपडेट करना है। आप केवल अपग्रेड को आँख बंद करके आगे बढ़ना और चलाना नहीं चाहते हैं - यह संभावित रूप से आपके एप्लिकेशन के लिए समस्याएँ पैदा कर सकता है। यह नहीं होना चाहिए - छोटे संस्करण पश्चगामी संगतता को नहीं तोड़ते हैं (सिवाय जब आप MySQL 8.0 का उपयोग करते हैं - तो हाँ, आप 8.0.x से 8.0.x+1 पर जाने पर कुछ भी उम्मीद कर सकते हैं); हालांकि, इसमें हमेशा कुछ जोखिम शामिल होता है। आपको सबसे पहले जो करना चाहिए वह एक अलग वातावरण में अपग्रेड का परीक्षण करना है।
हमारे पास ProxySQL और Keepalived के साथ एक साधारण MariaDB Galera क्लस्टर है:
हम एक परीक्षण क्लस्टर बनाना चाहते हैं ताकि हम अपग्रेड का परीक्षण कर सकें प्रक्रिया। ClusterControl के साथ, क्रिएट रेप्लिका क्लस्टर जॉब का उपयोग करना उतना ही आसान है:
हम मौजूदा क्लस्टर से ताजा डेटा प्राप्त कर सकते हैं, या हम बैकअप से डेटा का उपयोग कर सकते हैं।
हमें प्रोडक्शन क्लस्टर में एक सोर्स नोड भी चुनना होगा: 
फिर हमें एक नियमित परिनियोजन विज़ार्ड से गुजरना होगा, संस्करण चुनना होगा और डेटाबेस का विक्रेता, रूट पासवर्ड को परिभाषित करना, और इसी तरह। हम उन नोड्स को पास करके समाप्त करते हैं जिन पर क्लस्टर स्थापित किया जाएगा।
परिणामस्वरूप, आपको सूची में एक नया क्लस्टर दिखाई देगा। स्पष्ट चिह्न है कि यह उत्पादन क्लस्टर की नकल कर रहा है। एक बात ध्यान देने योग्य है, डिफ़ॉल्ट सेटअप में, क्लस्टरकंट्रोल प्रतिकृति क्लस्टर बनाने के लिए संकुल के नवीनतम संस्करणों का उपयोग करेगा। यदि आप केवल प्रश्नों को दोबारा जांचना चाहते हैं, तो यह पर्याप्त है। यदि आप पूरी अपग्रेड प्रक्रिया से गुजरना चाहते हैं, तो आपको पुराने संस्करण को स्थापित करने के लिए MySQL पैकेज के पुराने संस्करणों को पिन करना होगा (और फिर उन्हें अनपिन करें और अपग्रेड का परीक्षण करें)।
एक तरह से या दूसरे, सफल परीक्षणों के बाद, आप अंततः अपग्रेड करना चाहेंगे। इसे पूरा करने में ClusterControl आपकी मदद कर सकता है:
प्रबंधन -> अपग्रेड में, आपको अपग्रेड करने के लिए एक UI मिलेगा ।
आप उपलब्ध डेटाबेस को रीफ्रेश करने के लिए "नए पैकेजों की जांच करें" का उपयोग कर सकते हैं पैकेज। हम यह भी चुन सकते हैं कि हम किन नोड्स को अपग्रेड करना चाहते हैं और कौन सी सेवाएं:
बस पुष्टि करें और बस इतना ही - ClusterControl अपग्रेड करेगा और आपको संकुल का नवीनतम संस्करण।
जैसा कि आप देख सकते हैं, ClusterControl आपके डेटाबेस को अद्यतित रखना आसान और सीधा बनाता है। एकमात्र चरण जिसे आपको मैन्युअल रूप से संभालना होगा वह है उचित परीक्षण। अन्यथा - बाकी सब कुछ आपके लिए ClusterControl द्वारा किया जा सकता है। इस बारे में अधिक जानने के इच्छुक हैं कि कैसे ClusterControl आपके डेटाबेस को प्रभावी ढंग से प्रबंधित करने में आपकी मदद कर सकता है? इसे 30 दिनों के लिए मुफ़्त में आज़माएँ।
