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

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

वीआईपी पर आधारित एचए समाधान

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

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

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

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

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

आगे बढ़ने से पहले आपको इस समाधान के बारे में क्या जानना आवश्यक है:

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

आइए हमारे विज़ार्ड के साथ संभावित समस्याओं को देखें और कल्पना करें कि स्वचालित पुनर्प्राप्ति तंत्र को कैसे काम करना चाहिए।

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

1. ऑर्केस्ट्रेटर क्लस्टर टोपोलॉजी को अद्यतन करता है, प्रत्येक प्रतिकृति रिपोर्ट करती है कि मास्टर अनुपलब्ध है। ऑर्केस्ट्रेटर नए मास्टर की भूमिका के लिए उपयुक्त प्रतिकृति का चयन करने की प्रक्रिया शुरू करता है और पुनर्प्राप्ति शुरू करता है।
2. हम पुराने स्वामी से वीआईपी को हटाने का प्रयास कर रहे हैं - बिना सफलता के।
3. प्रतिकृति मास्टर की भूमिका में बदल जाती है। टोपोलॉजी का पुनर्निर्माण किया जा रहा है।
4. VIP के साथ एक नया नेटवर्क इंटरफ़ेस जोड़ा जा रहा है। चूंकि वीआईपी को हटाना संभव नहीं था, इसलिए हम समय-समय पर पृष्ठभूमि में एक अनुरोध भेजना शुरू करते हैं निःशुल्क एआरपी. इस प्रकार का अनुरोध/प्रतिक्रिया आपको कनेक्टेड स्विच पर आईपी और मैक एड्रेस मैपिंग टेबल को अपडेट करने की अनुमति देता है, जिससे आपको सूचित किया जाता है कि हमारा वीआईपी स्थानांतरित हो गया है। इससे संभावना कम हो जाती है split brain पुराने स्वामी को लौटाते समय।
5. सभी नए कनेक्शन तुरंत नए मास्टर पर पुनर्निर्देशित कर दिए जाते हैं। पुराने कनेक्शन विफल हो जाते हैं और एप्लिकेशन स्तर पर डेटाबेस पर बार-बार कॉल की जाती है।

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

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

अन्य समस्याएं

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

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

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

HA समाधान का सामान्य आरेख नीचे प्रस्तुत किया गया है।

एक नया मास्टर चुनना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निष्कर्ष

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

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

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

• HA योजना को कई डेटा केंद्रों तक बढ़ाने के लिए उनके बीच एक एकल L2 नेटवर्क की आवश्यकता होगी;
• नए मास्टर पर वीआईपी असाइन करने से पहले, हमें इसे पुराने मास्टर पर जारी करना होगा। प्रक्रिया अनुक्रमिक है, जिससे पुनर्प्राप्ति समय बढ़ जाता है;
• वीआईपी जारी करने के लिए सर्वर तक एसएसएच पहुंच, या दूरस्थ प्रक्रियाओं को कॉल करने की किसी अन्य विधि की आवश्यकता होती है। चूँकि सर्वर या डेटाबेस में समस्याएँ आ रही हैं जिसके कारण पुनर्प्राप्ति प्रक्रिया हुई, हम यह सुनिश्चित नहीं कर सकते कि वीआईपी निष्कासन सफलतापूर्वक पूरा हो जाएगा। और इससे एक ही वर्चुअल आईपी पते वाले दो सर्वर सामने आ सकते हैं और एक समस्या हो सकती है split brain.

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

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

स्रोत: www.habr.com