ड्रॉपबॉक्स में डेटाबेस विकास। एक वैश्विक MySQL डेटाबेस से हजारों सर्वर तक का मार्ग

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

कटऑफ के तहत, Highload ++ 2017 में Glory Bakhmutov ( m0sth8 ) की रिपोर्ट की प्रतिलिपि, कैसे ड्रॉपबॉक्स में डेटाबेस विकसित हुए और अब उनकी व्यवस्था कैसे की जाती है।


स्पीकर के बारे में: ग्लोरी टू बख्मुटोव - ड्रॉपबॉक्स टीम में साइट विश्वसनीयता इंजीनियर, गो को बहुत प्यार करता है और कभी-कभी golangshow.com पॉडकास्ट में दिखाई देता है।

सामग्री

• ड्रॉपबॉक्स वास्तुकला के बारे में संक्षेप में
• डेटाबेस के विकास का इतिहास और वर्तमान ड्रॉपबॉक्स आर्किटेक्चर कैसे काम करता है
• डेटाबेस (फॉलोवर्स, बैकअप, क्लोन, पदोन्नति) पर सबसे सरल संचालन
• स्वचालन - जो सभी डेटाबेस का प्रबंधन करता है और संचालन चलाता है
• निगरानी
• परीक्षण, मंचन और DRT

सादे भाषा में ड्रॉपबॉक्स वास्तुकला

ड्रॉपबॉक्स 2008 में दिखाई दिया। यह अनिवार्य रूप से क्लाउड फाइल स्टोरेज है। जब ड्रॉपबॉक्स बस शुरू हुआ, हैकर न्यूज के एक उपयोगकर्ता ने टिप्पणी की कि इसे एफ़टीपी और गिट का उपयोग करके कई बैश स्क्रिप्ट के साथ लागू किया जा सकता है। लेकिन, फिर भी, ड्रॉपबॉक्स विकसित हो रहा है, और अब यह 1.5 बिलियन से अधिक उपयोगकर्ताओं, 200 हजार व्यवसायों और हर दिन नई फ़ाइलों की एक बड़ी संख्या (कई बिलियन!) के साथ एक काफी बड़ी सेवा है।

ड्रॉपबॉक्स कैसा दिखता है?


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

1. Metaserver।
2. Blockserver।

मेटासेवर फ़ाइल के बारे में मेटा-जानकारी संग्रहीत करता है: आकार, उस पर टिप्पणी, ड्रॉपबॉक्स में इस फ़ाइल के लिंक आदि। अवरोधक केवल फ़ाइलों के बारे में जानकारी संग्रहीत करता है: फ़ोल्डर, पथ, आदि।

यह कैसे काम करता है?

उदाहरण के लिए, आपके पास एक वीडियो है। किसी तरह के वीडियो के साथ एक फ़ाइल।
स्लाइड से लिंक करें

• ग्राहक इस फ़ाइल को कई खंडों में विभाजित करता है (इस मामले में, 4 एमबी प्रत्येक), चेकसम की गणना करता है और मेटसेवर को एक अनुरोध भेजता है: "मेरे पास एक * .AVI फ़ाइल है, मैं इसे डाउनलोड करना चाहता हूं, हैश मात्राएं ऐसी हैं और"।
• Metserver ने उत्तर दिया: "मेरे पास ये ब्लॉक नहीं हैं, चलो डाउनलोड करें!" या वह जवाब दे सकता है कि उसके पास सभी या कुछ ब्लॉक हैं, और केवल शेष लोगों को लोड करने की आवश्यकता है।

स्लाइड से लिंक करें

• उसके बाद, क्लाइंट ब्लॉकसेवर में जाता है, हैश राशि और डेटा ब्लॉक को स्वयं भेजता है, जिसे ब्लॉकसेवर पर संग्रहीत किया जाता है।
• अवरोधक ऑपरेशन की पुष्टि करता है।

स्लाइड से लिंक करें

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


जब एक ग्राहक Metaserver पर कुछ बचाता है, तो सभी जानकारी MySQL में जाती है। ब्लॉकसेवर भी फ़ाइलों के बारे में जानकारी संग्रहीत करता है, कि वे कैसे संरचित हैं, वे किस ब्लॉक से मिलकर बनाते हैं, MySQL में। Blockserver, ब्लॉक स्टोरेज में खुद को ब्लॉक भी करता है, जो बदले में, जानकारी देता है कि कौन सा ब्लॉक कहां पर है, किस सर्वर पर और कैसे इसे प्रोसेस किया जाता है, MYSQL में भी।

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

