Citymobil मा हामी हाम्रो मुख्य निरन्तर डाटा भण्डारणको रूपमा MySQL डाटाबेस प्रयोग गर्छौं। हामीसँग विभिन्न सेवा र उद्देश्यका लागि धेरै डाटाबेस क्लस्टरहरू छन्।

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

HA समाधान VIP मा आधारित

पहिले, म तपाइँलाई छोटकरीमा हाम्रो डाटा भण्डारण प्रणाली के हो भनेर बताउनेछु।

हामी एक लेखन-पहुँचयोग्य मास्टर र बहु-पढ्न-मात्र प्रतिकृतिहरूको साथ क्लासिक प्रतिकृति योजना प्रयोग गर्छौं। क्लस्टरले मध्यवर्ती मास्टर समावेश गर्न सक्छ - एक नोड जुन प्रतिकृति र अरूको लागि मास्टर दुवै हो। ग्राहकहरूले HAProxy मार्फत प्रतिकृतिहरू पहुँच गर्छन्, जसले लोड वितरण र सजिलो स्केलिंगको लागि अनुमति दिन्छ। HAProxy को प्रयोग ऐतिहासिक कारणले गर्दा हो, र हामी हाल ProxySQL मा माइग्रेट गर्ने प्रक्रियामा छौं।

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

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

यदि मास्टर असफल भएमा पुनर्स्थापना गर्ने एउटा सरल तरिका फ्लोटिंग VIP ठेगानाहरू प्रयोग गर्नु हो।

अगाडि बढ्नु अघि तपाईले यस समाधानको बारेमा के जान्न आवश्यक छ:

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

हाम्रो विजार्डसँग सम्भावित समस्याहरू हेरौं र स्वचालित रिकभरी मेकानिजमले कसरी काम गर्नुपर्छ भनेर कल्पना गरौं।

मास्टरमा नेटवर्क जडान गायब भएको छ, वा हार्डवेयर स्तरमा समस्या उत्पन्न भएको छ, र सर्भर अनुपलब्ध छ।

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

सर्भर सामान्य मोडमा काम गरिरहेको छ, DBMS स्तरमा विफलता भयो

एल्गोरिथ्म अघिल्लो केस जस्तै छ: टोपोलोजी अपडेट गर्दै र रिकभरी प्रक्रिया सुरु गर्दै। सर्भर उपलब्ध भएकोले, हामीले पुरानो मास्टरमा सफलतापूर्वक VIP जारी गर्छौं, यसलाई नयाँमा स्थानान्तरण गर्छौं, र धेरै ARP अनुरोधहरू पठाउँछौं। पुरानो मास्टरको सम्भावित फिर्ताले पुन: निर्मित क्लस्टर र अनुप्रयोगको सञ्चालनलाई असर पार्नु हुँदैन।

अन्य समस्याहरू

प्रतिकृतिहरू वा मध्यवर्ती मास्टरहरूको असफलता नेतृत्व गर्दैन स्वचालित कार्यहरू गर्न र म्यानुअल हस्तक्षेप आवश्यक छ।

भर्चुअल नेटवर्क इन्टरफेस सधैं अस्थायी रूपमा थपिएको छ, त्यो हो, सर्भर रिबुट पछि, VIP स्वचालित रूपमा तोकिएको छैन। प्रत्येक डाटाबेस उदाहरण पूर्वनिर्धारित रूपमा पढ्न-मात्र मोडमा सुरु हुन्छ, अर्केस्ट्रेटरले स्वचालित रूपमा नयाँ मास्टरलाई लेख्नको लागि स्विच गर्दछ र स्थापना गर्ने प्रयास गर्दछ। read only पुरानो मास्टर मा। यी कार्यहरू सम्भावना कम गर्ने उद्देश्यले गरिन्छ split brain.

रिकभरी प्रक्रियाको क्रममा समस्याहरू उत्पन्न हुन सक्छन्, जुन मानक निगरानी उपकरणहरूको अतिरिक्त अर्केस्ट्रेटर UI मार्फत पनि सूचित गरिनु पर्छ। हामीले यो सुविधा थपेर REST API विस्तार गरेका छौं (PR हाल समीक्षा अन्तर्गत)।

HA समाधानको सामान्य रेखाचित्र तल प्रस्तुत गरिएको छ।

नयाँ मास्टर छान्दै

अर्केस्ट्रेटर पर्याप्त स्मार्ट छ र छनौट गर्ने प्रयास गर्दछ सबैभन्दा उपयुक्त प्रतिकृति निम्न मापदण्ड अनुसार नयाँ मास्टरको रूपमा:

• प्रतिकृति मास्टर पछि पछि छ;
• मास्टर र प्रतिकृतिको MySQL संस्करण;
• प्रतिकृति प्रकार (RBR, SBR वा मिश्रित);
• एउटै वा फरक डाटा केन्द्रहरूमा स्थान;
• उपलब्धता 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 - टोपोलोजी विश्लेषण को आवृत्ति। यदि समस्या पत्ता लाग्यो भने, टोपोलोजी रिकभरी सुरु हुन्छ। यो स्थिर, १ सेकेन्ड बराबर।

