हमने पहले MySQL गैलेरा क्लस्टर 4.0 में व्हाट्स न्यू के बारे में ब्लॉग किया है, स्ट्रीमिंग प्रतिकृति और मारियाडीबी 10.4 के साथ बड़े लेनदेन को संभालना और भाग 1 और भाग 2 श्रृंखला में नई स्ट्रीमिंग प्रतिकृति सुविधा का उपयोग करने के बारे में कुछ मार्गदर्शिकाएं प्रस्तुत की हैं।
अपनी डेटाबेस तकनीक को MySQL प्रतिकृति से MySQL गैलेरा क्लस्टर में स्थानांतरित करने के लिए आपको सही कौशल और सफल होने के लिए आप जो कर रहे हैं उसकी समझ होनी चाहिए। इस ब्लॉग में हम MySQL प्रतिकृति सेटअप से MySQL गैलेरा क्लस्टर 4.0 में माइग्रेट करने के लिए कुछ सुझाव साझा करेंगे।
MySQL प्रतिकृति और गैलेरा क्लस्टर के बीच अंतर
यदि आप अभी तक गैलेरा से परिचित नहीं हैं, तो हमारा सुझाव है कि आप MySQL ट्यूटोरियल के लिए हमारे गैलेरा क्लस्टर पर जाएं। गैलेरा क्लस्टर सिंक्रोनस प्रतिकृति के आधार पर प्रतिकृति के एक पूरे अलग स्तर का उपयोग करता है, MySQL प्रतिकृति के विपरीत जो एसिंक्रोनस प्रतिकृति का उपयोग करता है (लेकिन अर्ध-तुल्यकालिक प्रतिकृति प्राप्त करने के लिए भी कॉन्फ़िगर किया जा सकता है)।
गैलेरा क्लस्टर भी मल्टी-मास्टर प्रतिकृति का समर्थन करता है। यह अप्रतिबंधित समानांतर आवेदन (यानी, "समानांतर प्रतिकृति"), मल्टीकास्ट प्रतिकृति और स्वचालित नोड प्रावधान करने में सक्षम है।
गैलेरा क्लस्टर का प्राथमिक फोकस डेटा स्थिरता है, जबकि MySQL प्रतिकृति के साथ, यह डेटा असंगति के लिए प्रवण है (जिसे सर्वोत्तम प्रथाओं और उचित कॉन्फ़िगरेशन से बचा जा सकता है जैसे दासों पर केवल-पढ़ने के लिए लागू करने से बचने के लिए दासों के भीतर अवांछित लेखन)।
हालांकि गैलेरा द्वारा प्राप्त लेन-देन या तो प्रत्येक नोड पर लागू होते हैं या बिल्कुल नहीं, इनमें से प्रत्येक नोड अनुप्रयुक्त कतार (लेन-देन कमिट) में दोहराए गए राइट-सेट को प्रमाणित करता है जिसमें सभी की जानकारी भी शामिल होती है। लेनदेन के दौरान डेटाबेस द्वारा रखे गए ताले। ये राइट-सेट, एक बार पहचाने जाने वाले परस्पर विरोधी तालों को लागू नहीं किया जाता है। इस बिंदु तक, लेनदेन को प्रतिबद्ध माना जाता है और इसे टेबलस्पेस पर लागू करना जारी रखता है। एसिंक्रोनस प्रतिकृति के विपरीत, इस दृष्टिकोण को वस्तुतः सिंक्रोनस प्रतिकृति भी कहा जाता है क्योंकि राइट और कमिट एक तार्किक सिंक्रोनस मोड में होता है, लेकिन वास्तविक लेखन और टेबलस्पेस के लिए प्रतिबद्ध स्वतंत्र रूप से होता है और प्रत्येक नोड पर एसिंक्रोनस होता है।
MySQL प्रतिकृति के विपरीत, एक गैलेरा क्लस्टर एक सच्चा मल्टी-मास्टर, मल्टी-थ्रेडेड स्लेव, एक शुद्ध हॉट-स्टैंडबाय है, जिसमें मास्टर-फेलओवर या रीड-राइट स्प्लिटिंग की कोई आवश्यकता नहीं है। हालांकि, गैलेरा क्लस्टर में माइग्रेट करने का मतलब आपकी समस्याओं का स्वत:जवाब नहीं है। गैलेरा क्लस्टर केवल InnoDB का समर्थन करता है, इसलिए यदि आप MyISAM या मेमोरी स्टोरेज इंजन का उपयोग कर रहे हैं तो डिज़ाइन संशोधन हो सकते हैं।
गैर-InnoDB तालिकाओं को InnoDB में कनवर्ट करना
गैलेरा क्लस्टर आपको MyISAM का उपयोग करने की अनुमति देता है, लेकिन यह गैलेरा क्लस्टर के लिए डिज़ाइन नहीं किया गया था। गैलेरा क्लस्टर को क्लस्टर के भीतर सभी नोड्स के भीतर डेटा स्थिरता को सख्ती से लागू करने के लिए डिज़ाइन किया गया है और इसके लिए एक मजबूत एसीआईडी अनुपालक डेटाबेस इंजन की आवश्यकता है। InnoDB एक इंजन है जिसके पास इस क्षेत्र में इतनी मजबूत क्षमताएं हैं और अनुशंसा की जाती है कि आप InnoDB का उपयोग करें; विशेष रूप से लेन-देन करते समय।
यदि आप ClusterControl का उपयोग कर रहे हैं, तो आप प्रदर्शन सलाहकारों द्वारा प्रदान की गई किसी भी MyISAM तालिकाओं के लिए अपने डेटाबेस इंस्टेंस को निर्धारित करने के लिए आसानी से लाभ उठा सकते हैं। आप इसे प्रदर्शन → सलाहकार टैब के अंतर्गत पा सकते हैं। उदाहरण के लिए,
यदि आपको MyISAM और MEMORY तालिकाओं की आवश्यकता है, तो आप अभी भी इसका उपयोग कर सकते हैं लेकिन बना सकते हैं सुनिश्चित करें कि आपका डेटा जिसे दोहराने की आवश्यकता नहीं है। आप अपने संग्रहीत डेटा का उपयोग केवल-पढ़ने के लिए कर सकते हैं और, जहां भी उपयुक्त हो, "केवल पढ़ने के लिए प्रारंभ करें" का उपयोग कर सकते हैं।
अपनी InnoDB तालिका में प्राथमिक कुंजी जोड़ना
चूंकि गैलेरा क्लस्टर केवल InnoDB का समर्थन करता है, इसलिए यह बहुत महत्वपूर्ण है कि आपकी सभी तालिकाओं में एक क्लस्टर इंडेक्स होना चाहिए, (जिसे प्राथमिक कुंजी या अद्वितीय कुंजी भी कहा जाता है)। क्वेरी, इंसर्ट और अन्य डेटाबेस संचालन से सर्वश्रेष्ठ प्रदर्शन प्राप्त करने के लिए, यह बहुत महत्वपूर्ण है कि आपको प्रत्येक तालिका को एक अद्वितीय कुंजी (कुंजी) के साथ परिभाषित करना चाहिए क्योंकि InnoDB प्रत्येक तालिका के लिए सबसे सामान्य लुकअप और DML संचालन को अनुकूलित करने के लिए क्लस्टर इंडेक्स का उपयोग करता है। . यह क्लस्टर के भीतर लंबे समय तक चलने वाले प्रश्नों से बचने में मदद करता है और क्लस्टर में लिखने/पढ़ने के संचालन को धीमा कर सकता है।
ClusterControl में, ऐसे सलाहकार हैं जो आपको इसकी सूचना दे सकते हैं। उदाहरण के लिए, आपके MySQL प्रतिकृति मास्टर/स्लेव क्लस्टर में, आप सलाहकारों की सूची से अलार्म या दृश्य देखेंगे। नीचे दिए गए उदाहरण स्क्रीनशॉट से पता चलता है कि आपके पास ऐसी कोई तालिका नहीं है जिसमें कोई प्राथमिक कुंजी न हो:
एक मास्टर (या सक्रिय-लेखक) नोड की पहचान करें
गैलेरा क्लस्टर विशुद्ध रूप से एक वास्तविक मल्टी-मास्टर प्रतिकृति है। हालांकि, इसका मतलब यह नहीं है कि आप जिस भी नोड को लक्षित करना चाहते हैं उसे लिखने के लिए आप सभी स्वतंत्र हैं। पहचानने वाली एक बात यह है कि, जब एक अलग नोड पर लिखते हैं और एक परस्पर विरोधी लेन-देन का पता लगाया जाएगा, तो आप नीचे की तरह एक गतिरोध समस्या में आ जाएंगे:
2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
TRANSACTION 728431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
TRANSACTION 728426, ACTIVE 3 sec updating or deleting
mysql tables in use 1, locked 1
, undo log entries 11409
MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
update sbtest1_success set k=k+1 where id > 1000 and id < 100000
2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;एक मौजूदा सक्रिय-लेखक नोड की पहचान किए बिना कई नोड्स लिखने में समस्या, आप इन मुद्दों के साथ समाप्त हो जाएंगे जो बहुत ही सामान्य समस्याएं हैं जिन्हें मैंने कई नोड्स पर लिखते समय गैलेरा क्लस्टर का उपयोग करते समय देखा है। उसी समय। इससे बचने के लिए, आप सिंगल-मास्टर सेटअप दृष्टिकोण का उपयोग कर सकते हैं:
दस्तावेज़ीकरण से,
प्रवाह नियंत्रण को शिथिल करने के लिए, आप नीचे दी गई सेटिंग का उपयोग कर सकते हैं:
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"उपरोक्त के लिए सर्वर पुनरारंभ की आवश्यकता है क्योंकि fc_master_slave गतिशील नहीं है।
लॉगिंग विरोध या गतिरोध के लिए डिबगिंग मोड सक्षम करें
अपने गैलेरा क्लस्टर के साथ डिबगिंग या समस्याओं का पता लगाना बहुत महत्वपूर्ण है। गैलेरा में ताले MySQL प्रतिकृति की तुलना में अलग तरह से लागू किए गए हैं। क्लस्टर-व्यापी लेनदेन से निपटने के दौरान यह आशावादी लॉकिंग का उपयोग करता है। MySQL प्रतिकृति के विपरीत, इसमें केवल निराशावादी लॉकिंग होती है जो यह नहीं जानती है कि मल्टी-मास्टर सेटअप पर सह-मास्टर में ऐसा ही या परस्पर विरोधी लेनदेन निष्पादित किया जा रहा है या नहीं। गैलेरा अभी भी निराशावादी लॉकिंग का उपयोग करता है लेकिन स्थानीय नोड पर क्योंकि यह InnoDB द्वारा प्रबंधित किया जाता है, जो कि स्टोरेज इंजन समर्थित है। जब गैलेरा अन्य नोड्स में जाता है तो आशावादी लॉकिंग का उपयोग करता है। इसका मतलब यह है कि स्थानीय ताले (निराशावादी लॉकिंग) प्राप्त होने पर क्लस्टर पर अन्य नोड्स के साथ कोई जांच नहीं की जाती है। गैलेरा का मानना है कि, एक बार जब लेन-देन भंडारण इंजन के भीतर प्रतिबद्ध चरण से गुजरता है और अन्य नोड्स को सूचित किया जाता है, तो सब कुछ ठीक हो जाएगा और कोई विरोध नहीं होगा।
व्यवहार में, wsrep_logs_conflicts को सक्षम करना सबसे अच्छा है। यह परस्पर विरोधी MDL के साथ-साथ क्लस्टर में InnoDB लॉक का विवरण लॉग करेगा। इस चर को सक्षम करना गतिशील रूप से सेट किया जा सकता है लेकिन इसे सक्षम करने के बाद चेतावनी दी जा सकती है। यह आपकी त्रुटि-लॉग फ़ाइल को मौखिक रूप से पॉप्युलेट करेगा और आपकी त्रुटि-लॉग फ़ाइल का आकार बहुत बड़ा होने पर आपकी डिस्क को भर सकता है।
अपनी DDL क्वेरी से सावधान रहें
MySQL प्रतिकृति के विपरीत, एक ALTER कथन चलाने से केवल आने वाले कनेक्शन प्रभावित हो सकते हैं जिन्हें आपके ALTER कथन द्वारा लक्षित तालिका तक पहुंचने या संदर्भित करने की आवश्यकता होती है। यह दासों को भी प्रभावित कर सकता है यदि तालिका बड़ी है और दास अंतराल ला सकती है। हालांकि, जब तक आपके प्रश्न वर्तमान ALTER के साथ विरोध नहीं करते हैं, तब तक आपके मास्टर को लिखे जाने पर रोक नहीं लगाई जाएगी। हालांकि, गैलेरा क्लस्टर के साथ ALTER जैसे आपके DDL स्टेटमेंट चलाते समय ऐसा बिल्कुल नहीं है। ALTER कथन क्लस्टर-वाइड लॉक के कारण अटका हुआ गैलेरा क्लस्टर जैसी समस्याएं ला सकता है या प्रवाह नियंत्रण प्रतिकृति को आराम देना शुरू कर देता है जबकि कुछ नोड बड़े लेखन से पुनर्प्राप्त हो रहे हैं।
कुछ स्थितियों में, यदि तालिका बहुत बड़ी है और आपके एप्लिकेशन के लिए प्राथमिक और महत्वपूर्ण तालिका है, तो आपको अपने गैलेरा क्लस्टर में डाउनटाइम समाप्त हो सकता है। हालांकि, इसे डाउनटाइम के बिना हासिल किया जा सकता है। जैसा कि रिक जेम्स ने अपने ब्लॉग में बताया है, आप नीचे दिए गए सुझावों का पालन कर सकते हैं:
आरएसयू बनाम टीओआई
- रोलिंग स्कीमा अपग्रेड =एक बार में मैन्युअल रूप से एक नोड (ऑफ़लाइन) करें
- कुल आदेश अलगाव =गैलेरा सिंक्रनाइज़ करता है ताकि यह सभी नोड्स पर एक ही समय में (प्रतिकृति अनुक्रम में) किया जा सके। आरएसयू और टीओआई
सावधान:चूंकि डीडीएल के साथ क्लाइंट को सिंक्रोनाइज़ करने का कोई तरीका नहीं है, इसलिए आपको यह सुनिश्चित करना चाहिए कि क्लाइंट पुराने या नए स्कीमा से खुश हैं। अन्यथा, आपको स्कीमा और क्लाइंट कोड दोनों को एक साथ स्विच करते हुए संभवतः पूरे क्लस्टर को हटाना होगा।
एक "फास्ट" डीडीएल भी टीओआई के माध्यम से किया जा सकता है। यह इस तरह की एक संभावित सूची है:
- डेटाबेस/टेबल बनाएं/छोड़ें/नाम बदलें
- DEFAULT बदलने के लिए ALTER
- ENUM या SET की परिभाषा बदलने के लिए ALTER (मैन्युअल में चेतावनी देखें)
- कुछ विभाजन परिवर्तन जो तेज़ हैं।
- DROP INDEX (प्राथमिक कुंजी के अलावा)
- इंडेक्स जोड़ें?
- 'छोटे' टेबल पर अन्य ALTER.
- 5.6 और विशेष रूप से 5.7 में बहुत सारे ALGORITHM=INPLACE मामले होने के साथ, जांचें कि कौन से ALTER किस तरह से किए जाने चाहिए।
अन्यथा, RSU का उपयोग करें। प्रत्येक नोड के लिए अलग से निम्न कार्य करें:
SET GLOBAL wsrep_OSU_method='RSU';यह नोड को क्लस्टर से बाहर भी ले जाता है।
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';फिर से सिंक करता है, जिससे पुन:समन्वयन होता है (उम्मीद है कि एक त्वरित आईएसटी, धीमी एसएसटी नहीं)
अपने क्लस्टर की संगति बनाए रखें
गैलेरा क्लस्टर प्रतिकृति फिल्टर जैसे कि binlog_do_db या binlog_ignore_db का समर्थन नहीं करता है क्योंकि गैलेरा बाइनरी लॉगिंग पर निर्भर नहीं करता है। यह रिंग-बफर फ़ाइल पर निर्भर करता है जिसे GCache भी कहा जाता है जो क्लस्टर के साथ दोहराए गए राइट-सेट को संग्रहीत करता है। आप ऐसे डेटाबेस नोड्स के किसी भी असंगत व्यवहार या स्थिति को लागू नहीं कर सकते हैं।
दूसरी ओर, गैलेरा, क्लस्टर के भीतर डेटा स्थिरता को सख्ती से लागू करता है। यह अभी भी संभव है कि जहाँ पंक्तियाँ या रिकॉर्ड नहीं मिल सकते वहाँ असंगति हो सकती है। उदाहरण के लिए, अपने वेरिएबल wsrep_OSU_method या तो RSU या TOI को अपने DDL ALTER स्टेटमेंट के लिए सेट करना असंगत व्यवहार ला सकता है। TOI बनाम RSU के साथ गैलेरा के साथ असंगतता के बारे में चर्चा करते हुए Percona के इस बाहरी ब्लॉग को देखें।
wsrep_on=OFF सेट करना और बाद में DML या DDL क्वेरी चलाना आपके क्लस्टर के लिए खतरनाक हो सकता है। यदि परिणाम नोड की स्थिति या परिवेश पर निर्भर नहीं हैं, तो आपको अपनी संग्रहीत कार्यविधियों, ट्रिगर, फ़ंक्शन, ईवेंट या विचारों की भी समीक्षा करनी चाहिए। जब एक निश्चित नोड असंगत हो सकता है, तो यह संभावित रूप से पूरे क्लस्टर को नीचे ला सकता है। एक बार जब गैलेरा एक असंगत व्यवहार का पता लगाता है, तो गैलेरा क्लस्टर को छोड़ने और उस नोड को समाप्त करने का प्रयास करेगा। इसलिए, यह संभव है कि सभी नोड्स आपको दुविधा की स्थिति में छोड़कर असंगत हो सकते हैं।
यदि गैलेरा क्लस्टर नोड विशेष रूप से उच्च-ट्रैफ़िक अवधि में क्रैश का अनुभव करता है, तो बेहतर है कि नोड को तुरंत प्रारंभ न करें। इसके बजाय, एक पूर्ण एसएसटी करें या जितनी जल्दी हो सके एक नया उदाहरण लाएँ या एक बार ट्रैफ़िक कम हो जाए। यह संभव हो सकता है कि नोड असंगत व्यवहार ला सकता है जिसमें दूषित डेटा हो सकता है।
बड़े लेन-देनों को अलग करें और निर्धारित करें कि स्ट्रीमिंग प्रतिकृति का उपयोग करना है या नहीं
आइए सीधे इस पर चलते हैं। विशेष रूप से गैलेरा क्लस्टर 4.0 पर सबसे बड़े परिवर्तनों में से एक स्ट्रीमिंग प्रतिकृति है। गैलेरा क्लस्टर 4.0 के पिछले संस्करण, यह लेनदेन को सीमित करता है <2GiB जो आमतौर पर चर wsrep_max_ws_rows और wsrep_max_ws_size द्वारा नियंत्रित होता है। गैलेरा क्लस्टर 4.0 के बाद से, आप> 2GiB लेनदेन भेज सकते हैं लेकिन आपको यह निर्धारित करना होगा कि प्रतिकृति के दौरान टुकड़ों को कितना बड़ा संसाधित करना है। इसे सत्र द्वारा सेट किया जाना है और केवल वेरिएबल जिन्हें आपको ध्यान रखने की आवश्यकता है वे हैं wsrep_trx_fragment_unit और wsrep_trx_fragment_size। स्ट्रीमिंग प्रतिकृति को अक्षम करना आसान है क्योंकि wsrep_trx_fragment_size = 0 इसे सेट कर देगा। ध्यान दें कि, एक बड़े लेन-देन की नकल करने से स्लेव नोड्स (नोड्स जो वर्तमान सक्रिय-लेखक/मास्टर नोड के विरुद्ध प्रतिकृति कर रहे हैं) पर ओवरहेड भी होता है क्योंकि लॉग MySQL डेटाबेस में wsrep_streaming_log तालिका में लिखे जाएंगे।
एक और बात जो आप जोड़ सकते हैं, चूंकि आप बड़े लेन-देन के साथ काम कर रहे हैं, इसलिए यह विचारणीय है कि आपके लेन-देन को समाप्त होने में कुछ समय लग सकता है, इसलिए चर innodb_lock_wait_timeout उच्च को ध्यान में रखा जाना चाहिए। इसे सत्र के माध्यम से उस समय के आधार पर सेट करें जो आप अनुमान लगाते हैं लेकिन उस समय से बड़ा है जब आप इसे समाप्त करने का अनुमान लगाते हैं, अन्यथा एक टाइमआउट बढ़ाएं।
हम अनुशंसा करते हैं कि आप कार्रवाई में प्रतिकृति स्ट्रीमिंग के बारे में यह पिछला ब्लॉग पढ़ें।
अनुदान विवरण को दोहराना
यदि आप GRANTs का उपयोग कर रहे हैं और संबंधित संचालन डेटाबेस `mysql` में MyISAM/Aria तालिकाओं पर कार्य करते हैं। GRANT विवरण दोहराए जाएंगे, लेकिन अंतर्निहित तालिकाएं नहीं होंगी. तो इसका मतलब है, INSERT INTO mysql.user ... को दोहराया नहीं जाएगा क्योंकि टेबल MyISAM है।
हालाँकि, उपरोक्त अब सत्य नहीं हो सकता है क्योंकि Percona XtraDB क्लस्टर (PXC) 8.0 (वर्तमान में प्रायोगिक) के रूप में mysql स्कीमा तालिकाओं को InnoDB में बदल दिया गया है, जबकि MariaDB 10.4 में, कुछ तालिकाएँ अभी भी हैं एरिया प्रारूप में लेकिन अन्य सीएसवी या इनो डीबी में हैं। आपको यह निर्धारित करना चाहिए कि आपके पास गैलेरा का कौन सा संस्करण और प्रदाता है लेकिन MySQL स्कीमा को संदर्भित करने वाले डीएमएल कथनों का उपयोग करने से बचने के लिए सबसे अच्छा है। अन्यथा, आप अप्रत्याशित परिणामों पर समाप्त हो सकते हैं जब तक कि आप सुनिश्चित न हों कि यह पीएक्ससी 8.0 है।
XA लेन-देन, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK समर्थित नहीं हैं
गैलेरा क्लस्टर एक्सए लेनदेन का समर्थन नहीं करता है क्योंकि एक्सए लेनदेन रोलबैक को संभालता है और अलग तरीके से करता है। LOCK/UNLOCK या GET_LOCK/RELEASE_LOCK कथन गैलेरा के साथ लागू या उपयोग किए जाने के लिए खतरनाक हैं। आप एक दुर्घटना या ताले का अनुभव कर सकते हैं जो मारने योग्य नहीं हैं और बंद रहते हैं। उदाहरण के लिए,
---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
mysql tables in use 2, locked 2
3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5यह लेन-देन पहले ही अनलॉक किया जा चुका है और यहां तक कि मार भी दिया गया है लेकिन कोई फायदा नहीं हुआ। हमारा सुझाव है कि आपको अपने एप्लिकेशन क्लाइंट को फिर से डिज़ाइन करना होगा और गैलेरा क्लस्टर में माइग्रेट करते समय इन कार्यों से छुटकारा पाना होगा।
नेटवर्क स्थिरता जरूरी है!!!
गैलेरा क्लस्टर बिना किसी समस्या के इंटर-वैन टोपोलॉजी या इंटर-जियो टोपोलॉजी के साथ भी काम कर सकता है (गैलेरा के साथ इंटर-जियो टोपोलॉजी को लागू करने के बारे में इस ब्लॉग को देखें)। हालाँकि, यदि प्रत्येक नोड के बीच आपका नेटवर्क कनेक्टिविटी स्थिर नहीं है या किसी अप्रत्याशित समय के लिए रुक-रुक कर नीचे जा रहा है, तो यह क्लस्टर के लिए समस्याग्रस्त हो सकता है। यह सबसे अच्छा है कि आपके पास एक निजी और स्थानीय नेटवर्क में चलने वाला क्लस्टर है जहां इनमें से प्रत्येक नोड जुड़ा हुआ है। एक नोड को डिजास्टर रिकवरी के रूप में डिजाइन करते समय, एक क्लस्टर बनाने की योजना बनाएं यदि ये एक अलग क्षेत्र या भूगोल पर हैं। आप हमारे पिछले ब्लॉग को पढ़ना शुरू कर सकते हैं, भू-वितरित क्लस्टर बनाने के लिए MySQL गैलेरा क्लस्टर प्रतिकृति का उपयोग करना:भाग एक क्योंकि यह आपको अपने गैलेरा क्लस्टर टोपोलॉजी को तय करने में सबसे अच्छी मदद कर सकता है।
अपने नेटवर्क हार्डवेयर में निवेश करने के बारे में जोड़ने के लिए एक और बात, यह समस्याग्रस्त होगा यदि आपका नेटवर्क स्थानांतरण दर आपको आईएसटी के दौरान एक उदाहरण के पुनर्निर्माण के दौरान कम गति प्रदान करता है या एसएसटी में बदतर है, खासकर यदि आपका डेटा सेट बहुत बड़ा है . इसमें नेटवर्क स्थानांतरण के लंबे घंटे लग सकते हैं और यह आपके क्लस्टर की स्थिरता को प्रभावित कर सकता है, खासकर यदि आपके पास 3-नोड क्लस्टर है, जबकि 2 नोड उपलब्ध नहीं हैं जहां ये 2 डोनर और जॉइनर हैं। ध्यान दें कि, एसएसटी चरण के दौरान, डोनर/जॉइनर नोड्स का उपयोग तब तक नहीं किया जा सकता जब तक कि यह अंततः प्राथमिक क्लस्टर के साथ सिंक करने में सक्षम न हो जाए।
गैलेरा के पिछले संस्करण में, जब डोनर नोड चयन की बात आती है, तो स्टेट स्नैपशॉट ट्रांसफर (एसएसटी) डोनर को यादृच्छिक रूप से चुना गया था। Glera 4 में, इसमें बहुत अधिक सुधार हुआ है और क्लस्टर के भीतर सही दाता चुनने की क्षमता है, क्योंकि यह एक ऐसे दाता का पक्ष लेगा जो एक वृद्धिशील राज्य स्थानांतरण (IST) प्रदान कर सकता है, या उसी खंड में एक दाता चुन सकता है। वैकल्पिक रूप से, आप wsrep_sst_donor वैरिएबल को सही डोनर पर सेट कर सकते हैं जिसे आप हमेशा चुनना चाहेंगे।
अपने डेटा का बैकअप लें और माइग्रेशन के दौरान और उत्पादन से पहले कठोर परीक्षण करें
एक बार जब आप तैयार हो जाएं और अपने डेटा को गैलेरा क्लस्टर 4.0 में माइग्रेट करने का प्रयास करने का निर्णय ले लें, तो सुनिश्चित करें कि आपके पास हमेशा अपना बैकअप तैयार है। यदि आपने ClusterControl को आजमाया है, तो बैकअप लेना ऐसा करना आसान हो जाएगा।
सुनिश्चित करें कि आप InnoDB के सही संस्करण में माइग्रेट कर रहे हैं और परीक्षण करने से पहले हमेशा mysql_upgrad को लागू करना और चलाना न भूलें। सुनिश्चित करें कि आपके सभी परीक्षण वांछित परिणाम पास करते हैं जिससे MySQL प्रतिकृति आपको पेश कर सकती है। सबसे अधिक संभावना है, जब तक अनुशंसाओं और युक्तियों को पहले से लागू और तैयार किया गया है, तब तक आपके द्वारा MySQL प्रतिकृति क्लस्टर बनाम MySQL गैलेरा क्लस्टर में उपयोग किए जा रहे InnoDB स्टोरेज इंजन में कोई अंतर नहीं है।
निष्कर्ष
गैलेरा क्लस्टर 4.0 में माइग्रेट करना आपका वांछित डेटाबेस प्रौद्योगिकी समाधान नहीं हो सकता है। हालांकि, जब तक इसकी विशिष्ट आवश्यकताओं को तैयार, सेटअप और प्रदान किया जा सकता है, तब तक यह आपको गैलेरा क्लस्टर 4.0 का उपयोग करने के लिए दूर नहीं खींच रहा है। गैलेरा क्लस्टर 4.0 अब विशेष रूप से अत्यधिक उपलब्ध प्लेटफॉर्म और समाधान पर एक बहुत शक्तिशाली व्यवहार्य विकल्प और विकल्प बन गया है। हम यह भी सुझाव देते हैं कि आप गैलेरा कैविट्स या गैलेरा क्लस्टर की सीमाओं या मारियाडीबी के इस मैनुअल के बारे में इन बाहरी ब्लॉगों को पढ़ें।