डेटाबेस विकास का इतिहास

ड्रॉपबॉक्स में डेटाबेस कैसे विकसित हुए?


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


इसलिए, 2011 में अलग-अलग सर्वरों के लिए कई तालिकाएँ प्रस्तुत की गईं:

• उपयोगकर्ता , उपयोगकर्ताओं के बारे में जानकारी के साथ, उदाहरण के लिए, लॉगिन और ऑउथ टोकन;
• ब्लॉकसेवर से फ़ाइल जानकारी के साथ होस्ट ;
• विविध , जो उत्पादन से प्रसंस्करण अनुरोधों में शामिल नहीं था, लेकिन उपयोगिता कार्यों के लिए उपयोग किया जाता था, जैसे बैच नौकरियां।

लेकिन 2012 के बाद, ड्रॉपबॉक्स बहुत बढ़ने लगा, तब से हम एक वर्ष में लगभग 100 मिलियन उपयोगकर्ताओं द्वारा विकसित हुए हैं ।


इतनी बड़ी वृद्धि को ध्यान में रखना आवश्यक था, और इसलिए 2011 के अंत में हमारे पास शार्क थे - एक आधार जिसमें 1,600 शार्क थे। प्रारंभ में, 200 शार्क के साथ केवल 8 सर्वर। अब यह प्रत्येक पर 4 शार्क के साथ 400 मास्टर सर्वर है।
स्लाइड से लिंक करें

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

एडस्टोर अनिवार्य रूप से क्लाइंट्स से MySQL को अमूर्त करता है। ग्राहकों के पास कुछ इकाइयाँ होती हैं जो gRPC API से एडस्टोर कोर के लिंक द्वारा आपस में जुड़ी होती हैं, जो इस डेटा को MySQL में परिवर्तित करती हैं और किसी तरह इसे वहां स्टोर करती हैं (मूल रूप से यह कैश से यह सब देती है)।
स्लाइड से लिंक करें

2015 में, हमने अमेज़ॅन एस 3 को छोड़ दिया , मैजिक पॉकेट नामक अपना स्वयं का क्लाउड स्टोरेज विकसित किया। इसमें एक ब्लॉक फ़ाइल कहाँ स्थित है, किस सर्वर पर, MySQL में संग्रहीत सर्वरों के बीच इन ब्लॉकों के आंदोलनों के बारे में जानकारी शामिल है।
स्लाइड से लिंक करें

लेकिन MySQL का उपयोग बहुत ही ट्रिकी तरीके से किया जाता है - संक्षेप में, एक बड़े वितरित हैश टेबल के रूप में। यह एक बहुत अलग भार है, मुख्य रूप से यादृच्छिक रिकॉर्ड पढ़ने पर। 90% उपयोग I / O है।

डेटाबेस आर्किटेक्चर

सबसे पहले, हमने तुरंत कुछ सिद्धांतों की पहचान की जिनके द्वारा हम अपने डेटाबेस की वास्तुकला का निर्माण करते हैं:

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

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

आधार टोपोलॉजी

डेटाबेस इस प्रकार संरचित है:

• मुख्य डेटा सेंटर में, हमारे पास एक मास्टर है, जिसमें सभी रिकॉर्ड होते हैं।
• मास्टर सर्वर में दो दास सर्वर होते हैं जिनके लिए सेमीसिंक प्रतिकृति होती है। सर्वर अक्सर मर जाते हैं (लगभग 10 प्रति सप्ताह), इसलिए हमें दो दास सर्वर की आवश्यकता है।
• दास सर्वर अलग समूहों में हैं। डेटा सेंटर में क्लस्टर पूरी तरह से अलग कमरे होते हैं जो एक दूसरे से जुड़े नहीं होते हैं। यदि एक कमरा जल जाता है, तो दूसरा पूरी तरह से काम करता है।
• इसके अलावा एक अन्य डेटा सेंटर में हमारे पास तथाकथित छद्म मास्टर (इंटरमीडिएट मास्टर) है, जो वास्तव में सिर्फ एक गुलाम है, जिसके पास एक और गुलाम है।

इस तरह की टोपोलॉजी को चुना गया क्योंकि अगर पहला डेटा सेंटर अचानक हममें मर जाता है, तो दूसरे डेटा सेंटर में हमारे पास लगभग पूरा टोपोलॉजी होता है । हम केवल डिस्कवरी में सभी पते बदलते हैं, और क्लाइंट काम कर सकते हैं।

विशिष्ट टोपोलॉजी

हमारे पास विशेष टोपोलॉजी भी हैं।

