सुरक्षित तरीके से MySQL और MariaDB में स्कीमा परिवर्तन कैसे करें

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

इस लेख में, हम देखेंगे कि MySQL और MariaDB पर नियंत्रित तरीके से डेटाबेस परिवर्तन कैसे करें। हम आपके दैनिक डीबीए कार्य में कुछ अच्छी आदतों के बारे में बात करेंगे। हम वास्तविक संचालन के दौरान पूर्व-आवश्यकताओं और कार्यों पर ध्यान केंद्रित करेंगे और डेटाबेस स्कीमा परिवर्तनों से निपटने के दौरान आपके सामने आने वाली समस्याओं पर ध्यान देंगे। हम ओपन सोर्स टूल्स के बारे में भी बात करेंगे जो इस प्रक्रिया में आपकी मदद कर सकते हैं।

परीक्षण और रोलबैक परिदृश्य

बैकअप

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

हालांकि, क्या होगा यदि आप अपने डेटाबेस को नवीनतम बैकअप में रोलबैक करने का जोखिम नहीं उठा सकते हैं, या आपकी रखरखाव विंडो पर्याप्त बड़ी नहीं है (सिस्टम प्रदर्शन को ध्यान में रखते हुए), तो आप परिवर्तन से पहले एक पूर्ण डेटाबेस बैकअप नहीं कर सकते हैं?

किसी के पास एक परिष्कृत, निरर्थक वातावरण हो सकता है, लेकिन जब तक प्राथमिक और स्टैंडबाय दोनों स्थानों में डेटा को संशोधित किया जाता है, तब तक इसके बारे में करने के लिए बहुत कुछ नहीं है। कई स्क्रिप्ट केवल एक बार चलाई जा सकती हैं, या परिवर्तनों को पूर्ववत करना असंभव है। अधिकांश SQL परिवर्तन कोड दो समूहों में आते हैं:

• एक बार चलाएं - आप एक ही कॉलम को टेबल में दो बार नहीं जोड़ सकते।
• पूर्ववत करना असंभव - एक बार जब आप उस कॉलम को छोड़ देते हैं, तो वह चला जाता है। आप निस्संदेह अपने डेटाबेस को पुनर्स्थापित कर सकते हैं, लेकिन यह ठीक पूर्ववत नहीं है।

आप इस समस्या से कम से कम दो संभावित तरीकों से निपट सकते हैं। एक बाइनरी लॉग को सक्षम करना और एक बैकअप लेना होगा, जो पीआईटीआर के साथ संगत है। ऐसा बैकअप पूर्ण, पूर्ण और सुसंगत होना चाहिए। एक्स्ट्राबैकअप के लिए, जब तक इसमें एक पूर्ण डेटासेट होता है, यह PITR-संगत होगा। Mysqldump के लिए, इसे PITR-संगत बनाने का विकल्प भी है। छोटे बदलावों के लिए, mysqldump बैकअप का एक रूपांतर बदलने के लिए डेटा का केवल एक सबसेट लेना होगा। यह --where विकल्प के साथ किया जा सकता है। बैकअप नियोजित रखरखाव का हिस्सा होना चाहिए।

mysqldump -u -p --lock-all-tables --where="WHERE employee_id=100" mydb employees> backup_table_tmp_change_07132018.sql

चयन के रूप में तालिका बनाएं का उपयोग करने की एक और संभावना है।

आप डेटा या साधारण संरचना परिवर्तनों को एक निश्चित अस्थायी तालिका के रूप में संग्रहीत कर सकते हैं। यदि आपको अपने परिवर्तनों को रोलबैक करने की आवश्यकता है तो इस दृष्टिकोण के साथ आपको एक स्रोत मिलेगा। यदि आप अधिक डेटा नहीं बदलते हैं तो यह काफी आसान हो सकता है। इसमें से डेटा निकालकर रोलबैक किया जा सकता है। यदि तालिका में डेटा की प्रतिलिपि बनाते समय कोई विफलता होती है, तो इसे स्वचालित रूप से हटा दिया जाता है और बनाया नहीं जाता है, इसलिए सुनिश्चित करें कि आपका कथन आपके लिए आवश्यक प्रतिलिपि बनाता है।