प्रत्येक क्लस्टर नोड प्रत्येक एक पटक अर्केस्ट्रेटर द्वारा पोल गरिन्छ InstancePollSeconds सेकेन्ड जब समस्या पत्ता लगाइन्छ, क्लस्टर राज्य बाध्य छ अद्यावधिक गरियो, र त्यसपछि रिकभरी गर्न अन्तिम निर्णय गरिन्छ। विभिन्न डाटाबेस र अर्केस्ट्रेटर प्यारामिटरहरूसँग प्रयोग गरेर, हामीले प्रतिक्रिया र रिकभरी समयलाई 30 सेकेन्डमा घटाउन सक्षम भयौं।

परीक्षण स्ट्यान्ड

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

अभ्यासको बखत, हामी समस्या अनुकरण विधिहरू मध्ये एक छनौट गर्छौं: तुरुन्तै मास्टर प्रयोग गरेर शूट गर्नुहोस् kill -9, बिस्तारै प्रक्रिया समाप्त गर्नुहोस् र सर्भर रोक्नुहोस् (docker-compose stop), नेटवर्क समस्याहरू प्रयोग गरेर अनुकरण गर्नुहोस् iptables -j REJECT वा iptables -j DROP। हामी निम्न परिणामहरू आशा गर्छौं:

• अर्केस्ट्रेटरले मास्टरसँग समस्याहरू पत्ता लगाउनेछ र 10 सेकेन्ड भन्दा बढीमा टोपोलोजी अपडेट गर्नेछ;
• रिकभरी प्रक्रिया स्वचालित रूपमा सुरु हुनेछ: नेटवर्क कन्फिगरेसन परिवर्तन हुनेछ, मास्टरको भूमिका प्रतिकृतिमा जानेछ, टोपोलोजी पुनर्निर्माण हुनेछ;
• नयाँ मास्टर लेख्न योग्य हुनेछ, प्रत्यक्ष प्रतिकृतिहरू पुनर्निर्माण प्रक्रियामा हराउने छैन;
• डाटा नयाँ मास्टरमा लेख्न र नक्कल गर्न सुरु हुनेछ;
• कुल रिकभरी समय 30 सेकेन्ड भन्दा बढी हुनेछैन।

तपाईलाई थाहा छ, प्रणालीले विभिन्न हार्डवेयर र नेटवर्क कन्फिगरेसनहरू, सिंथेटिक र वास्तविक लोडमा भिन्नताहरू, आदिका कारण परीक्षण र उत्पादन वातावरणमा फरक व्यवहार गर्न सक्छ। तसर्थ, हामी आवधिक रूपमा वास्तविक परिस्थितिहरूमा अभ्यासहरू सञ्चालन गर्छौं, नेटवर्क जडान हराउँदा वा यसको व्यक्तिगत भागहरू बिग्रेको बेला प्रणालीले कसरी व्यवहार गर्छ भनेर जाँच गर्दछ। भविष्यमा, हामी दुबै वातावरणको लागि पूर्ण रूपमा समान पूर्वाधार निर्माण गर्न र यसको परीक्षण स्वचालित गर्न चाहन्छौं।

निष्कर्ष

मुख्य भण्डारण प्रणाली नोडको स्वास्थ्य SRE र सञ्चालन टोलीको मुख्य कार्यहरू मध्ये एक हो। VIP मा आधारित अर्केस्ट्रेटर र HA समाधानको कार्यान्वयनले हामीलाई निम्न परिणामहरू प्राप्त गर्न अनुमति दियो:

• डाटाबेस क्लस्टरको टोपोलजीसँग समस्याहरूको विश्वसनीय पहिचान;
• मास्टर-सम्बन्धित घटनाहरूमा स्वचालित र द्रुत प्रतिक्रिया, प्रणाली डाउनटाइम कम गर्दै।

यद्यपि, समाधानमा यसको सीमितता र बेफाइदाहरू छन्:

• धेरै डाटा केन्द्रहरूमा HA योजना मापन गर्न तिनीहरू बीच एकल L2 नेटवर्क चाहिन्छ;
• नयाँ मास्टरमा VIP नियुक्त गर्नु अघि, हामीले यसलाई पुरानोमा जारी गर्न आवश्यक छ। प्रक्रिया क्रमिक छ, जसले रिकभरी समय बढाउँछ;
• VIP जारी गर्न सर्भरमा SSH पहुँच आवश्यक छ, वा टाढाको प्रक्रियाहरू कल गर्ने कुनै अन्य विधि। सर्भर वा डाटाबेसले रिकभरी प्रक्रियाको कारणले समस्याहरू अनुभव गरिरहेको हुनाले, हामी निश्चित हुन सक्दैनौं कि VIP हटाउने कार्य सफलतापूर्वक पूरा हुनेछ। र यसले एउटै भर्चुअल आईपी ठेगाना र समस्याको साथ दुई सर्भरहरूको उपस्थिति निम्त्याउन सक्छ split brain.

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

मैले MySQL फेलओभर क्लस्टर सिर्जना गर्ने हाम्रो दृष्टिकोणको बारेमा कुरा गरें। यो लागू गर्न सजिलो छ र वर्तमान परिस्थितिहरूमा विश्वसनीयता को एक स्वीकार्य स्तर प्रदान गर्दछ। सामान्य रूपमा सम्पूर्ण प्रणाली र विशेष रूपमा पूर्वाधारको विकास हुँदा, यो दृष्टिकोण निस्सन्देह विकसित हुनेछ।

स्रोत: www.habr.com