मैजिक पॉकेट टोपोलॉजी में एक मास्टर सर्वर और दो दास सर्वर होते हैं। ऐसा इसलिए किया जाता है क्योंकि मैजिक पॉकेट खुद ज़ोन के बीच डेटा को डुप्लिकेट करता है। यदि यह एक क्लस्टर खो देता है, तो यह इरेज़ कोड के माध्यम से अन्य ज़ोन से सभी डेटा को पुनर्स्थापित कर सकता है।


सक्रिय-सक्रिय टोपोलॉजी एज़ेस्टोर द्वारा उपयोग की जाने वाली कस्टम टोपोलॉजी है। इसके दो डेटा केंद्रों में एक मास्टर और दो दास हैं, और वे एक दूसरे के दास हैं। यह एक बहुत ही खतरनाक योजना है , लेकिन एडस्टोर अपने स्तर पर जानते हैं कि किस डेटा पर कौन सा मास्टर किस सीमा तक लिख सकता है। इसलिए, यह टोपोलॉजी टूटती नहीं है।

उदाहरण

हमने 4-5 साल पहले विन्यास के साथ काफी सरल सर्वर स्थापित किए हैं:

• 2x Xeon 10 कोर;
• 5TB (8 SSD छापे 0 *);
• 384 जीबी मेमोरी।

* छापे 0 - क्योंकि ड्राइव की तुलना में पूरे सर्वर को बदलना आसान और बहुत तेज़ है।

एकल उदाहरण

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



यह समाधान उस में अच्छा है:

+ इसे प्रबंधित करना आसान है । यदि आपको MySQL उदाहरण को बदलने की आवश्यकता है, तो बस सर्वर को बदलें।

+ बस फायलोवर करते हैं ।

दूसरी ओर:

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

- एक शार्क की नकल करने की समस्या अन्य शार्क को प्रभावित करती है। MySQL प्रतिकृति समानांतर नहीं है, और सभी शार्क एक ही धागे पर काम करते हैं। अगर एक शार्क पर कुछ होता है, तो बाकी लोग भी शिकार बन जाते हैं।

इसलिए अब हम एक अलग टोपोलॉजी की ओर बढ़ रहे हैं।

बहु उदाहरण है

नए संस्करण में, सर्वर पर कई MySQL इंस्टेंसेस एक बार में लॉन्च किए गए हैं, प्रत्येक में एक शार्क है। क्या बेहतर है?

+ हम केवल एक विशिष्ट शार्क पर ही ऑपरेशन कर सकते हैं । यही है, अगर आपको एक फायलोवर की आवश्यकता है, तो केवल एक ही शार्क को स्विच करें, यदि आपको बैकअप की आवश्यकता है, तो हम केवल एक ही शार्क का बैकअप लेते हैं। इसका मतलब यह है कि ऑपरेशनों को बहुत तेज किया जाता है - चार-शार्द सर्वर के लिए 4 बार।

+ शेयर शायद ही एक-दूसरे को प्रभावित करते हैं ।

+ प्रतिकृति में सुधार। हम डेटाबेस की विभिन्न श्रेणियों और वर्गों को मिला सकते हैं। Edgestore ने बहुत सारी जगह ले ली है, उदाहरण के लिए, सभी 4 टीबी, और मैजिक पॉकेट में केवल 1 TB लगता है, लेकिन इसका 90% उपयोग है। यही है, हम विभिन्न श्रेणियों को जोड़ सकते हैं जो I / O और मशीन संसाधनों का अलग-अलग तरीकों से उपयोग करते हैं, और 4 प्रतिकृति धाराएं शुरू करते हैं।

बेशक, इस समाधान में इसकी कमियां हैं:

- सबसे बड़ा ऋण यह है कि यह सब प्रबंधित करना बहुत कठिन है । हमें कुछ चतुर शेड्यूलर की आवश्यकता है जो समझेंगे कि वह इस उदाहरण को कहां ले जा सकता है, जहां एक इष्टतम भार होगा।

- असफलताओं की तुलना में कठोर ।

इसलिए, हम केवल इस निर्णय पर आगे बढ़ रहे हैं।

खोज

ग्राहकों को किसी तरह यह जानना चाहिए कि वांछित डेटाबेस से कैसे जुड़ा जाए, इसलिए हमारे पास डिस्कवरी है, जो होनी चाहिए:

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

डिस्कवरी कैसे विकसित हुई

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


यदि बहुत सारे सर्वर हैं, तो दुर्भाग्य से, यह काम नहीं करता है।