जाहिर है, कुछ सीमाएँ भी हैं।

चूंकि अंतर्निहित चयन कथनों में पंक्तियों का क्रम हमेशा निर्धारित नहीं किया जा सकता है, तालिका बनाएं ... इग्नोर करें चुनें और तालिका बनाएं ... प्रतिस्थापन चयन को कथन-आधारित प्रतिकृति के लिए असुरक्षित के रूप में चिह्नित किया गया है। ऐसे स्टेटमेंट स्टेटमेंट-आधारित मोड का उपयोग करते समय त्रुटि लॉग में एक चेतावनी उत्पन्न करते हैं और MIXED मोड का उपयोग करते समय पंक्ति-आधारित प्रारूप का उपयोग करके बाइनरी लॉग में लिखे जाते हैं।

ऐसी विधि का एक बहुत ही सरल उदाहरण हो सकता है:

CREATE TABLE tmp_employees_change_07132018 AS SELECT * FROM employees where employee_id=100;
UPDATE employees SET salary=120000 WHERE employee_id=100;
COMMMIT;

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

पॉइंट-इन-टाइम रोलबैक डीबीए को बैकअप से पुनर्स्थापना करने के बजाय पिछले समय में लेनदेन को वापस रोल करके डेटा को तेज़ी से पुनर्प्राप्त करने में सक्षम बनाता है। आरओडब्ल्यू-आधारित डीएमएल घटनाओं के आधार पर, फ्लैशबैक बाइनरी लॉग और रिवर्स उद्देश्यों को बदल सकता है। इसका मतलब है कि यह दिए गए पंक्ति परिवर्तनों को तेजी से पूर्ववत करने में मदद कर सकता है। उदाहरण के लिए, यह DELETE ईवेंट को INSERTs में बदल सकता है और इसके विपरीत, और यह UPDATE ईवेंट के WHERE और SET भागों को स्वैप करेगा। यह सरल विचार कुछ प्रकार की गलतियों या आपदाओं से वसूली में नाटकीय रूप से तेजी ला सकता है। जो लोग Oracle डेटाबेस से परिचित हैं, उनके लिए यह एक प्रसिद्ध विशेषता है। मारियाडीबी फ्लैशबैक की सीमा डीडीएल समर्थन की कमी है।

विलंबित प्रतिकृति स्लेव बनाएं

संस्करण 5.6 के बाद से, MySQL विलंबित प्रतिकृति का समर्थन करता है। एक दास सर्वर कम से कम एक निर्दिष्ट समय तक मास्टर से पीछे रह सकता है। डिफ़ॉल्ट विलंब 0 सेकंड है। देरी को N सेकंड पर सेट करने के लिए MASTER_DELAY विकल्प का उपयोग करें MASTER TO बदलें:

CHANGE MASTER TO MASTER_DELAY = N;

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

एसिंक्रोनस स्लेव बनाएं जो क्लस्टर का हिस्सा नहीं है

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

जैसा कि ऊपर स्क्रीनशॉट में दिखाया गया है, ClusterControl कुछ तरीकों से एसिंक्रोनस स्लेव को जोड़ने की प्रक्रिया को स्वचालित कर सकता है। आप क्लस्टर में नोड जोड़ सकते हैं, दास को विलंबित कर सकते हैं। मास्टर पर प्रभाव को कम करने के लिए, आप दास का निर्माण करते समय डेटा स्रोत के रूप में मास्टर के बजाय मौजूदा बैकअप का उपयोग कर सकते हैं।

डेटाबेस क्लोन करें और समय मापें

एक अच्छा परीक्षण उत्पादन परिवर्तन के यथासंभव निकट होना चाहिए। ऐसा करने का सबसे अच्छा तरीका है कि आप अपने मौजूदा परिवेश का क्लोन बना लें।

