बैकअप और स्टोरेज के बारे में थोड़ा अनुभव

सभी को नमस्कार!

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

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

स्थानीय "आकार" की विशेषताएं

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

पिछले एक साल में, मैंने पहले ही दो बार स्थिति देखी है जब डेटा रिकवरी के दौरान अड़चन डिस्क सरणी थी, जिस पर रिकवरी की गई थी। वे आरटीओ में फिट हो गए, लेकिन घंटी चिंताजनक थी।

हमारे पास क्लस्टर पर एक समाधान है, आपको बैकअप की आवश्यकता क्यों है?

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

हालांकि, डेटा हानि न केवल एक साइट पर उपकरणों की विफलता से होती है, और किसी कारण से डेवलपर कुछ समय के लिए इसे समझना नहीं चाहता था। परिणामस्वरूप, सॉफ्टवेयर का पहला संस्करण सामुदायिक DBMS पर जारी किया गया था, जिसके बैकअप यांत्रिकी ने RTO / RPO आवश्यकताओं या ठेकेदार के SLA को पूरा करने की अनुमति नहीं दी थी।
सामान्य तौर पर, मैं इस वाक्यांश को अक्सर एक क्लस्टर के बारे में सुनता हूं।

पहले, फिर यह!

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

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

हमारा सब कुछ डंप कर?

अक्सर मैं ऐसे DBMS पर MySQL और PostgreSQL के रूप में समाधान करता हूं। और इससे भी अधिक बार मैं एक ऐसी स्थिति में आता हूं, जहां डेटाबेस के टीएम्पी / टीएमपी को बैकअप विधि के रूप में उपयोग किया जाता है, और फिर दूसरे माध्यम में। इसी समय, सिस्टम जहां इन DBMS का उपयोग किया जाता है, डेटा हानि की स्थिति में डाउनटाइम के लिए काफी महत्वपूर्ण होते हैं, और बहुत लोड होते हैं। मैं पहले से ही संस्करणों के बारे में चुप हूं।

किसी कारण से, कुछ लोग इन उत्पादों के लिए प्रलेखन पढ़ते हैं और यह नहीं जानते कि इन DBMS के बैकअप बनाने के लिए वैकल्पिक तरीके और समाधान हैं। PostgreSQL में क्रमशः MySQL एंटरप्राइज बैकअप MySQL और pg_basebackup ( pg_start_backup, pg_stop_backup ) के लिए। या वह जानता है, लेकिन उसके सिर से उड़ गया। हालांकि ये समाधान अधिक जटिल और तेज नहीं हैं। तेजी से बैकअप, तेजी से बहाल, तेजी से परीक्षण।

कृपया पियानोवादक को गोली मत मारो।
वह अपना सर्वश्रेष्ठ कर रहे हैं।
ऑस्कर फिंगल ओफलाहर्टी विल्स वाइल्ड