ऊपर बहुत पहले डिस्कवरी है जो हमारे पास है। विन्यास स्क्रिप्ट में नेमप्लेट बदलने वाले डेटाबेस स्क्रिप्ट थे - यह एक अलग MySQL नेमप्लेट था, और क्लाइंट पहले से ही इस डेटाबेस को सुनते थे और समय-समय पर वहां से डेटा लेते थे।


तालिका बहुत सरल है, एक डेटाबेस श्रेणी है, एक शार्क कुंजी है, एक डेटाबेस क्लास मास्टर / दास, प्रॉक्सी और एक डेटाबेस पता है। वास्तव में, क्लाइंट ने एक श्रेणी, एक डीबी क्लास, एक शार्प कुंजी और माईएसक्यूएल पते का अनुरोध किया था, जिस पर वह पहले से ही एक कनेक्शन स्थापित कर सकता था।


जैसे ही बहुत सारे सर्वर थे, मेम्चे को जोड़ा गया और ग्राहकों ने इसके साथ पहले से ही संवाद करना शुरू कर दिया।

लेकिन फिर हमने इसे फिर से शुरू किया। MySQL लिपियों ने gRPC के माध्यम से एक पतली क्लाइंट के माध्यम से एक सेवा के साथ संवाद करना शुरू किया, जिसे हमने RegisterService कहा। जब कुछ परिवर्तन हुए, तो RegisterService की एक कतार थी, और वह समझ गया कि इन परिवर्तनों को कैसे लागू किया जाए। एएफएस में डेटा सेव करने के लिए रजिस्टरस् सेवा। AFS हमारा आंतरिक सिस्टम है जो चिड़ियाघरकीपर पर आधारित है।


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

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

अनिवार्य रूप से, चिड़ियाघर कीपर के ऊपर ऐसा अमूर्त, जिसमें एक स्थानीय बैकऑफ़ और जिटर एल्गोरिदम है। ZooKeeper अब लोड के तहत क्रैश नहीं करता है। एएफएस के साथ, हम एस 3 और जीआईटी में बैकअप लेते हैं, फिर स्थानीय एएफएस स्वयं ग्राहकों को सूचित करता है कि डेटा बदल गया है।


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

संचालन

हम बहुत ही सरल ऑपरेशन का उपयोग करते हैं: पदोन्नति, क्लोन, बैकअप / रिकवरी।


एक ऑपरेशन एक सरल राज्य मशीन है । जब हम ऑपरेशन में जाते हैं, तो हम कुछ चेक करते हैं, उदाहरण के लिए, स्पिन-चेक, जो कई बार टाइमआउट चेक द्वारा होता है कि क्या हम इस ऑपरेशन को कर सकते हैं। उसके बाद, हम कुछ प्रारंभिक कार्रवाई करते हैं जो बाहरी प्रणालियों को प्रभावित नहीं करता है। अगला, ऑपरेशन ही।

किसी ऑपरेशन के सभी चरणों में एक रोलबैक-चरण (पूर्ववत) है। यदि ऑपरेशन में कोई समस्या है, तो ऑपरेशन सिस्टम को उसकी मूल स्थिति में पुनर्स्थापित करने का प्रयास करता है। यदि सब कुछ ठीक है, तो सफाई होती है और ऑपरेशन पूरा हो जाता है।

हमारे पास किसी भी ऑपरेशन के लिए ऐसी सरल राज्य मशीन है।

पदोन्नति (मास्टर का परिवर्तन)

यह डेटाबेस में एक बहुत ही सामान्य ऑपरेशन है। एक गर्म मास्टर-सर्वर पर परिवर्तन कैसे किया जाए, इस बारे में प्रश्न थे - यह एक हिस्सेदारी प्राप्त करेगा। बस इतना है कि ये सभी ऑपरेशन गुलाम सर्वर पर किए जाते हैं, और फिर मास्टर स्थानों के साथ गुलाम बदलते हैं। इसलिए, पदोन्नति ऑपरेशन बहुत अक्सर होता है ।


हमें कर्नेल को अपडेट करने की आवश्यकता है - हम स्वैप करते हैं, हमें MySQL के संस्करण को अपडेट करने की आवश्यकता है - हम दास पर अपडेट करते हैं, मास्टर पर स्विच करते हैं, वहां अपडेट करते हैं।


हमने बहुत तेजी से तरक्की हासिल की है। उदाहरण के लिए, चार शार्क के लिए, अब हमारे पास लगभग 10-15 एस के लिए प्रचार है। ऊपर दिए गए ग्राफ़ से पता चलता है कि पदोन्नति की उपलब्धता के साथ इसे 0.0003% तक की हानि हुई।