प्रतिकृति के माध्यम से परिवर्तन करें

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

ऑपरेशन

रखरखाव विंडो के दौरान, हम डेटाबेस पर एप्लिकेशन ट्रैफ़िक नहीं रखना चाहते हैं। कभी-कभी पूरी कंपनी में फैले सभी एप्लिकेशन को बंद करना कठिन होता है। वैकल्पिक रूप से, हम केवल कुछ विशिष्ट होस्ट को रिमोट से MySQL तक पहुंचने की अनुमति देना चाहते हैं (उदाहरण के लिए मॉनिटरिंग सिस्टम या बैकअप सर्वर)। इस उद्देश्य के लिए, हम Linux पैकेट फ़िल्टरिंग का उपयोग कर सकते हैं। यह देखने के लिए कि कौन से पैकेट फ़िल्टरिंग नियम उपलब्ध हैं, हम निम्नलिखित कमांड चला सकते हैं:

iptables -L INPUT -v

हमारे द्वारा उपयोग किए जाने वाले सभी इंटरफेस पर MySQL पोर्ट को बंद करने के लिए:

iptables -A INPUT -p tcp --dport mysql -j DROP

और रखरखाव विंडो के बाद फिर से MySQL पोर्ट को खोलने के लिए:

iptables -D INPUT -p tcp --dport mysql -j DROP

जिनके पास रूट एक्सेस नहीं है, उनके लिए आप max_connection को 1 या 'स्किप नेटवर्किंग' में बदल सकते हैं।

लॉगिंग

लॉगिंग प्रक्रिया शुरू करने के लिए, MySQL क्लाइंट प्रॉम्प्ट पर टी कमांड का उपयोग इस तरह करें:

mysql> tee /tmp/my.out;

वह आदेश MySQL को आपके वर्तमान MySQL लॉगिन सत्र के इनपुट और आउटपुट दोनों को /tmp/my.out नामक फ़ाइल में लॉग इन करने के लिए कहता है। फिर स्रोत कमांड के साथ अपनी स्क्रिप्ट फ़ाइल निष्पादित करें।

अपने निष्पादन समय का बेहतर विचार प्राप्त करने के लिए, आप इसे प्रोफाइलर सुविधा के साथ जोड़ सकते हैं। प्रोफाइलर को

SET profiling = 1;

फिर अपनी क्वेरी को

SHOW PROFILES;

आप उन प्रश्नों की सूची देखते हैं जिनके लिए प्रोफाइलर के पास आँकड़े हैं। तो अंत में, आप चुनते हैं कि किस क्वेरी के साथ जांचना है

SHOW PROFILE FOR QUERY 1;

स्कीमा माइग्रेशन टूल

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

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

इसी तरह, यदि पुरानी तालिका पर एक पंक्ति को संशोधित या हटा दिया जाता है, तो इसे नई तालिका में भी लागू किया जाता है। फिर, पुरानी और नई तालिका के बीच डेटा (LOW_PRIORITY INSERT का उपयोग करके) की प्रतिलिपि बनाने की पृष्ठभूमि प्रक्रिया शुरू होती है। एक बार डेटा कॉपी हो जाने के बाद, RENAME TABLE को क्रियान्वित किया जाता है।

