MySQL के लिए ऑर्केस्ट्रेटर: आप इसके बिना दोष-सहिष्णु प्रोजेक्ट क्यों नहीं बना सकते

कोई भी बड़ा प्रोजेक्ट दो सर्वर से शुरू होता है। पहले एक DB सर्वर था, फिर रीडिंग स्केल करने के लिए उसमें स्लेव जोड़े गए। और फिर - रुको! एक मास्टर है, लेकिन कई स्लेव हैं; अगर एक स्लेव चला जाता है, तो सब कुछ ठीक रहेगा, लेकिन अगर मास्टर चला जाता है - तो यह बुरा होगा: डाउनटाइम, एडमिन अपने साबुन के बुलबुले में सर्वर को चालू कर देते हैं। क्या करें? मास्टर का बैकअप लें। मेरे सहयोगी पावेल ने पहले ही इस बारे में लिखा है लेख, मैं इसे दोहराऊंगा नहीं। इसके बजाय, मैं आपको बताऊंगा कि आपको MySQL के लिए ऑर्केस्ट्रेटर की ज़रूरत क्यों है!

आइये मुख्य प्रश्न से शुरू करें: "मास्टर के चले जाने पर हम कोड को नई मशीन में कैसे स्थानांतरित करेंगे?"

• मुझे VIP (वर्चुअल IP) योजना सबसे ज़्यादा पसंद है, हम इसके बारे में नीचे बात करेंगे। यह सबसे सरल और सबसे स्पष्ट है, हालाँकि इसकी एक स्पष्ट सीमा है: जिस मास्टर का हम बैकअप लेंगे, वह नई मशीन के साथ L2 सेगमेंट में होना चाहिए, यानी हम दूसरे DC के बारे में भूल सकते हैं। और, एक अच्छे तरीके से, यदि आप इस नियम का पालन करते हैं कि एक बड़ा L2 बुरा है, क्योंकि L2 केवल रैक के लिए है, और रैक के बीच L3 है, और ऐसी योजना की और भी सीमाएँ हैं।
• आप कोड में DNS नाम लिख सकते हैं और इसे /etc/hosts के माध्यम से हल कर सकते हैं। वास्तव में, कोई समाधान नहीं होगा। योजना का लाभ: पहली विधि के लिए कोई सीमा नहीं है, यानी आप क्रॉस-डीसी का आयोजन कर सकते हैं। लेकिन फिर स्पष्ट प्रश्न उठता है: हम Puppet-Ansible के माध्यम से /etc/hosts में कितनी जल्दी बदलाव ला सकते हैं?
• दूसरी विधि को थोड़ा संशोधित किया जा सकता है: सभी वेब सर्वर पर हम एक कैशिंग DNS स्थापित करते हैं, जिसके माध्यम से कोड मास्टर डेटाबेस में जाएगा। आप DNS में इस प्रविष्टि के लिए TTL 60 निर्दिष्ट कर सकते हैं। ऐसा लगता है कि अगर सही तरीके से लागू किया जाए तो यह विधि अच्छी है।
• सेवा खोज के साथ एक योजना, जो कंसुल और etcd के उपयोग को दर्शाती है।
• दिलचस्प विकल्प प्रॉक्सीएसक्यूएलMySQL के सभी ट्रैफ़िक को ProxySQL के माध्यम से लपेटा जाना चाहिए, ProxySQL स्वयं निर्धारित कर सकता है कि अब मास्टर कौन है। वैसे, आप इस उत्पाद का उपयोग करने के विकल्पों में से एक के बारे में मेरे में पढ़ सकते हैं लेख.

गिटहब पर काम कर रहे ऑर्केस्ट्रेटर के लेखक ने पहले वीआईपी के साथ पहली योजना को लागू किया, और फिर इसे कॉन्सल के साथ योजना में परिवर्तित कर दिया।

विशिष्ट बुनियादी ढांचा योजना:

मैं तुरंत उन स्पष्ट स्थितियों का वर्णन करूंगा जिन पर ध्यान देने की आवश्यकता है:

• किसी भी सर्वर पर कॉन्फ़िगरेशन में VIP पता निर्दिष्ट नहीं किया जाना चाहिए। आइए एक स्थिति की कल्पना करें: मास्टर रिबूट हुआ, और जब यह लोड हो रहा था, ऑर्केस्ट्रेटर फ़ेलओवर मोड में चला गया और स्लेव में से एक को मास्टर बना दिया; फिर पुराना मास्टर आया, और अब VIP दो मशीनों पर है। यह बुरा है।
• ऑर्केस्ट्रेटर के लिए, आपको पुराने मास्टर और नए मास्टर से संपर्क करने के लिए एक स्क्रिप्ट लिखनी होगी। पुराने मास्टर पर, आपको ifdown चलाना होगा, और नए मास्टर पर, ifup vip। इस स्क्रिप्ट में यह भी शामिल करना अच्छा होगा कि फ़ेलओवर के मामले में, किसी भी स्प्लिटब्रेन से बचने के लिए पुराने मास्टर के स्विच पर पोर्ट को बस बुझा दिया जाता है।
• ऑर्केस्ट्रेटर द्वारा आपकी स्क्रिप्ट को कॉल करने के बाद सबसे पहले VIP को हटा दें और/या स्विच पर पोर्ट को बंद कर दें, और फिर नए मास्टर पर VIP-अप स्क्रिप्ट को कॉल करें, सभी को यह बताने के लिए arping करना न भूलें कि नया VIP अब यहाँ है।
• सभी स्लेव का read_only=1 होना चाहिए, और जैसे ही आप किसी स्लेव को मास्टर में प्रोन्नत करते हैं, उसका read_only=0 होना चाहिए।
• यह मत भूलिए कि इसके लिए हमने जो भी स्लेव चुना है, वह मास्टर बन सकता है (ऑर्केस्ट्रेटर में एक पूरी वरीयता प्रणाली है, किस स्लेव को नए मास्टर के लिए पहले उम्मीदवार के रूप में माना जाए, किसे दूसरे, और किस स्लेव को किसी भी परिस्थिति में मास्टर के रूप में नहीं चुना जाना चाहिए)। यदि कोई स्लेव मास्टर बन जाता है, तो उस पर स्लेव लोड बना रहेगा और मास्टर लोड जुड़ जाएगा, इसका ध्यान रखना चाहिए।

यदि आपके पास ऑर्केस्ट्रेटर नहीं है तो आपको इसकी आवश्यकता क्यों है?

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

ऑर्केस्ट्रेटर इंटरफ़ेस:

जीटीआईडी ​​त्रुटिपूर्ण क्या है?

ऑर्केस्ट्रेटर के काम करने के लिए दो मुख्य आवश्यकताएं हैं:

• यह आवश्यक है कि MySQL क्लस्टर में सभी मशीनों पर छद्म GTID सक्षम हो; हमारे पास GTID सक्षम है।
• यह आवश्यक है कि हर जगह एक प्रकार का बिनलॉग हो, कथन संभव है। हमारे पास ऐसा कॉन्फ़िगरेशन था, जिसमें मास्टर और अधिकांश स्लेव में रो था, और दो ऐतिहासिक रूप से मिश्रित मोड में बने रहे। नतीजतन, ऑर्केस्ट्रेटर बस इन स्लेव को नए मास्टर से कनेक्ट नहीं करना चाहता था।

याद रखें कि प्रोडक्शन स्लेव के बारे में सबसे महत्वपूर्ण बात मास्टर के साथ इसकी संगति है! यदि आपने मास्टर और स्लेव दोनों पर ग्लोबल ट्रांजेक्शन आईडी (GTID) सक्षम किया है, तो आप gtid_subset फ़ंक्शन का उपयोग करके यह पता लगा सकते हैं कि क्या इन मशीनों पर वास्तव में समान डेटा परिवर्तन अनुरोध निष्पादित किए गए हैं। आप इसके बारे में अधिक पढ़ सकते हैं यहां.

तो ऑर्केस्ट्रेटर आपको GTID त्रुटि के माध्यम से दिखाता है कि स्लेव पर ऐसे लेनदेन हैं जो मास्टर पर नहीं हैं। ऐसा क्यों होता है?