लेकिन सामान्य पदोन्नति इतनी दिलचस्प नहीं है, क्योंकि ये सामान्य ऑपरेशन हैं जो हर दिन किए जाते हैं। विफलताएं दिलचस्प हैं।

विफलता (एक टूटे हुए मास्टर के लिए प्रतिस्थापन)

एक विफलता का अर्थ है कि डेटाबेस मृत है।

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

मृत मास्टर सर्वरों का प्रतिस्थापन दिन में लगभग 2-3 बार होता है , यह पूरी तरह से स्वचालित प्रक्रिया है, किसी भी मानवीय हस्तक्षेप की आवश्यकता नहीं है। महत्वपूर्ण खंड में लगभग 30 सेकंड लगते हैं, और यह देखने के लिए अतिरिक्त जांच का एक गुच्छा है कि क्या सर्वर वास्तव में जीवित है, या शायद यह पहले ही मर चुका है।

नीचे एक उदाहरण आरेख है कि फ़ैलोवर कैसे काम करता है।


चयनित अनुभाग में, हम मास्टर सर्वर को रिबूट करते हैं । यह आवश्यक है क्योंकि हमारे पास MySQL 5.6 है, और इसमें सेमीसिंक प्रतिकृति दोषरहित नहीं है। इसलिए, प्रेत पढ़ना संभव है, और हमें इस मास्टर की आवश्यकता है, भले ही यह मर न गया हो, जितनी जल्दी हो सके इसे मार दें ताकि ग्राहक इससे अलग हो जाएं। इसलिए, हम इपमी के माध्यम से एक हार्ड रीसेट करते हैं - यह पहला सबसे महत्वपूर्ण ऑपरेशन है जो हमें करना चाहिए। MySQL 5.7 संस्करण में, यह इतना महत्वपूर्ण नहीं है।

क्लस्टर सिंक्रनाइज़ेशन। हमें क्लस्टर सिंक्रोनाइज़ेशन की आवश्यकता क्यों है?


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

• हम सभी दास सर्वर पर सभी I / O थ्रेड को रोकते हैं।
• उसके बाद, हम पहले से ही यह सुनिश्चित करने के लिए जानते हैं कि मास्टर "रीड-ओनली" है, क्योंकि सेमीसिंक्स डिस्कनेक्ट हो गया है और कोई और वहां कुछ भी नहीं लिख सकता है।
• अगला, हम गुलाम का चयन सबसे बड़े पुनर्प्राप्त / निष्पादित जीटीआईडी ​​सेट के साथ करते हैं, अर्थात्, सबसे बड़े लेनदेन के साथ जो इसे डाउनलोड या पहले से ही लागू है।
• हम सभी दास सर्वर को इस चयनित दास में फिर से कॉन्फ़िगर करते हैं, I / O थ्रेड शुरू करते हैं, और वे सिंक्रनाइज़ किए जाते हैं।
• हम तब तक प्रतीक्षा करते हैं जब तक वे सिंक्रनाइज़ नहीं हो जाते हैं, जिसके बाद हमारे पास पूरा क्लस्टर सिंक्रनाइज़ हो जाता है। , executed GTID set .

— . promotion , :

• slave -, , master, promotion.
• slave- master, , ACLs, , - proxy, , - .
• read_only = 0, , master , . master .
• - . - , , , , , proxy .
• .

, rollback , . rollback reboot. , , , — change master — master .

— . , , , , .



● slave

, slave-, . .

●

, , . .

●

, , . . 3 .

, , , :

1. . 1 40 .
   
2. .
   

, . 1 40 , , , .

, . . 4 .

• 24 . HDFS, .
• 6 unsharded databases, Global DB. , , , .
• 3 S3.
• 3 S3 .

. , 3 , HDFS 3 , 6 S3. .

, .


, , . , , recovery - . , , - . 100 , .

, , , , , , , . .

hot-, Percona xtrabackup. —stream=xbstream, , . script-splitter, , .

MySQL 2x. 3 , , , 1 500 . , , HDFS S3.

.


, , HDFS S3, , splitter xtrabackup, . crash-recovery.

hot , crash-recovery . , . binlog, master.

binlogs?

binlog'. master , 4 , 100 , HDFS.

: Binlog Backuper, . , , binlog HDFS.


, 4 , 5 , , , . HDFS S3 .

.

:

1. — 10 , 45 — .
   
2. , scheduler multi instance slave master .
   
3. — , . , , , , , , . pt-table-checksum , .
   

, :

1. 1 10 , . crash-recovery, .
   
2. .
   

