सभी को नमस्कार!
आज हम इस बारे में बात करेंगे कि MySQL Master-Master प्रतिकृति किस तरह के कार्यों के लिए वास्तव में उपयोगी है, जिसके लिए यह पूरी तरह से बेकार और हानिकारक है, क्या मिथक और गलत धारणाएं इसके साथ जुड़ी हुई हैं और इस तकनीक से कौन से व्यावहारिक लाभ जल्दी प्राप्त किए जा सकते हैं। मैं विन्यास और वास्तुकला आरेखों के विशिष्ट उदाहरण दूंगा।
MySQL मास्टर-मास्टर प्रतिकृति के बारे में बात करना - उच्च उपलब्धता और प्रदर्शन के संदर्भों में - फैशनेबल है, लेकिन, दुर्भाग्य से, कई लोग इसके सार और प्रौद्योगिकी से जुड़ी गंभीर सीमाओं को नहीं समझते हैं।
शास्त्रीय MySQL में शुरू करने के लिए, कोई "वास्तविक" मास्टर-मास्टर प्रतिकृति अभी तक नहीं है :-) लेकिन अगर आप कोशिश करते हैं, तो आप अभी भी डेटा सेंटर की विफलता की स्थिति में एक प्रभावी उत्तरजीविता योजना स्थापित कर सकते हैं और अपनी खुशी का हिस्सा प्राप्त कर सकते हैं।
मास्टर-मास्टर सेटअप
यह ज्ञात है कि मास्टर-मास्टर को कॉन्फ़िगर करने के लिए आपको IDshnikov ऑफसेट को कॉन्फ़िगर करने और प्रत्येक सर्वर के लिए अपना विशिष्ट पहचानकर्ता सेट करने की आवश्यकता है:
प्रक्रिया नेटवर्क पर विस्तार से वर्णित है, यह बस और जल्दी से किया जाता है ... लेकिन यह केवल पहली बार में सरल है। वास्तव में, सफलता के रास्ते पर, हम कई लाशों, आश्चर्य और नुकसान पाएंगे :-)
नीचे पंक्ति: आपने स्वयं दो सर्वरों पर MySQL मास्टर-मास्टर कॉन्फ़िगर किया है और आगे समझने के लिए तैयार हैं।
समय
आपको एक बार और सभी के लिए स्पष्ट रूप से समझने की आवश्यकता है कि क्लासिक MySQL प्रतिकृति असिंक्रोनस है (संस्करण 5.6 में, SEM-सिंक्रोनस प्रतिकृति के लिए समर्थन दिखाई दिया,
एसईएम आवंटित किया गया है, क्योंकि यह अब तक पूरी तरह से तुल्यकालिक नहीं है)।
सिद्धांत के साथ नरक में, आइए देखें कि हम अतुल्यकालिक प्रतिकृति के साथ क्या सामना कर रहे हैं। डेटाबेस के बीच डेटा एक मनमाना देरी (मिलीसेकंड से दिनों तक) के साथ प्रेषित होता है। स्लेव के साथ मास्टर-स्लेव आर्किटेक्चर के लिए, आप केवल 30 सेकंड, इसके द्वारा आवेदन के पीछे के डेटा को नहीं पढ़ सकते हैं। लेकिन मास्टर-मास्टर के लिए, सब कुछ बदतर है - हमारे पास नहीं है और नहीं होगा (यहां तक कि एसईएम-तुल्यकालिक प्रतिकृति के मामले में) कोई गारंटी नहीं है कि डेटाबेस की प्रतियां तुल्यकालिक हैं। यानी प्रत्येक डेटाबेस पर एक ही क्वेरी को अलग-अलग तरीके से किया जा सकता है। और आज्ञाओं का एक साथ निष्पादन:
UPDATE mytable SET mycol=mycol+1; - UPDATE mytable SET mycol=mycol*3; -
दोनों डेटाबेसों में सिंक से डेटा बाहर ले जाएगा (
कोड और
दिनांक हमें माफ कर सकते हैं)।
समान यूनिक कॉलम मान (ऑटो-इन्क्रिमेंट नहीं!) की एक साथ प्रविष्टि, दोनों डेटाबेस में गलती से रोकने के लिए प्रतिकृति का कारण होगा। ऐसे कई खौफनाक उदाहरण हैं।
और यद्यपि "ON DUPLICATE KEY UPDATE" जैसे समाधानों की सलाह दी जाती है, कभी-कभी त्रुटियों को अनदेखा कर दिया जाता है, आदि, और साथ ही साथ आवेदन को खोदते हुए, सामान्य ज्ञान बताता है कि ऐसे दृष्टिकोण फिसलन और अविश्वसनीय हैं।
मुझे लगता है, जाहिर है, आपके आवेदन के लिए किस तरह का पतन और असंगति हो सकती है।
नीचे पंक्ति: एक अतुल्यकालिक मास्टर-मास्टर का उपयोग एक साथ दोनों डेटाबेसों को लिखने के लिए जाने बिना कि नुकसान खतरनाक और अविश्वसनीय है और दुर्लभ मामलों में उपयोग किया जाता है।
जादू की अंगूठी
MySQL सर्वर को रिंग में एकीकृत करना तकनीकी रूप से संभव है। हालांकि, उपरोक्त समस्याएं और भी तीव्र हो जाती हैं - रिंग के साथ रिकॉर्ड के वितरण के साथ जुड़े गैर-निर्धारकवाद को जोड़ा जाता है: आप नोड 1 और 3 पर एक साथ अपडेट कर सकते हैं, और नोड 2 पर एक बार पास कर सकते हैं। प्रत्येक नोड पर क्या होता है, इसके बारे में सोचना डरावना है। और इस तरह की प्रतिकृति अर्थव्यवस्था को बनाए रखने के लिए एक "पूर्ण आनंद" है, एक सिस्टम प्रशासक का एक बुरा सपना।
MySQL तुल्यकालिक प्रतिकृति समर्थन
अब, वास्तविक तुल्यकालिक मास्टर-मास्टर प्रतिकृति के संदर्भ में (जब डेटा अखंडता की गारंटी दी जाती है और आप एक साथ सभी क्लस्टर नोड्स के लिए लिख सकते हैं),
गलेरा के बारे में बहुत बात है। कोई कहेगा कि इसके लिए आप लंबे समय से ज्ञात
MySQL NDB क्लस्टर का उपयोग करने का प्रयास कर सकते हैं - लेकिन यह व्यापक रूप से ज्ञात है कि यह "जाइरोप्लेन" अनुप्रयोगों की एक बहुत ही संकीर्ण सर्कल के अनुरूप है, शायद ही कभी वेब की दुनिया से।
हम रुचि के साथ
गलेरा का अनुसरण कर रहे हैं - यह संभव है कि यह इस पर होगा कि भविष्य में वास्तविक मास्टर-मास्टर क्लस्टर बनाए जाएंगे, लेकिन अब हम देखते हैं कि मौजूदा अच्छी तरह से परीक्षण किए गए स्थिर टूल से क्या सीखा जा सकता है।
अतुल्यकालिक MySQL मास्टर-मास्टर प्रतिकृति के लाभ
हालांकि, सब कुछ इतना दुखद नहीं है। कोई फर्क नहीं पड़ता कि कैसे के लिए क्लासिक MySQL मास्टर-दास प्रतिकृति डांटा:
- एसिंक्रोनसी (नोड्स, लैग्स पर डेटा डेसिंक ...)
- अपर्याप्त विश्वसनीयता (flush_log_at_trx_commit = 1, Sync_binlog = 1, Sync_relay_log = 1, Sync_relay_log_info = 1, Sync_master_info = 1, कभी-कभी यह पर्याप्त नहीं होता है, और सर्वर के पुनः आरंभ होने पर प्रतिकृति विफल हो जाती है)
- अपर्याप्त लेन-देन का समर्थन (पेरकोना सर्वर पैच के लिए धन्यवाद जिसमें यह सुविधा लागू की गई है)
यह "वर्कहॉर्स" बहुत व्यापक रूप से उपयोग किया जाता है और सिस्टम प्रशासकों के लिए बहुत सारे लाभ और खुशी लाता है:
- एक गर्म "लगभग" अप-टू-डेट बैकअप बनाने के लिए
- MySQL दासों के साथ रीडिंग को क्लस्टर करने के लिए
- वर्टिकल शार्डिंग के लिए (हम फिल्टर करते हैं कि कौन सी टेबल को किस दास को स्थानांतरित करना है)
- डेटाबेस लड़ाई सर्वर लोड किए बिना mysqldump का उपयोग करके दास सर्वर को सुरक्षित रूप से बैकअप करने के लिए
- और अन्य
अतुल्यकालिक मास्टर-मास्टर प्रतिकृति को जल्दी से "उपयोगी घोड़े" में बदल दिया जा सकता है। आमतौर पर इस वास्तुकला को मास्टर-मास्टर (एक्टिव-पैसिव) कहा जाता है:
विचार सरल हैं: हम एक डेटाबेस में लिखते हैं, दूसरे का उपयोग एक हॉट बैकअप के रूप में किया जाता है, जिसमें आप यदि आवश्यक हो, तुरंत क्लिक कर सकते हैं! यह "जल्दी से डेटा लिखना शुरू कर रहा है" जो इस वास्तुकला को ऐसी उपयोगिता और उच्चता प्रदान करता है।
थोड़ा धूम्रपान किया ...
थोड़ा धूम्रपान करने और सोचने के बाद, आप इस "वर्कहॉर्स" का एक और अद्भुत अनुप्रयोग देख सकते हैं - एक स्थानीय डेटा सेंटर में दुर्घटना का सामना करने की क्षमता। आपको बस एक अन्य डेटा सेंटर में मास्टर-मास्टर (एक्टिव-पैसिव) में गर्म डेटाबेस रखने की आवश्यकता है, आप किसी अन्य महाद्वीप पर कर सकते हैं:
हां, मैं देख रहा हूं कि जलते हुए डेटा सेंटर में तीर की जरूरत नहीं है, लेकिन इसे छवि धारणा अखंडता के लिए छोड़ दें :-)
ठीक है, तो कोई भी हमें इस वास्तुकला पर रीडिंग को स्केल करने के लिए मना नहीं करता है, जो डेटा सेंटर के लिए एक क्लस्टर स्थानीय प्राप्त करता है:
बस
दास सर्वर के लिए विज़ार्ड पर लॉगिंग अपडेट के
विकल्प को सक्षम करने के लिए मत भूलना।
जोखिम
ईमानदारी से, इस तरह की प्रतिकृति योजना काफी भरोसेमंद रूप से काम करती है और हम इसे सफलतापूर्वक
अमेज़न क्लाउड में बिट्रिक्स 24 पर और
"भौगोलिक वेब क्लस्टर" समाधान में उपयोग करते हैं। इसके संचालन की विशेषताएं इस प्रकार हैं:
- स्टेटमेंट-आधारित प्रतिकृति मोड में शुरू करें। यदि संदेश MySQL लॉग में दिखाई देते हैं कि इस मोड में इस क्वेरी को निष्पादित करना खतरनाक है, क्योंकि स्लेव पर इसके निष्पादन का क्रम अलग हो सकता है - "मिश्रित" प्रतिकृति मोड को सक्षम करें (इसके लिए इनोबीडी में लेनदेन अलगाव मोड को दोहराने योग्य पढ़ने में वृद्धि की आवश्यकता हो सकती है)। मैं पंक्ति-आधारित सहित अनुशंसा नहीं करता।
- यदि आप प्रदर्शन के बारे में चिंतित हैं, तो आप संभवतः पैरामीटर शामिल नहीं करेंगे: flush_log_at_at_trx_commit = 1, Sync_binlog = 1, Sync_relay_log = 1, Sync_relay_log_info = 1, Sync_master_info = 1 (व्यंग्य :-))। इसका मतलब है कि आपको MySQL इमरजेंसी रिस्टार्ट होने के बाद कभी-कभी मैन्युअल रूप से रीप्लेसमेंट उठाने की आवश्यकता होगी - मैना के साथ mysqlbinlog कमांड को स्मोक करें, आप बहुत सारी रोचक और उपयोगी चीजें पा सकते हैं।
- जब तक आप एक तरफ प्रतिकृति को नहीं बढ़ाते हैं, तब तक बैलेंसर को वापस स्विच न करने का प्रयास करें - अन्यथा, डेटा के साथ एक गड़बड़ शुरू हो सकती है (और दूसरी बार कोडड और दिनांक अब माफ नहीं कर सकते हैं :-))।
"और खाद?"
डीसी के बीच सामग्री के सिंक्रनाइज़ेशन के बारे में भूल गए। सब कुछ मूल रूप से यहाँ मानक है:
गुब्बारे फ़ाइलों के लिए
क्लाउड स्टोरेज -
Clodo.ru ,
Selectel.ru , Amazon S3, Google Storage और अन्य। सीडीएन का गहन उपयोग। Csync2, rsync और इसी तरह के अन्य उपकरणों का उपयोग करके DC के बीच स्थैतिक स्थानांतरण। आमतौर पर कोई समस्या नहीं है।
इस विषय पर क्या पढ़ा जाए
यह लाइन
-हा परियोजना को देखने के लायक है और, जाहिरा तौर पर, यह बैश पर आसान बना देता है ;-)
गैलेरा बहुत आशाजनक दिखता है। चलिए यह भी उम्मीद करते हैं कि MySQL अंततः "वास्तविक" मास्टर-मास्टर प्रतिकृति बना देगा ताकि आज मांग में हो।
और हां, मैं पूरी तरह से भूल गया - डेटा अभी भी मास्टर-मास्टर (एक्टिव-पैसिव) के बीच सिंक से बाहर हो सकता है। यह mysql के दुर्घटनाग्रस्त होने के कारण होता है, सर्वर का अचानक रिबूट, प्रतिकृति स्थिति का नुकसान, इसके कोड में त्रुटियां। यह ठीक है, एक इलाज है - अधिक जटिल:
और इस सरल बैश स्क्रिप्ट की तरह सरल (बड़े तालिकाओं पर उपयोग न करें):
परिणाम
Bitrix24 परियोजना में, हम वर्णित तकनीक का गहनता से उपयोग करते हैं - और इससे हमें एक से अधिक बार मदद मिली है। इस वर्ष के 15 जून को अमेज़न में डेटा सेंटर में अंतिम गिरावट ग्राहकों द्वारा किसी का ध्यान नहीं गया - हमने स्वचालित रूप से एक और डीसी में बैकअप मास्टर पर स्विच किया।
लेख में, हमने अलमारियों पर MySQL मास्टर-मास्टर विषय को हल किया, ताकि भविष्य में हम इस तकनीक में छिपे हुए अर्थ की तलाश न करें। हमने शुद्ध नुकसान पर खतरनाक और खराब तरीके से जांच की। उन्होंने मास्टर-मास्टर (एक्टिव-पैसिव) के लिए एक और डेटा सेंटर (दूसरे महाद्वीप पर) में एक हॉट MySQL मास्टर-सर्वर प्रदान करने के लिए एक सरल और व्यावहारिक एप्लीकेशन चुना और अब sysdamin को बिना किसी डर के छुट्टी पर लिया जा सकता है कि सभी प्रतिकृति नोड्स का डेटा अलग होगा (अब नहीं है) मैं रिलेशनल सिद्धांत के संस्थापकों के पिता के नाम का उल्लेख करता हूं) या डेटा सेंटर पर बिजली गिरती है :-) हर किसी को शुभकामनाएं, अच्छा मूड और विश्वसनीय प्रतिकृति!