हैलो, हब्रोज़िटेली! आईटी के क्षेत्र में, एक वास्तविक क्रांति हुई - उन्होंने कोड के साथ बुनियादी ढांचे के साथ काम करना शुरू कर दिया। यह प्रक्रिया न केवल नई समस्याएं पैदा करती है, बल्कि डेटाबेस के अपटाइम को सुनिश्चित करने के अवसर भी प्रदान करती है। लेखकों ने यह व्यावहारिक मार्गदर्शिका किसी के लिए भी तैयार की है जो आधुनिक डेटाबेस विश्वसनीयता इंजीनियरों (DBRE) के समुदाय में शामिल होना चाहता है।इस पुस्तक में: • भंडारण आवश्यकताओं और जोखिम प्रबंधन आवश्यकताओं। • एक वास्तुकला का निर्माण और विकास जो पारदर्शी डेटाबेस सहायता प्रदान करता है। • रिलीज प्रबंधन प्रक्रिया को सुव्यवस्थित करना। • डेटा का भंडारण, अनुक्रमण और प्रतिकृति। • डेटा वेयरहाउस की विशेषताओं का निर्धारण करना और इसके उपयोग के लिए सर्वोत्तम विकल्पों का चयन करना। • आर्किटेक्चर घटकों और बड़े डेटा प्रोसेसिंग के लिए उन्मुख आर्किटेक्चर के निर्माण का अनुसंधान।यह पुस्तक किसके लिए है?, , . , . , . , , . .
, Linux/Unix, - / . , — — — . , , .
, , , . , , .
, , . , - , . , Excel, .
प्रकाशन संरचना. . , , , . : , , , . , . !
, : (DBRE), (RE). , . DBR- , , .
, . . , . — , . , , , , , , , . .
, .
1 . , — , DBRE, — , , DBRE .
2 . , . , , — , . , .
3 . . .
4 . . , , . , .
5 6 . . , , , , , .
7 . , , DBE. — , . , , , .
8 . , ? SQL? — , .
9 . . .
10 , . , , . , .
11 . , , . , , , .
12 (), , , . , « » () , , . — .
, 13 . , .
बैकअप बहाल
अध्याय 5 और 6 में, हमने बुनियादी ढांचे के डिजाइन और प्रबंधन पर ध्यान केंद्रित किया। इसका अर्थ है कि आपके पास वितरित इन्फ्रास्ट्रक्चर बनाने और तैनात करने का एक अच्छा विचार है जिसमें डेटाबेस काम करते हैं, साथ ही साथ उन्हें प्रबंधित भी करते हैं। हमने क्षमता बढ़ाने या विफल नोड को बदलने के लिए जल्दी से नए नोड जोड़ने के तरीकों पर ध्यान दिया। अब सबसे महत्वपूर्ण बात पर चर्चा करने का समय है - डेटा का बैकअप लेना और पुनर्स्थापित करना।आइए इसका सामना करें: हर कोई उबाऊ और थकाऊ गतिविधियों को बहाल करने और बहाल करने पर विचार करता है। अधिकांश के लिए, ये प्रक्रियाएँ दिनचर्या का प्रतीक हैं। टीम जूनियर इंजीनियरों और बाहरी ठेकेदारों के साथ बातचीत करना और तीसरे पक्ष के उपकरण के साथ काम करना पसंद नहीं करती है। इससे पहले, हमें बस भयानक बैकअप सॉफ्टवेयर से निपटना था। हमें आपसे सहानुभूति है, ईमानदारी से।फिर भी, यह आपके काम में सबसे महत्वपूर्ण प्रक्रियाओं में से एक है। नोड्स, डेटा केंद्रों के बीच महत्वपूर्ण डेटा को स्थानांतरित करना और इसे दीर्घकालिक अभिलेखागार में स्थानांतरित करना आपके व्यवसाय - जानकारी की सबसे मूल्यवान संपत्ति का एक निरंतर आंदोलन है। हम दृढ़ता से अनुशंसा करते हैं कि आप पुनर्प्राप्ति और बैकअप संचालन को द्वितीय श्रेणी के संचालन के रूप में नहीं मानते हैं, लेकिन उन्हें वीआईपी संचालन के रूप में मानते हैं। हर किसी को न केवल डेटा रिकवरी के लक्ष्यों को समझना चाहिए, बल्कि इस काम और प्रक्रिया की निगरानी के सिद्धांतों से भी परिचित होना चाहिए। DevOps दर्शन मानता है कि सभी को कोड लिखने और इसे वास्तव में काम करने की प्रणाली में लागू करने में सक्षम होना चाहिए। हम प्रत्येक इंजीनियर को कम से कम एक बार महत्वपूर्ण डेटा रिकवरी प्रक्रियाओं में भाग लेने के लिए आमंत्रित करते हैं।हम एक विशिष्ट आवश्यकता को पूरा करने के साधन के रूप में डेटा - बैकअप और अभिलेखागार की प्रतियां बनाते हैं और स्टोर करते हैं। रिकवरी के लिए इनकी जरूरत होती है। कभी-कभी वसूली एक सुखद और इत्मीनान से भरा मामला है, उदाहरण के लिए, जब ऑडिटर्स के लिए एक वातावरण बनाते हैं या एक वैकल्पिक वातावरण स्थापित करते हैं। लेकिन सबसे अधिक बार असफल नोड्स को जल्दी से बदलने या मौजूदा समूहों की क्षमता बढ़ाने की आवश्यकता होती है।आज, वितरित वातावरण में, हम डेटा बैकअप और पुनर्प्राप्ति में नई चुनौतियों का सामना कर रहे हैं। पहले की तरह, अधिकांश स्थानीय डेटा सेट उचित सीमा के भीतर वितरित किए जाते हैं, अधिकतम कुछ टेराबाइट तक। अंतर यह है कि ये स्थानीय डेटा सेट एक बड़े वितरित सेट का केवल एक हिस्सा हैं। साइट पुनर्प्राप्ति अपेक्षाकृत नियंत्रित प्रक्रिया है, लेकिन एक क्लस्टर में राज्य बनाए रखना अधिक कठिन कार्य है।बुनियादी सिद्धांत
हम डेटा बैकअप और रिकवरी के मूल सिद्धांतों पर चर्चा करके शुरू करते हैं। एक अनुभवी डेटाबेस विशेषज्ञ या सिस्टम इंजीनियर के लिए, उनमें से कुछ प्राथमिक लग सकते हैं। यदि हां, तो आप कई पृष्ठों को आसानी से स्क्रॉल कर सकते हैं।शारीरिक या तार्किक?
डेटाबेस का एक भौतिक बैकअप वास्तविक फ़ाइलों का बैकअप लेता है जिसमें डेटा संग्रहीत होता है। इसका मतलब है कि डेटाबेस के विशिष्ट फ़ाइल प्रारूप समर्थित हैं, और आमतौर पर डेटाबेस में मेटाडेटा का एक सेट होता है जो यह निर्धारित करता है कि फाइलें क्या हैं और डेटाबेस संरचना क्या हैं। यदि, फ़ाइलों की बैकअप प्रतियां बनाते समय, आप एक अन्य डेटाबेस उदाहरण का उपयोग करने में सक्षम होने की उम्मीद करते हैं, तो आपको एक बैकअप बनाने और इसके साथ जुड़े मेटाडेटा को सहेजने की आवश्यकता होगी, जिस पर यह डेटाबेस निर्भर करता है, ताकि बैकअप पोर्टेबल हो।तार्किक बैकअप बनाते समय, डेटा डेटाबेस से एक प्रारूप में निर्यात किया जाता है जिसे सैद्धांतिक रूप से किसी भी सिस्टम में स्थानांतरित किया जा सकता है। आमतौर पर मेटाडेटा भी सहेजा जाता है, लेकिन सबसे अधिक संभावना है कि यह उस पल के लिए प्रासंगिक होगा जब बैकअप प्रदर्शन किया गया था। एक उदाहरण यह है कि अपडेट करते समय खाली डेटाबेस को पॉप्युलेट करने के लिए आवश्यक सभी इंसर्ट स्टेटमेंट्स का निर्यात। एक अन्य उदाहरण JSON स्ट्रिंग है। नतीजतन, तार्किक बैकअप, एक नियम के रूप में, बहुत समय लगता है, क्योंकि यह एक भौतिक प्रतिलिपि और लिखने का संचालन नहीं है, लेकिन पंक्ति-दर-पंक्ति डेटा निष्कर्षण है। इसी तरह, सभी सामान्य डेटाबेस ओवरहेड के साथ पुनर्प्राप्ति होती है, जैसे लॉकिंग और रीडो और पूर्ववत लॉग बनाना।इस पृथक्करण का एक बड़ा उदाहरण पंक्ति-आधारित प्रतिकृति और कथन-आधारित प्रतिकृति के बीच का अंतर है। कई संबंधपरक डेटाबेसों में, एजेंट-आधारित प्रतिकृति का मतलब है कि संस्करण नियंत्रण प्रणाली के लिए लिखने के बाद, डेटा हेरफेर भाषा (डीएमएल, या सम्मिलित करें, अपडेट, बदलें, हटाएं) के ऑपरेटरों की एक पत्रिका को उनके साथ जोड़ा जाता है। इन बयानों को प्रतिकृतियों में पारित किया जाता है जिसमें वे खेले जाते हैं। प्रतिकृति के लिए एक और दृष्टिकोण स्ट्रिंग्स या चेंज डेटा कैप्चर (सीडीसी) पर आधारित है।स्वायत्त या परिचालन?
एक ऑफ़लाइन (या ठंडा) बैकअप वह है जिसमें फ़ाइलों का उपयोग करने वाला डेटाबेस उदाहरण अक्षम है। इसके लिए धन्यवाद, आप राज्य को बनाए रखने के बारे में चिंता किए बिना फ़ाइलों को जल्दी से कॉपी कर सकते हैं, जबकि अन्य प्रक्रियाएं डेटा को पढ़ती और लिखती हैं। यह एक आदर्श, लेकिन बहुत दुर्लभ स्थिति है।एक ऑनलाइन (या हॉट) बैकअप के साथ, आप अभी भी सभी फ़ाइलों को कॉपी करते हैं, लेकिन डेटा की एक सुसंगत स्नैपशॉट प्राप्त करने की आवश्यकता से जुड़ी अतिरिक्त जटिलता है, जो उस समय मौजूद होनी चाहिए, जिसके दौरान बैकअप किया जाता है। इसके अलावा, यदि वर्तमान ट्रैफ़िक बैकअप के दौरान डेटाबेस तक पहुँचता है, तो आपको भंडारण स्तर पर I / O सबसिस्टम के थ्रूपुट से अधिक नहीं होने के लिए सावधान रहना चाहिए। यहां तक कि लोड को सीमित करते हुए, आप पा सकते हैं कि स्थिरता बनाए रखने के लिए उपयोग किए जाने वाले तंत्र आवेदन में अनुचित देरी का परिचय देते हैं।पूर्ण, वृद्धिशील और विभेदक
पूर्ण बैकअप होने के बाद, चाहे वह कोई भी विधि बनाई गई हो, इसका मतलब है कि स्थानीय डेटा सेट पूरी तरह से आरक्षित है। छोटे डेटासेट के लिए, यह बहुत आम है। 10 टीबी के लिए, यह अविश्वसनीय समय ले सकता है।डिफरेंशियल बैकअप आपको केवल पिछले बैकअप के बाद से बदले गए डेटा का बैकअप लेने की अनुमति देता है। लेकिन व्यवहार में, अधिक डेटा आमतौर पर सिर्फ बदले की तुलना में बैकअप होता है क्योंकि डेटा को एक निश्चित आकार की संरचनाओं के रूप में व्यवस्थित किया जाता है - पृष्ठ। पृष्ठ का आकार, उदाहरण के लिए, 16 या 64 Kbytes है, और पृष्ठ में डेटा की कई पंक्तियाँ हैं। विभेदक बैकअप उन सभी पृष्ठों का बैकअप लेता है, जिन पर डेटा परिवर्तित किया गया है। इस प्रकार, बड़े पृष्ठ आकार के साथ, बहुत बड़े आकार के बैकअप प्राप्त किए जाते हैं, यदि केवल संशोधित डेटा को वहां संग्रहीत किया गया था।वृद्धिशील बैकअप अंतर बैकअप के समान होते हैं, सिवाय इसके कि अंतिम बैकअप की तारीख जिसमें परिवर्तित डेटा संदर्भित होता है वह वृद्धिशील या पूर्ण है। इस प्रकार, एक वृद्धिशील बैकअप से पुनर्स्थापित करते समय, आपको वर्तमान बिंदु पर पहुंचने के लिए अंतिम पूर्ण बैकअप, साथ ही एक या एक से अधिक वृद्धिशील बैकअप की आवश्यकता हो सकती है।यह जानने के बाद, हम कई बिंदुओं पर चर्चा करेंगे जिन्हें एक प्रभावी बैकअप और डेटा रिकवरी रणनीति चुनने पर विचार किया जाना चाहिए।डेटा रिकवरी विचार
पहली बार एक प्रभावी रणनीति चुनते समय, आपको फिर से अपने सेवा गुणवत्ता लक्ष्यों (एसएलओ) पर विचार करना चाहिए, जिनकी चर्चा अध्याय 2 में की गई थी। विशेष रूप से, आपको उपलब्धता और विश्वसनीयता संकेतकों पर विचार करने की आवश्यकता है। आप अंत में जो भी रणनीति चुनते हैं, उसमें अभी भी अपटाइम पर पूर्वनिर्धारित सीमा के भीतर डेटा को पुनर्प्राप्त करने की क्षमता शामिल होनी चाहिए। और आपको अपनी विश्वसनीयता विनिर्देशों के अनुपालन को सुनिश्चित करने के लिए जल्दी से बैकअप लेना होगा।यदि आप हर दिन बैकअप लेते हैं और साइट स्तर पर संग्रहण में बैकअप के बीच लेन-देन लॉग रखते हैं, तो आप अगले बैकअप तक आसानी से इन लेनदेन को खो सकते हैं।इसके अलावा, आपको यह विचार करने की आवश्यकता है कि डेटा सेट एक समग्र पारिस्थितिकी तंत्र के भीतर कैसे कार्य करता है। उदाहरण के लिए, आपके आदेश एक रिलेशनल डेटाबेस में संग्रहीत किए जा सकते हैं, जहां सब कुछ लेनदेन के रूप में तय किया जाता है और इसलिए, इस डेटाबेस में संग्रहीत अन्य डेटा के संबंध में आसानी से बहाल किया जाता है। हालाँकि, आदेश बनने के बाद, वर्कफ़्लो को कतार प्रणाली या "की - वैल्यू" प्रकार के स्टोरेज में स्टोर किए गए ईवेंट द्वारा ट्रिगर किया जा सकता है। ये प्रणालियां डेटा अखंडता को कभी-कभार या यहां तक कि संक्षेप में (अल्पकालिक होने के लिए) सुनिश्चित कर सकती हैं, यदि आवश्यक हो, तो संबंधपरक डेटाबेस के लिए या पुनर्प्राप्ति के लिए इसका उपयोग करना। वसूली के दौरान इन वर्कफ़्लो पर कैसे विचार करें?यदि आप ऐसे वातावरण से निपट रहे हैं जहां तेजी से विकास हो रहा है, तो यह पता चल सकता है कि बैकअप में संग्रहीत डेटा को एप्लिकेशन के एक संस्करण द्वारा लिखा और उपयोग किया गया था, और एक दूसरे को पुनर्स्थापित करने के बाद निष्पादित किया जाता है। एप्लिकेशन आउटडेटेड डेटा के साथ कैसे इंटरैक्ट करेगा? ठीक है, यदि डेटा संस्करण है - तो इसे ध्यान में रखा जा सकता है, लेकिन आपको इस संभावना के बारे में पता होना चाहिए और ऐसे मामलों के लिए तैयार रहना चाहिए। अन्यथा, एप्लिकेशन तार्किक रूप से इस डेटा को नुकसान पहुंचा सकता है, जिससे भविष्य में और भी अधिक समस्याएं हो सकती हैं।डेटा रिकवरी की योजना बनाते समय इन सभी और कई अन्य बारीकियों का अनुमान नहीं लगाया जा सकता है। जैसा कि अध्याय 3 में कहा गया है, किसी भी स्थिति के लिए तैयार करना असंभव है। लेकिन इसे करने की कोशिश करना बहुत महत्वपूर्ण है। डेटाबेस रिकवरी सुनिश्चित करने के लिए डेटा रिकवरी एक इंजीनियर के सबसे महत्वपूर्ण कर्तव्यों में से एक है। इस प्रकार, आपकी डेटा रिकवरी योजना यथासंभव व्यापक होनी चाहिए और यथासंभव संभावित समस्याओं को ध्यान में रखना चाहिए।रिकवरी परिदृश्य
उपरोक्त सभी को ध्यान में रखते हुए, हम उन घटनाओं और कार्यों के प्रकारों पर चर्चा करेंगे जिनके लिए डेटा रिकवरी की आवश्यकता हो सकती है ताकि सभी आवश्यकताओं की योजना बनाई जा सके। सबसे पहले, आप सभी परिदृश्यों को नियोजित और अनियोजित में विभाजित कर सकते हैं। केवल आपात स्थिति के समाधान के लिए डेटा रिकवरी को ध्यान में रखते हुए, आप केवल आपातकालीन देखभाल और दुर्घटनाओं का अनुकरण करने के लिए अपनी टीम के टूल को सीमित करेंगे। इसके विपरीत, यदि डेटा रिकवरी को रोजमर्रा की गतिविधियों में शामिल किया जाता है, तो उच्च स्तर की जागरूकता और आपात स्थिति के सफल समाधान की उम्मीद की जा सकती है। इसके अलावा, हमारे पास यह निर्धारित करने के लिए अधिक डेटा होगा कि रिकवरी रणनीति हमारे SLO का समर्थन करती है या नहीं। स्क्रिप्ट के कुछ दैनिक रन के साथ, नमूनों का एक सेट प्राप्त करना आसान होगा,जिसमें सीमा मूल्य शामिल हैं और जिनका उपयोग योजना के लिए काफी आत्मविश्वास से किया जा सकता है।अनुसूचित पुनर्प्राप्ति परिदृश्य
क्या दैनिक कार्य प्रक्रियाओं को एकीकृत कर सकते हैं? यहाँ वह सूची है जो हम अक्सर विभिन्न साइटों पर मिलते हैं:- एक औद्योगिक संचालन वातावरण में नए नोड्स और क्लस्टर का निर्माण;
- विभिन्न वातावरणों का निर्माण;
- निष्कर्षण, परिवर्तन और लोडिंग (एक्सट्रैक्ट, ट्रांसफ़ॉर्म एंड लोड, ईटीएल) और क्रमिक रूप से रखे गए स्टोरेज के लिए डेटा प्रोसेसिंग तकनीकी प्रक्रिया के चरणों का प्रदर्शन;
- प्रदर्शन का परीक्षण।
इन ऑपरेशनों को निष्पादित करते समय, परिचालन नियंत्रण स्टैक पर पुनर्प्राप्ति प्रक्रिया को शामिल करना सुनिश्चित करें। निम्नलिखित संकेतकों पर विचार करें।- समय। प्रत्येक घटक और पूरी प्रक्रिया को पूरा करने में कितना समय लगता है? अनपैक किया? कॉपी करें? लॉग निष्पादन? परिक्षण?
- आकार। एक बैकअप कितना स्थान लेता है, संकुचित और असम्पीडित?
- . ?
यह जानकारी आपको बैंडविड्थ समस्याओं से बचने में मदद करेगी, जो वसूली प्रक्रिया की स्थिरता सुनिश्चित करने में मदद करेगी।एक औद्योगिक ऑपरेटिंग वातावरण में नए नोड्स और क्लस्टर
आपके डेटाबेस अपरिवर्तनीय बुनियादी ढांचे का हिस्सा हैं या नहीं, नियमित रूप से पुनर्वित्त के अवसर हैं, जिसमें पुनर्प्राप्ति प्रक्रियाओं को आवश्यक रूप से उपयोग किया जाएगा।नई नोड के प्रारंभिक लोडिंग और क्लस्टर में इसके प्लेसमेंट के लिए आवश्यक समय के कारण डेटाबेस को स्वचालित रूप से सिस्टम के स्केलिंग में शामिल किया जा सकता है। फिर भी, इन प्रक्रियाओं का परीक्षण करने के लिए क्लस्टर में नियमित रूप से नए नोड्स जोड़ने के लिए टीम को शेड्यूल बनाने से रोकने के लिए कोई कारण नहीं हैं। कैओस बंदर ( http://bit.ly/2zy1qsE)) - नेटफ्लिक्स द्वारा विकसित एक उपकरण जो सिस्टम को बेतरतीब ढंग से बंद कर देता है, आपको इस तरह से करने की अनुमति देता है कि आप निगरानी की पूरी प्रक्रिया को नोटिफ़िकेशन जारी कर सकते हैं, नोटिफिकेशन जारी कर सकते हैं, छँटाई और बहाल कर सकते हैं। यदि आपने पहले से ऐसा नहीं किया है, तो आप इसे उन प्रक्रियाओं की चेकलिस्ट की योजना में शामिल कर सकते हैं जो आपके परिचालन विभाग को नियमित अंतराल पर करनी चाहिए ताकि सभी कर्मचारी प्रक्रिया से परिचित हों। ये क्रियाएं आपको न केवल पूर्ण और वृद्धिशील पुनर्प्राप्ति का परीक्षण करने की अनुमति देती हैं, बल्कि प्रतिकृति को शामिल करने और ऑपरेशन के लिए नोड लगाने की प्रक्रिया भी शामिल हैं।विभिन्न वातावरण बनाएंआप अनिवार्य रूप से प्रदर्शन और अन्य उद्देश्यों के लिए विकास, एकीकरण और परिचालन परीक्षण वातावरण बनाएंगे। इन वातावरणों में से कुछ को पूर्ण डेटा पुनर्प्राप्ति की आवश्यकता होती है, और उन्हें नोड पुनर्प्राप्ति और पूर्ण क्लस्टर पुनर्प्राप्ति को लागू करने की आवश्यकता होती है। कुछ वातावरणों में अन्य आवश्यकताएं होती हैं, जैसे कि फ़ीचर टेस्टिंग के लिए आंशिक रिकवरी समर्थन और उपयोगकर्ता गोपनीयता सुनिश्चित करने के लिए डेटा क्लींजिंग। यह आपको समय में एक विशिष्ट बिंदु पर डेटा रिकवरी का परीक्षण करने की अनुमति देता है, साथ ही विशिष्ट वस्तुओं की वसूली भी करता है। यह सब मानक पूर्ण पुनर्प्राप्ति से बहुत अलग है और ऑपरेटर कार्यों और एप्लिकेशन त्रुटियों के कारण होने वाली क्षति की मरम्मत के लिए उपयोगी है। एक एपीआई बनाकर,सुविधा स्तर पर डेटा रिकवरी प्रदान करते हैं और समय पर एक विशिष्ट बिंदु पर, आप इन प्रक्रियाओं के साथ कर्मचारियों को स्वचालन और परिचित करने की सुविधा प्रदान कर सकते हैं।डेटा गोदामों के लिए ईटीएल और पाइपलाइन प्रक्रियाएं पाइपलाइन के आगे स्थित होती हैं जैसाकि पर्यावरण के निर्माण के कार्यों के लिए, स्नैपशॉट से या व्यक्तिगत वस्तुओं के स्तर पर प्रक्रियाओं और पुनर्प्राप्ति एपीआई को सफलतापूर्वक लागू किया जा सकता है जब आगे के विश्लेषण के लिए पाइपलाइनों को कार्यशील डेटाबेस से डेटा स्थानांतरित करना और भंडारण को स्ट्रीम करना है। ।फ़ील्ड परीक्षणविभिन्न परीक्षण परिदृश्यों के निष्पादन के दौरान, आपको डेटा की प्रतियों की आवश्यकता होगी। कुछ परीक्षणों, उदाहरण के लिए क्षमता और लोड के लिए, डेटा के पूर्ण सेट की आवश्यकता होती है, जो पूर्ण पुनर्प्राप्ति के लिए बहुत अच्छा है। कार्यात्मक परीक्षण के लिए छोटे डेटासेट की आवश्यकता हो सकती है, जो समय पर और सुविधा स्तर पर एक विशिष्ट बिंदु पर पुनर्प्राप्ति की अनुमति देगा।डेटा रिकवरी परीक्षण स्वयं एक सतत संचालन हो सकता है। हर रोज़ परिदृश्य में डेटा पुनर्प्राप्ति प्रक्रियाओं का उपयोग करने के अलावा, आप निरंतर पुनर्प्राप्ति संचालन को कॉन्फ़िगर कर सकते हैं। यह स्वचालित रूप से किसी भी समस्या की पहचान करने के लिए परीक्षण और सत्यापन को स्वचालित करेगा, जो बैकअप प्रक्रिया बाधित होने पर उत्पन्न हो सकती है। जब इस प्रक्रिया को लागू करने की बात आती है, तो कई पूछते हैं कि वसूली की सफलता को कैसे सत्यापित किया जाए।बैकअप बनाते समय, आप बहुत सारे डेटा प्राप्त कर सकते हैं, जिन्हें आप परीक्षण के लिए उपयोग कर सकते हैं, उदाहरण के लिए:- ऑटो-इंक्रीमेंट अनुक्रम में सबसे हाल ही में पहचानकर्ता
- वस्तुओं के लिए लाइन काउंटर;
- डेटा के सबसेट के लिए चेकसम जो केवल डाला जाता है और इसलिए अपरिवर्तनीय माना जा सकता है;
- स्कीमा परिभाषा फ़ाइलों में चेकसम।
किसी भी परीक्षण के साथ, दृष्टिकोण बहुस्तरीय होना चाहिए। ऐसे कई परीक्षण हैं जो या तो सफल होंगे या जल्दी विफल होंगे। यह परीक्षण का पहला स्तर होना चाहिए। उदाहरण मेटाडेटा / ऑब्जेक्ट परिभाषा के लिए चेकसम की तुलना कर रहे हैं, सफलतापूर्वक डेटाबेस उदाहरण शुरू कर रहे हैं, और सफलतापूर्वक एक प्रतिकृति स्ट्रीम से कनेक्ट कर रहे हैं। ऑपरेशन में अधिक समय लग सकता है, जैसे चेकसम और काउंटिंग टेबल की गणना, चेक के दौरान बाद में किया जाना चाहिए।अनियोजित स्क्रिप्ट
सभी दैनिक नियोजित परिदृश्यों को ध्यान में रखते हुए, डेटा रिकवरी प्रक्रिया को अच्छी तरह से डीबग किया जाना चाहिए, प्रलेखित किया जाना चाहिए, काम किया जाना चाहिए और त्रुटियों और समस्याओं से पर्याप्त रूप से मुक्त होना चाहिए। इस के लिए धन्यवाद, अनियोजित परिदृश्य शायद ही कभी बाहर हो जाते हैं जितना भयावह हो सकता है। टीम को नियोजित और अनियोजित वसूली के बीच अंतर नहीं देखना चाहिए। हम सूची और उन स्थितियों पर विचार करते हैं जिनसे हमें पुनर्प्राप्ति प्रक्रिया करने की आवश्यकता हो सकती है:- उपयोगकर्ता की त्रुटि
- अनुप्रयोग त्रुटि;
- अवसंरचना सेवाओं की उपलब्धता;
- ऑपरेटिंग सिस्टम त्रुटियाँ और हार्डवेयर त्रुटियाँ;
- हार्डवेयर विफलताओं;
- डेटा सेंटर विफलताओं।
उपयोगकर्तात्रुटि आदर्श रूप से, उपयोगकर्ता त्रुटियों को शायद ही कभी होना चाहिए। इंजीनियरों के लिए एक "रेलिंग" और एक "बाधा" का निर्माण करके, आप इनमें से कई स्थितियों को रोक सकते हैं। हालांकि, हमेशा संभावना है कि ऑपरेटर गलती से नुकसान पहुंचाएगा। डेटाबेस क्लाइंट एप्लिकेशन में UPDATE या DELETE निष्पादित करते समय एक विशिष्ट उदाहरण हर जगह और सभी भूले हुए लोगों के लिए है। या, उदाहरण के लिए, डेटा सफाई स्क्रिप्ट का निष्पादन एक परीक्षण वातावरण में नहीं है, लेकिन एक "उत्पादन" प्रणाली में है। अक्सर ऑपरेशन सही ढंग से किया जाता है, लेकिन गलत समय पर या उन मेजबानों के लिए नहीं। यह सब उपयोगकर्ता की त्रुटियों से संबंधित है। अक्सर उन्हें पहचान कर तुरंत ठीक कर दिया जाता है। हालांकि, कभी-कभी ऐसे परिवर्तनों के परिणाम कई दिनों या हफ्तों तक किसी का ध्यान नहीं जाता है।अनुप्रयोग त्रुटियांअनुप्रयोग त्रुटियों की चर्चा परिदृश्यों में से सबसे खराब है, क्योंकि वे बहुत कपटी हो सकते हैं। अनुप्रयोग लगातार डेटा वेयरहाउस के साथ बातचीत करने के तरीके को बदल रहे हैं। कई एप्लिकेशन संसाधनों या फ़ाइलों या तृतीय-पक्ष पहचानकर्ताओं जैसे संदर्भात्मक अखंडता और बाह्य संकेत को भी प्रबंधित करते हैं। यह कल्पना करना डरावना है कि क्या होगा यदि आप केवल एक बदलाव करते हैं जो डेटा को खराब करता है, उन्हें हटाता है या उन तरीकों से गलत डेटा जोड़ता है जो काफी समय तक किसी का ध्यान नहीं जा सकते हैं।इंफ्रास्ट्रक्चर सर्विसेजअध्याय 6 में, हमने बुनियादी ढांचा प्रबंधन सेवाओं का जादू पेश किया। दुर्भाग्य से, ये सिस्टम उपयोगी के रूप में विनाशकारी हो सकते हैं, जिससे किसी फ़ाइल को संपादित करने, किसी अन्य वातावरण या गलत कॉन्फ़िगरेशन सेटिंग्स की ओर संकेत करने से बड़े पैमाने पर परिणाम हो सकते हैं।ओएस त्रुटियों और हार्डवेयर त्रुटियोंऑपरेटिंग सिस्टम और उपकरण जिनके साथ वे बातचीत करते हैं वे भी लोगों द्वारा बनाई गई प्रणालियां हैं, और इस प्रकार त्रुटियां उनमें हो सकती हैं जो अनजाने या खराब ज्ञात कॉन्फ़िगरेशन के कारण अप्रत्याशित परिणाम हो सकते हैं। डेटा रिकवरी के संदर्भ में, यह विशेष रूप से डेटा से संबंधित है जिस तरह से डेटा डेटाबेस से ओएस कैश के माध्यम से फाइल सिस्टम, कंट्रोलर और अंततः डिस्क में स्थानांतरित किया जाता है। नुकसान या डेटा का नुकसान बहुत बार होता है जितना हम सोचते हैं। दुर्भाग्य से, इन तंत्रों पर हमारा भरोसा और निर्भरता इसके बारे में संशयवाद के बजाय डेटा अखंडता की उम्मीद को जन्म देता है।
Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?
. , , . , . — .
, ZFS, , . RAID-, , .
हार्डवेयर विफलताओंहार्डवेयर घटक सिद्धांत रूप में विफल होते हैं, और वितरित प्रणालियों में यह नियमित रूप से होता है। आप लगातार डिस्क, मेमोरी, प्रोसेसर, नियंत्रक और नेटवर्क डिवाइस विफलताओं का सामना करते हैं। इन हार्डवेयर विफलताओं के परिणाम नोड्स या नोड्स पर देरी की विफलता हो सकती है, जो सिस्टम को अनुपयोगी बनाता है। साझा उपकरण, जैसे कि नेटवर्क डिवाइस, पूरे समूहों को प्रभावित कर सकते हैं, उन्हें दुर्गम बना सकते हैं या उन्हें छोटे समूहों में तोड़ सकते हैं जो इस बात से अवगत नहीं हैं कि नेटवर्क विभाजित हो गया है। इससे डेटा में त्वरित और महत्वपूर्ण विसंगतियां हो सकती हैं जिन्हें संयुक्त और सही करने की आवश्यकता है।डेटा सेंटर विफलताओंकभी-कभी नेटवर्क स्तर पर हार्डवेयर समस्याओं से डेटा सेंटर में क्रैश हो जाता है। ऐसा होता है कि स्टोरेज बैकप्लेन को ओवरलोड करने से कैस्केडिंग विफलताओं का कारण बनता है, जैसा कि 2012 में अमेज़ॅन वेब सेवाओं के साथ हुआ था ( http://bit.ly/2zxSpzR )। कभी-कभी तूफान, भूकंप और अन्य आपदाएं पूरे डेटा केंद्रों की विफलता का कारण बनती हैं। इसके बाद की वसूली ताकत के लिए सबसे विश्वसनीय वसूली रणनीतियों का भी परीक्षण करेगी।स्क्रिप्ट का दायरा
नियोजित और अनियोजित परिदृश्यों की गणना करने के बाद, जिन्हें पुनर्प्राप्ति की आवश्यकता हो सकती है, हम इन घटनाओं में एक और आयाम जोड़ते हैं ताकि हमारी प्रस्तुति चमकदार हो जाए। यह सबसे उपयुक्त प्रतिक्रिया विधि चुनने के लिए उपयोगी होगा। निम्नलिखित विकल्पों पर विचार करें:- एक नोड के भीतर स्थानीयकृत विफलता;
- पूरे क्लस्टर की विफलता;
- एक विफलता जो पूरे डेटा सेंटर या कई समूहों को प्रभावित करती है।
स्थानीय, या एकल-साइट की स्थिति में, विफलता, पुनर्प्राप्ति एक होस्ट तक सीमित है। आप क्षमता बढ़ाने या विफल नोड को बदलने के लिए क्लस्टर में एक नया नोड जोड़ सकते हैं। या, सिस्टम निरंतर अद्यतन को लागू करता है और फिर बहाली नोड द्वारा नोड किया जाएगा। किसी भी मामले में, यह एक स्थानीय वसूली है।क्लस्टर स्तर पर, इस क्लस्टर के सभी सदस्यों के लिए रिकवरी की आवश्यकता वैश्विक है। शायद डेटा का एक विनाशकारी परिवर्तन या विलोपन था जो सभी नोड्स को कैस्केड करता था। या आपको क्षमता का परीक्षण करने के लिए एक नया क्लस्टर शुरू करने की आवश्यकता है।यदि डेटा सेंटर या कई क्लस्टर के पैमाने पर विफलता थी, तो इसका मतलब है कि सभी डेटा को उनके भौतिक स्थान या विफलता के पूरे क्षेत्र में पुनर्स्थापित करना आवश्यक है। यह साझा डेटा वेयरहाउस की विफलता या डेटा केंद्र की एक भयावह विफलता के कारण हो सकता है। एक नए माध्यमिक साइट की नियोजित तैनाती के दौरान इस तरह की वसूली की आवश्यकता हो सकती है।स्कोप के अलावा, डेटासेट स्कोप है। यहां आप तीन संभावित विकल्पों को सूचीबद्ध कर सकते हैं:- एक वस्तु;
- कई वस्तुओं;
- डेटाबेस मेटाडेटा।
एक वस्तु के पैमाने पर, केवल इस विशेष वस्तु को डेटा रिकवरी की आवश्यकता होती है - कुछ या सभी। इस मामले पर पहले चर्चा की गई थी, जिसके परिणामस्वरूप जब DELETE ऑपरेशन किया गया था, तो नियोजित की तुलना में अधिक डेटा हटा दिया गया था, उसी ऑब्जेक्ट के भीतर विफलता को संदर्भित करता है। यदि कई ऑब्जेक्ट विफल हो जाते हैं, तो कई, या संभवतः, किसी विशेष डेटाबेस में सभी ऑब्जेक्ट प्रभावित होते हैं। यह तब हो सकता है जब अनुप्रयोग क्षतिग्रस्त हो, अद्यतन या खंड माइग्रेशन विफल हो जाता है। अंत में, डेटाबेस मेटाडेटा के पैमाने पर क्रैश होते हैं, जब सब कुछ डेटाबेस में संग्रहीत डेटा के साथ होता है, लेकिन मेटाडेटा जो इसे उपयोग करने योग्य बनाता है, जैसे उपयोगकर्ता डेटा, सुरक्षा विशेषाधिकार, या ओएस फ़ाइलों का अनुपालन।स्क्रिप्ट के परिणाम
यह न केवल वसूली की आवश्यकता वाले परिदृश्य की पहचान करने और विफलता के क्षेत्र की पहचान करने के लिए महत्वपूर्ण है, बल्कि संभावित परिणामों को निर्धारित करने के लिए भी है, क्योंकि वे पुनर्प्राप्ति के लिए एक दृष्टिकोण चुनते समय महत्वपूर्ण होंगे। यदि डेटा हानि SLO को प्रभावित नहीं करती है, तो आप एक पद्धतिगत और धीमी गति से दृष्टिकोण चुन सकते हैं जो परिणामों के विस्तार को कम करता है। एसएलओ के विघटन के लिए नेतृत्व करने वाले अधिक वैश्विक परिवर्तनों को सावधानी के साथ संपर्क किया जाना चाहिए, एक त्वरित सेवा पुनर्प्राप्ति का चयन करना और उसके बाद ही लंबी अवधि के लिए सफाई पर आगे बढ़ना। सभी दृष्टिकोणों को निम्नलिखित तीन श्रेणियों में विभाजित किया जा सकता है।- एसएलओ पर प्रभाव, अनुप्रयोग विफलता, अधिकांश उपयोगकर्ताओं को प्रभावित किया।
- धमकी SLO, कुछ उपयोगकर्ताओं को भुगतना पड़ा है।
- एसएलओ को धमकी नहीं देने वाले कार्य प्रभावित होते हैं।
लेखक के बारे में
कैंपबेल लेन (Laine कैंपबेल) डिजाइन कंपनी के लिए एक वरिष्ठ प्रबंधक (वरिष्ठ निदेशक) है। वह PalominoDB / Blackbird के संस्थापक और सीईओ भी थे, एक परामर्श सेवा है जो कई कंपनियों के लिए डेटाबेस का रखरखाव करती है, जिसमें अमेरिका के लिए ओबामा, एक्टिवेशन कॉल ऑफ ड्यूटी, एडोब इकोसिग्न, टेक्नोराती, लाइवजर्नल, और ज़ेडसर्कल्स शामिल हैं। उसे 18 साल का अनुभव ऑपरेटिंग डेटाबेस और स्केलेबल वितरित सिस्टम है।चेरिटी मेजर(चैरिटी मेजर) मधुकोश के सीईओ और सह-संस्थापक हैं। लॉग एग्रीगेटर्स की सटीकता, टाइम सीरीज़ स्पीड मेट्रिक्स, और एप्लिकेशन परफॉरमेंस मेट्रिक्स (APMs) के लचीलेपन को मिलाकर, मधुकोश दुनिया की पहली सही मायने में नई पीढ़ी की विश्लेषणात्मक सेवा है। चेरिती पहले एक पार्स / फेसबुक ऑपरेशंस विशेषज्ञ थी, जो मोंगोडीबी प्रतिकृति सेटों के एक विशाल बेड़े का प्रबंधन करती है, साथ ही रेडिस, कैसेंड्रा, और मायक्यूएस। उसने फेसबुक पर RocksDB टीम के साथ मिलकर काम किया, स्टोरेज प्लग-इन API का उपयोग करके दुनिया के पहले Mongo + Rocks इंस्टॉलेशन के विकास और तैनाती में भाग लिया।»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट» सामग्री» अंश पर पाई जा सकती हैKhabrozhiteley कूपन पर 25% छूट के लिए - डेटाबेसपुस्तक के कागज संस्करण के भुगतान करने पर, एक इलेक्ट्रॉनिक पुस्तक ई-मेल द्वारा भेजा जाता है।