MySQL को लागि अर्केस्ट्रेटर: किन तपाईं बिना दोष-सहिष्णु परियोजना निर्माण गर्न सक्नुहुन्न

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

मुख्य प्रश्नको साथ सुरु गरौं: "मास्टरले छोड्दा हामी कोडलाई नयाँ मेसिनमा कसरी स्विच गर्नेछौं?"

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

Github मा काम गर्ने अर्केस्ट्रेटर को लेखक, पहिले VIP संग पहिलो योजना लागू गर्यो, र त्यसपछि कन्सुल संग एक योजना मा रूपान्तरण।

सामान्य पूर्वाधार लेआउट:

म तुरुन्तै स्पष्ट परिस्थितिहरू वर्णन गर्नेछु जुन खातामा लिनु आवश्यक छ:

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

यदि तपाईसँग छैन भने अर्केस्ट्रेटर किन चाहिन्छ?

• अर्केस्ट्रेटरसँग धेरै प्रयोगकर्ता-अनुकूल ग्राफिकल इन्टरफेस छ जसले सम्पूर्ण टोपोलोजी प्रदर्शन गर्दछ (तलको स्क्रिनसट हेर्नुहोस्)।
• अर्केस्ट्रेटरले कुन दासहरू पछि परेका छन् भनेर ट्र्याक गर्न सक्छ, र जहाँ प्रतिकृति सामान्यतया बिग्रिएको छ (हामीसँग SMS पठाउनको लागि अर्केस्ट्रेटरसँग संलग्न लिपिहरू छन्)।
• अर्केस्ट्रेटरले तपाईलाई बताउँछ कि कुन दासहरूमा GTID त्रुटि छ।

अर्केस्ट्रेटर इन्टरफेस:

GTID त्रुटि के हो?

अर्केस्ट्रेटरको लागि काम गर्न दुईवटा मुख्य आवश्यकताहरू छन्:

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

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

यसरी, अर्केस्ट्रेटरले तपाईंलाई GTID त्रुटि मार्फत देखाउँदछ कि त्यहाँ दासमा लेनदेनहरू छन् जुन मालिकमा छैनन्। यो किन भइरहेको छ?

• Read_only=1 दासमा सक्षम गरिएको छैन, कसैले जडान गरेको र डेटा परिवर्तन गर्न अनुरोध पूरा गरेको छ।
• Super_read_only=1 दासमा सक्षम गरिएको छैन, त्यसपछि प्रशासक, सर्भरलाई भ्रमित पारेर, भित्र गएर त्यहाँ अनुरोध कार्यान्वयन गरे।
• यदि तपाईंले अघिल्लो दुवै बिन्दुहरूलाई ध्यानमा राख्नुभयो भने, त्यहाँ अर्को चाल छ: MySQL मा, बिनलगहरू फ्लश गर्ने अनुरोध बिनलगमा पनि जान्छ, त्यसैले पहिलो फ्लशमा, मालिक र सबै दासहरूमा GTID त्रुटि देखा पर्नेछ। यसबाट कसरी बच्ने ? Perona-5.7.25-28 ले binlog_skip_flush_commands=1 सेटिङ प्रस्तुत गर्‍यो, जसले binlogs मा फ्लश लेख्न निषेध गर्दछ। mysql.com वेबसाइटमा एक स्थापित छ बग.

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

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

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

चित्रले प्रक्रियाको बीचमा देखाउँछ। यस बिन्दु सम्म पहिले नै के गरिसकिएको छ? हामीले भन्यौं कि हामी केही दासलाई नयाँ मालिक बनाउन चाहन्छौं, अर्केस्ट्रेटरले नयाँ मालिकले ट्रान्जिट मेसिनको रूपमा काम गर्दै अन्य सबै दासहरूलाई पुन: जडान गर्न थाल्यो। यस योजनाको साथ, कुनै त्रुटिहरू देखा पर्दैन, सबै दासहरूले काम गर्छन्, अर्केस्ट्रेटरले पुरानो मालिकबाट VIP हटाउँदछ, यसलाई नयाँमा स्थानान्तरण गर्दछ, read_only=0 बनाउँदछ र पुरानो मालिकको बारेमा बिर्सन्छ। सबै! हाम्रो सेवाको डाउनटाइम VIP स्थानान्तरण समय हो, जुन 2-3 सेकेन्ड हो।

आजको लागि यति हो, सबैलाई धन्यवाद। अर्केस्ट्रेटरको बारेमा चाँडै दोस्रो लेख हुनेछ। प्रसिद्ध सोभियत चलचित्र "ग्यारेज" मा एक पात्रले भने, "म उहाँसँग जान्दिन!" त्यसोभए, अर्केस्ट्रेटर, म तपाईसँग टोपनमा जान्छु!

स्रोत: www.habr.com