एक और दिलचस्प उपकरण gh-ost है। घ-ओस्ट परिवर्तित स्कीमा के साथ एक अस्थायी तालिका बनाता है, जैसे पीटी-ऑनलाइन-स्कीमा-परिवर्तन करता है। यह INSERT प्रश्नों को निष्पादित करता है, जो पुराने से नई तालिका में डेटा की प्रतिलिपि बनाने के लिए निम्न पैटर्न का उपयोग करता है। फिर भी यह ट्रिगर्स का उपयोग नहीं करता है। दुर्भाग्य से ट्रिगर कई सीमाओं का स्रोत हो सकते हैं। gh-ost तालिका परिवर्तनों को पकड़ने के लिए बाइनरी लॉग स्ट्रीम का उपयोग करता है और अतुल्यकालिक रूप से उन्हें घोस्ट टेबल पर लागू करता है। एक बार जब हमने सत्यापित कर लिया कि gh-ost हमारे स्कीमा परिवर्तन को सही ढंग से निष्पादित कर सकता है, तो यह वास्तव में इसे निष्पादित करने का समय है। ध्यान रखें कि आपको माइग्रेशन के परीक्षण की प्रक्रिया के दौरान gh-ost द्वारा बनाई गई पुरानी तालिकाओं को मैन्युअल रूप से छोड़ने की आवश्यकता हो सकती है। आप --initially-drop-ghost-table और --initially-drop-old-table फ़्लैग का उपयोग करके gh-ost को यह आपके लिए करने के लिए कह सकते हैं। निष्पादित करने के लिए अंतिम आदेश बिल्कुल वैसा ही है जैसा हम अपने परिवर्तन का परीक्षण करने के लिए करते थे, हमने अभी इसमें --execute जोड़ा है।

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

TOI - यह डिफ़ॉल्ट DDL प्रतिकृति विधि है। राइटसेट को उत्पन्न करने वाला नोड पार्सिंग समय पर डीडीएल का पता लगाता है और डीडीएल प्रसंस्करण शुरू करने से पहले एसक्यूएल स्टेटमेंट के लिए एक प्रतिकृति घटना भेजता है। स्कीमा उन्नयन सभी क्लस्टर नोड्स पर एक ही कुल क्रम क्रम में चलता है, अन्य लेनदेन को संचालन की अवधि के लिए करने से रोकता है। यह तरीका तब अच्छा होता है जब आप चाहते हैं कि आपका ऑनलाइन स्कीमा अपग्रेड क्लस्टर के माध्यम से दोहराया जाए और पूरी तालिका को लॉक करने में कोई आपत्ति न हो (इसी तरह MySQL में डिफ़ॉल्ट स्कीमा परिवर्तन कैसे हुआ)।

SET GLOBAL wsrep_OSU_method='TOI';

RSU - स्थानीय स्तर पर स्कीमा अपग्रेड को पूरा करें। इस पद्धति में, आपके लेखन केवल उस नोड को प्रभावित कर रहे हैं जिस पर वे चल रहे हैं। परिवर्तन शेष क्लस्टर में दोहराए नहीं जाते हैं। यह विधि गैर-विरोधी कार्यों के लिए अच्छी है और यह क्लस्टर को धीमा नहीं करेगी।

SET GLOBAL wsrep_OSU_method='RSU';

जबकि नोड स्कीमा अपग्रेड को प्रोसेस करता है, यह क्लस्टर के साथ डीसिंक्रोनाइज़ करता है। जब यह स्कीमा अपग्रेड को संसाधित करना समाप्त करता है, तो यह विलंबित प्रतिकृति घटनाओं को लागू करता है और स्वयं को क्लस्टर के साथ सिंक्रनाइज़ करता है। भारी अनुक्रमणिका निर्माण चलाने के लिए यह एक अच्छा विकल्प हो सकता है।

निष्कर्ष

हमने यहां कई अलग-अलग तरीके प्रस्तुत किए हैं जो आपके स्कीमा परिवर्तनों की योजना बनाने में आपकी मदद कर सकते हैं। बेशक यह सब आपके आवेदन और व्यावसायिक आवश्यकताओं पर निर्भर करता है। आप अपनी परिवर्तन योजना तैयार कर सकते हैं, आवश्यक परीक्षण कर सकते हैं, लेकिन अभी भी एक छोटा सा मौका है कि कुछ गलत हो जाएगा। मर्फी के नियम के अनुसार - "किसी भी स्थिति में चीजें गलत हो जाएंगी, यदि आप उन्हें मौका देते हैं"। इसलिए सुनिश्चित करें कि आप इन परिवर्तनों को करने के विभिन्न तरीकों को आजमाएं, और वह चुनें जिसमें आप सबसे अधिक सहज हों।