slave -, . , . .

++

. Hardware , (HDD) 10 , + crash recovery xtrabackup, . , , . , , , , HDD , HDFS .

, — :

1. ;
   
2. .
   

, HDFS, , , .

स्वचालन

, 6 000 . , , — :

• Auto-replace;
• DBManager;
• Naoru, Wheelhouse

Auto-replace

, , , , — , -. , .

Availability () — , . — recovery , .


MySQL , heartbeat. Heartbeat — timestamp.


, , , master read-write. heartbeat.

auto-replace , .
, 91 .

?

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

ऑटो-रिप्लेस बहुत रूढ़िवादी है। वह कभी भी बहुत अधिक स्वचालित संचालन नहीं करना चाहता है।

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

इसलिए, हम एक बार में केवल एक समस्या का समाधान करते हैं ।

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

DBManager

DBManager हमारे डेटाबेस के प्रबंधन के लिए एक सेवा है। यह है:

• स्मार्ट कार्य अनुसूचक जो वास्तव में जानता है कि कब शुरू करना है;
• लॉग और सभी जानकारी: कौन, कब और क्या लॉन्च किया - यह सच्चाई का स्रोत है;
• तुल्यकालन बिंदु।

DBManager वास्तुकला में काफी सरल है।

• ग्राहक होते हैं, या तो डीबीए जो वेब इंटरफेस के माध्यम से कुछ करते हैं, या स्क्रिप्ट / सेवाएं जो डीबीए लिखती हैं जो जीआरपीसी के माध्यम से एक्सेस करती हैं।
• व्हीलहाउस और नोरू जैसी बाहरी प्रणालियाँ हैं, जो जीआरपीसी के माध्यम से डीबीएमएनेगर में जाती हैं।
• एक अनुसूचक है जो समझता है कि क्या ऑपरेशन, कब और कहां शुरू हो सकता है।
• एक बहुत ही मूर्ख कार्यकर्ता है, जब कोई ऑपरेशन उसके पास आता है, उसे शुरू करता है, पीआईडी ​​द्वारा जांच की जाती है। कार्यकर्ता पुनः आरंभ कर सकता है, प्रक्रियाएं बाधित नहीं होती हैं। सभी श्रमिक सर्वर के जितना संभव हो उतना निकट स्थित होते हैं, जिस पर संचालन होता है, इसलिए, उदाहरण के लिए, एसीएलएस को अपडेट करते समय, हमें कई गोल यात्राएं करने की आवश्यकता नहीं है।
• प्रत्येक SQL होस्ट पर हमारे पास एक DBAgent है - यह एक RPC सर्वर है। जब आपको सर्वर पर कुछ ऑपरेशन करने की आवश्यकता होती है, तो हम एक आरपीसी अनुरोध भेजते हैं।

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


एक काफी सरल सीएलआई इंटरफ़ेस है जहां आप कार्यों को चला सकते हैं और उन्हें सुविधाजनक दृश्यों में भी देख सकते हैं।

Remediations

हमारे पास समस्याओं के जवाब के लिए एक प्रणाली भी है। जब कुछ टूट जाता है, उदाहरण के लिए, ड्राइव क्रैश हो जाता है, या कुछ सेवा काम नहीं करती है, तो नोरू काम करता है । यह वह प्रणाली है जो ड्रॉपबॉक्स में काम करती है, हर कोई इसका उपयोग करता है, और यह विशेष रूप से ऐसे छोटे कार्यों के लिए बनाया गया है। मैंने 2016 में अपनी रिपोर्ट में नारू के बारे में बात की थी।

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

निगरानी

यह बहुत महत्वपूर्ण है।

यदि आप सिस्टम की निगरानी नहीं करते हैं, तो सबसे अधिक संभावना है कि यह काम नहीं करता है।

हम MySQL में सब कुछ की निगरानी करते हैं - MySQL से प्राप्त होने वाली सभी जानकारी कहीं संग्रहीत होती है, हम इसे समय पर एक्सेस कर सकते हैं। हम जानकारी पर जानकारी संग्रहीत करते हैं, अनुरोधों पर आंकड़े, लेनदेन पर, लेनदेन की लंबाई पर, लेन-देन की लंबाई पर प्रतिशत, प्रतिकृति पर, नेटवर्क पर - सभी-सभी-सभी - मैट्रिक्स की एक बड़ी संख्या।

चेतावनी

हमारे पास 992 अलर्ट कॉन्फ़िगर किए गए हैं। वास्तव में, कोई भी मैट्रिक्स को नहीं देख रहा है, यह मुझे लगता है कि ऐसे लोग नहीं हैं जो काम पर आते हैं और मैट्रिक्स चार्ट को देखना शुरू करते हैं, अधिक दिलचस्प कार्य हैं।