• स्लेव में read_only=1 सक्षम नहीं है, किसी ने कनेक्ट किया और डेटा बदलने का अनुरोध किया।
• स्लेव में super_read_only=1 सक्षम नहीं है, इसलिए एडमिन ने सर्वर को भ्रमित करते हुए, वहां जाकर अनुरोध निष्पादित कर दिया।
• यदि आपने पिछले दोनों बिंदुओं को ध्यान में रखा है, तो एक और तरकीब है: MySQL में, बिनलॉग को फ्लश करने का अनुरोध भी बिनलॉग में चला जाता है, इसलिए मास्टर और सभी स्लेव पर पहला फ्लश GTID त्रुटिपूर्ण हो जाएगा। इससे कैसे बचें? पेरोना-5.7.25-28 में, एक सेटिंग binlog_skip_flush_commands=1 दिखाई दी, जो बिनलॉग में फ्लश लिखने पर रोक लगाती है। mysql.com वेबसाइट पर एक सेट अप है बग.

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

स्पष्ट प्रश्न यह है: "ऑर्केस्ट्रेटर को कैसे काम करना चाहिए?" इसे वर्तमान स्लेव से एक नया मास्टर चुनना चाहिए, और फिर सभी स्लेव को फिर से कनेक्ट करना चाहिए (यही GTID के लिए है; यदि आप binlog_name और binlog_pos के साथ पुराने तंत्र का उपयोग करते हैं, तो वर्तमान मास्टर से एक स्लेव को नए में स्विच करना असंभव है!)। ऑर्केस्ट्रेटर से पहले, मुझे एक बार यह सब मैन्युअल रूप से करना पड़ा था। पुराना मास्टर बगी एडेप्टेक कंट्रोलर के कारण लटका हुआ था, इसमें लगभग 10 स्लेव थे। मुझे मास्टर से VIP को एक स्लेव में स्थानांतरित करना था और अन्य सभी स्लेव को फिर से कनेक्ट करना था। मुझे कितने कंसोल खोलने थे, मुझे कितने एक साथ कमांड दर्ज करने थे... मुझे सुबह 3 बजे तक इंतजार करना पड़ा, दो को छोड़कर सभी स्लेव से लोड हटाना पड़ा, दो में से पहली मशीन को मास्टर बनाना पड़ा, तुरंत दूसरी मशीन को उससे कनेक्ट करना पड़ा, फिर सभी अन्य स्लेव को नए मास्टर से कनेक्ट करना पड़ा और लोड वापस करना पड़ा। कुल मिलाकर, यह भयानक था...

ऑर्केस्ट्रेटर फेलओवर मोड में जाने पर कैसे काम करता है? इसे सबसे आसानी से उस स्थिति से समझा जा सकता है, जब हम मास्टर को मौजूदा मशीन से ज़्यादा शक्तिशाली, ज़्यादा आधुनिक मशीन बनाना चाहते हैं।

चित्र प्रक्रिया के मध्य को दर्शाता है। इस बिंदु तक क्या किया गया है? हमने कहा कि हम एक स्लेव को नया मास्टर बनाना चाहते हैं, ऑर्केस्ट्रेटर ने बस सभी अन्य स्लेव को फिर से कनेक्ट करना शुरू कर दिया, जिसमें नया मास्टर एक ट्रांजिट मशीन के रूप में कार्य करता है। इस योजना के साथ, कोई त्रुटि नहीं होती है, सभी स्लेव काम करते हैं, ऑर्केस्ट्रेटर पुराने मास्टर से वीआईपी को हटाता है, इसे नए में स्थानांतरित करता है, read_only=0 बनाता है और पुराने मास्टर के बारे में भूल जाता है। बस! हमारी सेवा का डाउनटाइम वीआईपी ट्रांसफर का समय है, जो 2-3 सेकंड है।

आज के लिए बस इतना ही, आप सभी का धन्यवाद। जल्द ही ऑर्केस्ट्रेटर के बारे में दूसरा लेख होगा। प्रसिद्ध सोवियत फिल्म "गैराज" में एक पात्र ने कहा "मैं उसके साथ टोही पर नहीं जाऊंगा!" खैर, ऑर्केस्ट्रेटर, मैं आपके साथ टोही पर जाऊंगा!

स्रोत: www.habr.com