MySQL के लिए ऑर्केस्ट्रेटर: इसके बिना एक असफल-सुरक्षित परियोजना क्यों नहीं बनाई जा सकती है

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

चलिए मुख्य प्रश्न से शुरू करते हैं: "विज़ार्ड को छोड़ने पर हम कोड को एक नई मशीन पर कैसे स्विच करेंगे?"

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

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

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

मैं तुरंत विचार करने के लिए स्पष्ट स्थितियों का वर्णन करूंगा:

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• सभी गुलामों के पास read_only = 1 होना चाहिए, और जैसे ही आप दास को गुरु के सामने प्रचारित करते हैं, उसे read_only = 0 होना चाहिए।
• यह मत भूलो कि इसके लिए हमने जो भी दास चुना है, वह एक मास्टर बन सकता है (ऑर्केस्ट्रेटर के पास वरीयता का एक पूरा तंत्र है, जिसे दास को पहले स्थान पर नए मास्टर के लिए उम्मीदवार माना जाना चाहिए, जो दूसरे में एक है, और किसी भी परिस्थिति में दास का चयन नहीं किया जाना चाहिए। गुरुजी)। यदि दास स्वामी बन जाता है, तो उस पर दास भार बना रहेगा और मास्टर लोड जोड़ा जाएगा, इसे ध्यान में रखा जाना चाहिए।

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

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

आर्केस्ट्रा इंटरफेस:

जीटीआईडी ​​क्या गलत है?

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

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

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

इस प्रकार, ऑर्केस्ट्रेटर आपको जीटीआईडी ​​के त्रुटिपूर्ण त्रुटि के माध्यम से दिखाता है कि दास पर लेनदेन हैं जो विज़ार्ड में नहीं हैं। ऐसा क्यों होता है?

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

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

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

फेलओवर मोड में प्रवेश करने पर ऑर्केस्ट्रेटर कैसे काम करता है? यह सबसे आसानी से एक ऐसी स्थिति के उदाहरण द्वारा दिखाया गया है जहां हम एक मास्टर को अब से अधिक शक्तिशाली, अधिक आधुनिक मशीन बनाना चाहते हैं।

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

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