इसलिए, ऐसे अलर्ट हैं जो निश्चित सीमा मानों तक पहुंचने पर काम करते हैं। हमारे पास 992 अलर्ट हैं, चाहे कुछ भी हो, हम इसके बारे में पता लगाएंगे ।

घटनाओं

हमारे पास PagerDuty है - एक सेवा जिसके माध्यम से जिम्मेदार व्यक्तियों को अलर्ट भेजा जाता है जो कार्रवाई करना शुरू करते हैं।


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

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

परीक्षण

निगरानी के साथ, मुझे यकीन है कि हर कोई परीक्षण कर रहा है। इकाई परीक्षणों के अलावा, जिसके साथ हम अपना कोड कवर करते हैं, हमारे पास एकीकरण परीक्षण हैं जिसमें हम परीक्षण करते हैं:

• हमारे पास जो भी टोपोलॉजी हैं;
• इन टोपोलॉजी पर सभी ऑपरेशन।

यदि हमारे पास प्रमोशन ऑपरेशन हैं, तो हम एकीकरण परीक्षण में प्रमोशन ऑपरेशन का परीक्षण करते हैं। यदि हमारे पास क्लोनिंग है, तो हम उन सभी टोपोलॉजी के लिए क्लोनिंग करते हैं जो हमारे पास हैं।

टोपोलॉजी उदाहरण


हमारे पास सभी अवसरों के लिए टोपोलॉजी है: 2 डेटा सेंटर जिसमें मल्टी उदाहरण के साथ, शार्क के साथ, कोई शार्क नहीं, क्लस्टर्स के साथ, एक डेटा सेंटर - आम तौर पर लगभग किसी भी टोपोलॉजी - यहां तक ​​कि उन जिसका हम उपयोग नहीं करते हैं, बस देखने के लिए।


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


परीक्षण बहुत सरल दिखता है: हम संकेत देते हैं कि किस टोपोलॉजी का उपयोग किया जा रहा है। इस परीक्षण में, हम auto_replace का परीक्षण करते हैं।

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

चरणों

स्टेज वातावरण उत्पादन के समान डेटाबेस हैं, लेकिन कोई उपयोगकर्ता ट्रैफ़िक नहीं है, लेकिन कुछ सिंथेटिक ट्रैफ़िक है जो पेरकोना प्लेबैक, सिसबेन और इसी तरह के सिस्टम के माध्यम से उत्पादन के समान है।

पेरकोना प्लेबैक में, हम ट्रैफ़िक रिकॉर्ड करते हैं, फिर हम इसे विभिन्न तीव्रता के साथ मंच के वातावरण में खो देते हैं, हम 2-3 गुना तेजी से खो सकते हैं। यही है, यह कृत्रिम है, लेकिन वास्तविक भार के बहुत करीब है।

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

इसके अलावा, हम सभी स्वचालन का एक साथ परीक्षण करते हैं, क्योंकि एकीकरण परीक्षणों में, सबसे अधिक संभावना है, सिस्टम का एक हिस्सा परीक्षण किया जाता है, और मंचन में, सभी स्वचालित सिस्टम एक साथ काम करते हैं। कभी-कभी आप सोचते हैं कि सिस्टम इस तरह से व्यवहार करेगा और अन्यथा नहीं, लेकिन यह पूरी तरह से अलग तरीके से व्यवहार कर सकता है।

DRT (आपदा वसूली परीक्षण)

हम उत्पादन में परीक्षण भी करते हैं - असली ठिकानों पर। इसे डिजास्टर रिकवरी टेस्टिंग कहा जाता है। हमें इसकी आवश्यकता क्यों है?

● हम अपनी वारंटी का परीक्षण करना चाहते हैं।

यह कई बड़ी कंपनियों द्वारा किया जाता है। उदाहरण के लिए, Google के पास एक सेवा है जो इतनी दृढ़ता से काम करती है - 100% समय - यह कि इसका उपयोग करने वाली सभी सेवाओं ने निर्णय लिया कि यह सेवा वास्तव में 100% स्थिर है और कभी भी क्रैश नहीं होती है। इसलिए, Google को इस सेवा को उद्देश्य से छोड़ना पड़ा, ताकि उपयोगकर्ता इस संभावना को ध्यान में रखें।

