CityMobile में, हम लगातार डेटा के लिए मुख्य भंडारण के रूप में MySQL डेटाबेस का उपयोग करते हैं। हमारे पास विभिन्न सेवाओं और उद्देश्यों के लिए कई डेटाबेस क्लस्टर हैं।

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

वीआईपी हा समाधान

सबसे पहले, मैं संक्षेप में बात करता हूं कि हमारी डेटा संग्रहण प्रणाली क्या है।

हम क्लासिक राइटिंग स्कीम का उपयोग एक राइट-ओनली विज़ार्ड और कई रीड-ओनली प्रतिकृतियों के साथ करते हैं। एक क्लस्टर में एक मध्यवर्ती मास्टर हो सकता है - एक नोड जो एक प्रतिकृति और दूसरों के लिए एक मास्टर दोनों है। ग्राहक HAProxy के माध्यम से प्रतिकृतियों का उपयोग करते हैं, जो लोड वितरण और आसान मापनीयता के लिए भी अनुमति देता है। HAProxy का उपयोग ऐतिहासिक कारणों के कारण है, और अब हम ProxySQL के लिए पलायन की प्रक्रिया में हैं।

प्रतिकृति अर्ध-समकालिक हैGTID। इसका मतलब यह है कि कम से कम एक प्रतिकृति को सफल समझे जाने से पहले लॉग को लेनदेन लिखना होगा। यह प्रतिकृति मोड मुख्य नोड की विफलता के मामले में प्रदर्शन और डेटा सुरक्षा के बीच एक इष्टतम संतुलन प्रदान करता है। मूल रूप से, सभी परिवर्तनों को मास्टर से प्रतिकृति का उपयोग करके स्थानांतरित किया जाता है Row Based Replication (RBR), लेकिन कुछ नोड्स हो सकते हैं mixed binlog format।

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

विफलता के मामले में एक विज़ार्ड को पुनर्स्थापित करने का सबसे आसान तरीका अस्थायी वीआईपी पते का उपयोग करना है।

आगे बढ़ने से पहले आपको इस समाधान के बारे में क्या जानना चाहिए:

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

हम अपने मास्टर के साथ संभावित समस्याओं पर विचार करेंगे और कल्पना करेंगे कि स्वचालित पुनर्प्राप्ति तंत्र को कैसे काम करना चाहिए।

मास्टर से नेटवर्क कनेक्टिविटी गायब हो गई है, या हार्डवेयर स्तर पर कोई समस्या आ गई है, और सर्वर अनुपलब्ध है

, . , , .
VIP — .
. .
VIP. VIP , gratuitous ARP. / IP- MAC-, VIP. split brain .
सभी नए कनेक्शन तुरंत नए मास्टर पर पुनर्निर्देशित किए जाते हैं। पुराने कनेक्शन विफल हो जाते हैं, बार-बार कॉल डेटाबेस स्तर पर किए जाते हैं।

सर्वर सामान्य मोड में चल रहा है; DBMS स्तर पर विफलता हुई

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

दूसरी समस्याएं

प्रतिकृतियां या मध्यवर्ती स्वामी की विफलता स्वचालित कार्यों के लिए नेतृत्व नहीं करती है और मैन्युअल हस्तक्षेप की आवश्यकता होती है।

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

पुनर्प्राप्ति प्रक्रिया के दौरान, समस्याएं उत्पन्न हो सकती हैं, जिसे मानक निगरानी उपकरणों के अलावा ऑर्केस्ट्रेटर के यूआई के माध्यम से भी सूचित किया जाना चाहिए। हमने इस सुविधा को जोड़कर REST API का विस्तार किया है ( PR वर्तमान में विचाराधीन है)।

हा समाधान की सामान्य योजना नीचे प्रस्तुत की गई है।

एक नया विज़ार्ड चुनना

ऑर्केस्ट्रा काफी स्मार्ट है और निम्नलिखित मानदंडों के अनुसार नए मास्टर के रूप में सबसे उपयुक्त प्रतिकृति चुनने की कोशिश करता है:

मास्टर से प्रतिकृति की अंतराल;
MySQL विज़ार्ड और प्रतिकृति संस्करण;
प्रतिकृति का प्रकार (आरबीआर, एसबीआर, या मिश्रित);
एक या अलग-अलग डेटा केंद्रों में स्थान;
उपलब्धता errant GTID- लेनदेन जो प्रतिकृति पर किए गए थे और मास्टर पर अनुपस्थित हैं;
कस्टम चयन नियमों को भी ध्यान में रखा जाता है।

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

प्रतिक्रिया और पुनर्प्राप्ति समय

किसी घटना की स्थिति में, सिस्टम डाउनटाइम को कम करना महत्वपूर्ण है, इसलिए, हम MySQL मापदंडों पर विचार करते हैं जो ऑर्केस्ट्रा द्वारा क्लस्टर टोपोलॉजी के निर्माण और अद्यतन को प्रभावित करते हैं:

slave_net_timeout- उस सेकंड की संख्या जिसके दौरान प्रतिकृति नए डेटा की प्रतीक्षा करती है या कनेक्शन खो जाने से पहले मास्टर से दिल की धड़कन का संकेत पहचान लिया जाता है और पुन: संयोजन किया जाता है। कम मूल्य, तेजी से प्रतिकृति यह निर्धारित करने में सक्षम होगी कि मास्टर के साथ संबंध टूट गया है। हमने यह मान 5 सेकंड के लिए सेट किया है।
MASTER_CONNECT_RETRY- पुनरावृत्ति प्रयासों के बीच सेकंड की संख्या। नेटवर्क समस्याओं के मामले में, इस पैरामीटर का एक कम मूल्य आपको क्लस्टर रिकवरी प्रक्रिया की शुरुआत को जल्दी से फिर से जोड़ने और रोकने की अनुमति देगा। अनुशंसित मूल्य 1 सेकंड है।
MASTER_RETRY_COUNT - पुन: कनेक्ट करने के प्रयासों की अधिकतम संख्या।
MASTER_HEARTBEAT_PERIOD- सेकंड में अंतराल जिसके बाद मास्टर एक दिल की धड़कन संकेत भेजता है। डिफ़ॉल्ट आधा मूल्य है slave_net_timeout।

ऑर्केस्ट्रेटर विकल्प:

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

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

परीक्षण स्टैंड

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

अभ्यास के दौरान, हम समस्या का अनुकरण करने के लिए तरीकों में से एक का चयन करते हैं: तुरंत विज़ार्ड को गोली मार दें kill -9, धीरे-धीरे प्रक्रिया को पूरा करें और सर्वर को बंद करें ( docker-compose stop), iptables -j REJECTया साथ नेटवर्क समस्याओं का अनुकरण करें iptables -j DROP। हम इन परिणामों की उम्मीद करते हैं:

ऑर्केस्ट्रा मास्टर के साथ समस्याओं का पता लगाएगा और 10 सेकंड से अधिक समय में टोपोलॉजी को अपडेट करेगा;
पुनर्प्राप्ति प्रक्रिया स्वचालित रूप से शुरू होगी: नेटवर्क कॉन्फ़िगरेशन बदल जाएगा, विज़ार्ड की भूमिका प्रतिकृति में जाएगी, टोपोलॉजी को फिर से बनाया जाएगा;
नया मास्टर रिकॉर्डिंग के लिए उपलब्ध होगा, लाइव प्रतिकृतियां पुनर्निर्माण की प्रक्रिया में खो नहीं जाएगी;
डेटा नए मास्टर को लिखा जाएगा और दोहराया जाएगा;
कुल पुनर्प्राप्ति समय 30 सेकंड से अधिक नहीं होगा।

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

जाँच - परिणाम

भंडारण प्रणाली के मुख्य नोड की संचालन क्षमता SRE टीम और संचालन के मुख्य कार्यों में से एक है। वीआईपी पर आधारित ऑर्केस्ट्रा और हा-समाधानों की शुरूआत निम्नलिखित परिणाम प्राप्त करने की अनुमति देती है:

डेटाबेस क्लस्टर की टोपोलॉजी के साथ समस्याओं का विश्वसनीय पता लगाने;
मास्टर से संबंधित घटनाओं के लिए स्वचालित और त्वरित प्रतिक्रिया, जो सिस्टम डाउनटाइम को कम करती है।

हालाँकि, समाधान की अपनी सीमाएँ और नुकसान हैं:

कई डेटा केंद्रों को हा योजना को स्केल करने के लिए उनके बीच एक एकल L2 नेटवर्क की आवश्यकता होगी;
इससे पहले कि आप नए मास्टर को वीआईपी असाइन करें, हमें उसे पुराने पर मुक्त करने की आवश्यकता है। प्रक्रिया अनुक्रमिक है, जो वसूली समय को बढ़ाती है;
VIP SSH- , . , , , VIP . IP- split brain.

बचने के लिए split brain, आप STONITH विधि ("हेड में अन्य नोड को गोली मारो") का उपयोग कर सकते हैं , जो समस्या नोड को पूरी तरह से अलग या डिस्कनेक्ट करता है। क्लस्टर की उच्च उपलब्धता को लागू करने के अन्य तरीके हैं: वीआईपी और डीएनएस, सेवा की खोज और प्रॉक्सी सेवाओं, सिंक्रोनस प्रतिकृति और अन्य तरीकों का एक संयोजन जिसमें उनकी कमियां और फायदे हैं।

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

MySQL क्लस्टर के लिए HA समाधान के रूप में आर्केस्ट्रा और वीआईपी