तो हम हैं - हमारे पास गारंटी है कि MySQL काम करता है - और कभी-कभी यह काम नहीं करता है! और हमारे पास गारंटी है कि यह एक निश्चित अवधि के लिए काम नहीं कर सकता है, ग्राहकों को इसे ध्यान में रखना चाहिए। समय-समय पर, हम उत्पादन मास्टर को मारते हैं, या यदि हम एक फायलोवर बनाना चाहते हैं, तो हम सभी दासों को मारते हैं यह देखने के लिए कि अर्धचालक प्रतिकृति कैसे व्यवहार करती है।

● ग्राहक इन त्रुटियों के लिए तैयार हैं (प्रतिस्थापन और गुरु की मृत्यु)

वह अच्छा क्यों है? हमारे पास एक मामला था जब पदोन्नति के दौरान 1600 में से 4 शार्क, उपलब्धता 20% तक गिर गई। ऐसा लगता है कि कुछ गलत है, 1600 से 4 शार्क के लिए कुछ अन्य संख्याएं होनी चाहिए। इस प्रणाली के लिए विफलताएं महीने में लगभग एक बार दुर्लभ थीं, और सभी ने फैसला किया: "ठीक है, यह एक विफलता है, ऐसा होता है।"

कुछ बिंदु पर, जब हमने एक नई प्रणाली में स्विच किया, तो एक व्यक्ति ने उन दो दिल की धड़कन रिकॉर्डिंग सेवाओं को अनुकूलित करने का फैसला किया और उन्हें एक में मिला दिया। इस सेवा ने कुछ और किया और अंत में, दिल की धड़कन बंद हो गई और रिकॉर्डिंग बंद हो गई। ऐसा हुआ कि इस ग्राहक के लिए हमारे पास एक दिन में 8 फायलोवर्स थे। सब कुछ - 20% उपलब्धता।

यह पता चला कि इस ग्राहक में जिंदा है 6 घंटे। तदनुसार, जैसे ही मास्टर की मृत्यु हुई, हमारे पास 6 घंटे के लिए सभी कनेक्शन थे। पूल काम करना जारी नहीं रख सकता है - इसके कनेक्शन रखे गए हैं, यह सीमित है और काम नहीं करता है। इसकी मरम्मत की गई।

हम फिर से फायलोवर करते हैं - अब 20% नहीं, लेकिन फिर भी बहुत कुछ। अभी भी कुछ गड़बड़ है। यह पता चला कि पूल के कार्यान्वयन में एक बग। जब अनुरोध किया गया, तो पूल कई मोड़ पर मुड़ गया, और फिर यह सब जुड़ा। यदि कुछ शार्प बुखार थे, तो गो कोड में कुछ दौड़ की स्थिति उत्पन्न हुई, और पूरे पूल को बंद कर दिया गया। ये सभी शार्क अब काम नहीं कर सकती थीं।

आपदा वसूली परीक्षण बहुत उपयोगी है, क्योंकि ग्राहकों को इन त्रुटियों के लिए तैयार रहना चाहिए, उन्हें अपने कोड की जांच करनी चाहिए।

● प्लस डिजास्टर रिकवरी परीक्षण अच्छा है क्योंकि यह व्यापार के घंटों के दौरान होता है और सब कुछ जगह में है, कम तनाव, लोग जानते हैं कि अब क्या होगा। यह रात में नहीं होता है, और यह बहुत अच्छा है।

निष्कर्ष

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

2. टेस्ट निरंतर और स्वचालित (और उत्पादन में) होना चाहिए।
आपका सिस्टम बदल रहा है, आपका इंफ्रास्ट्रक्चर बदल रहा है। यदि आपने एक बार जांच की, और यह काम करने लगा, इसका मतलब यह नहीं है कि यह कल काम करेगा। इसलिए, आपको उत्पादन सहित, हर दिन लगातार स्वचालित परीक्षण करने की आवश्यकता है।

3. अपने ग्राहकों (पुस्तकालयों) के लिए सुनिश्चित करें।
उपयोगकर्ता यह नहीं जान सकते कि डेटाबेस कैसे काम करता है। वे समझ नहीं पा रहे हैं कि टाइमआउट की आवश्यकता क्यों है, जीवित रहें। इसलिए, इन ग्राहकों का मालिक होना बेहतर है - आप शांत रहेंगे।

4. सिस्टम और अपनी गारंटी के निर्माण के लिए अपने सिद्धांतों को निर्धारित करना आवश्यक है, और हमेशा उनका अनुपालन करें।

इस प्रकार, आप 6 हजार डेटाबेस सर्वर का समर्थन कर सकते हैं।

, facebook youtube- — Highload++ 2018 . , 1 .