वाल-जी से बैकअप। 2019 में क्या है? एंड्री बोरोडिन

मेरा सुझाव है कि आप एंड्री बोरोडिन की 2019 की शुरुआत की रिपोर्ट "बैकअप विद वाल-जी। 2019 में क्या है?"

नमस्ते! मेरा नाम एंड्री बोरोडिन है। मैं यांडेक्स में डेवलपर हूं। मुझे 2016 से PostgreSQL में दिलचस्पी है, जब मैंने डेवलपर्स से बात की और उन्होंने कहा कि सब कुछ सरल है - आप स्रोत कोड लें और इसे बनाएं, और सब कुछ काम करेगा। और तब से मैं रुक नहीं सकता - मैं हर तरह की अलग-अलग चीजें लिखता हूं।

जिन चीजों पर मैं काम कर रहा हूं उनमें से एक बैकअप सिस्टम है। वाल-जी. सामान्य तौर पर, Yandex में हम बहुत लंबे समय से PostgreSQL में बैकअप सिस्टम पर काम कर रहे हैं। और आप इंटरनेट पर छह रिपोर्टों की एक श्रृंखला पा सकते हैं कि हम बैकअप सिस्टम कैसे बनाते हैं। और हर साल वे थोड़ा विकसित होते हैं, थोड़ा विकसित होते हैं, और अधिक विश्वसनीय हो जाते हैं।

लेकिन आज की रिपोर्ट केवल इस बारे में नहीं है कि हमने क्या किया है, बल्कि यह भी है कि यह कितना सरल है और क्या है। आपमें से कितने लोग पहले ही वाल-जी के बारे में मेरी रिपोर्ट देख चुके हैं? यह अच्छा है कि बहुत से लोगों ने नहीं देखा, क्योंकि मैं सबसे सरल चीज़ से शुरुआत करूँगा।

यदि अचानक आपके पास एक PostgreSQL क्लस्टर है, और मुझे लगता है कि हर किसी के पास उनमें से कुछ हैं, और अचानक अभी तक कोई बैकअप सिस्टम नहीं है, तो आपको कोई S3 स्टोरेज या Google क्लाउड संगत स्टोरेज प्राप्त करने की आवश्यकता है।

उदाहरण के लिए, आप हमारे स्टैंड पर आ सकते हैं और यांडेक्स ऑब्जेक्ट स्टोरेज के लिए एक प्रचार कोड ले सकते हैं, जो S3 संगत है।

फिर एक बाल्टी बनाएं. यह सिर्फ जानकारी के लिए एक कंटेनर है।

एक सेवा उपयोगकर्ता बनाएँ.

सेवा उपयोगकर्ता के लिए एक एक्सेस कुंजी बनाएं: aws-s3-key.

वाल-जी की नवीनतम स्थिर रिलीज़ डाउनलोड करें।

हमारी प्री-रिलीज़ रिलीज़ से किस प्रकार भिन्न हैं? मुझसे अक्सर जल्दी रिहा होने के लिए कहा जाता है। और यदि पर्याप्त समय, उदाहरण के लिए, एक महीने तक संस्करण में कोई बग नहीं है, तो मैं इसे जारी कर देता हूं। यहां नवंबर से यह रिलीज है। और इसका मतलब यह है कि हर महीने हमें किसी प्रकार का बग मिलता है, आमतौर पर गैर-महत्वपूर्ण कार्यक्षमता में, लेकिन हमने अभी तक कोई रिलीज़ जारी नहीं की है। पिछला संस्करण केवल नवंबर का है। इसमें हमें कोई भी बग ज्ञात नहीं है, अर्थात जैसे-जैसे प्रोजेक्ट आगे बढ़ा, वैसे-वैसे बग जुड़ते गए।

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

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

इसका मतलब है कि आपको सेटिंग्स में जाकर "archive_mode = on" चालू करना होगा और "archive_command" जोड़ना होगा, जो कि WAL-G में एक उपकमांड भी है। लेकिन किसी कारण से लोग अक्सर इस विषय पर बार स्क्रिप्ट का उपयोग करते हैं और इसे वाल-जी के आसपास लपेट देते हैं। कृपया ऐसा न करें. वाल-जी में पाई गई कार्यक्षमता का उपयोग करें। यदि आप कुछ भूल रहे हैं तो लिखें GitHub. वाल-जी मानता है कि यह एकमात्र प्रोग्राम है जो आर्काइव_कमांड में चलता है।

हम यांडेक्स डेटाबेस प्रबंधन में उच्च उपलब्धता क्लस्टर बनाने के लिए मुख्य रूप से WAL-G का उपयोग करते हैं।

और इसका उपयोग आमतौर पर एक मास्टर और कई प्रतिकृति की टोपोलॉजी में किया जाता है। साथ ही, यह यांडेक्स ऑब्जेक्ट स्टोरेज में एक बैकअप कॉपी बनाता है।

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

आमतौर पर, नया नोड जोड़ते समय हमें बैकअप सिस्टम प्रदर्शन की आवश्यकता होती है। यह महत्वपूर्ण क्यों है? आमतौर पर लोग क्लस्टर में एक नया नोड जोड़ते हैं क्योंकि मौजूदा क्लस्टर रीड लोड को संभाल नहीं सकता है। उन्हें एक नई प्रतिकृति जोड़ने की आवश्यकता है. यदि हम pg_basebackup से लोड को मास्टर में जोड़ते हैं, तो मास्टर ध्वस्त हो सकता है। इसलिए, हमारे लिए यह बहुत महत्वपूर्ण था कि हम संग्रह से एक नया नोड जल्दी से अपलोड कर सकें, जिससे मास्टर पर न्यूनतम भार पैदा हो।

और ऐसी ही एक और स्थिति. क्लस्टर मास्टर को डेटा सेंटर से स्विच करने के बाद पुराने मास्टर को पुनः आरंभ करने की आवश्यकता है जिसके साथ कनेक्टिविटी खो गई थी।

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

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

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

हम जिस मुख्य विचारधारा का पालन करते हैं वह यह है कि वाल-जी को बालिका की तरह सरल होना चाहिए।

वाल-जी के पास 4 कमांड हैं। यह:

वाल-पुश - शाफ्ट को संग्रहित करें।

वाल-फ़ेच - एक शाफ्ट प्राप्त करें।

बैकअप-पुश - बैकअप बनाएं।

बैकअप-फ़ेच - बैकअप सिस्टम से बैकअप प्राप्त करें।

वास्तव में, WAL-G के पास इन बैकअप का प्रबंधन भी है, यानी इतिहास में उन रिकॉर्ड और बैकअप को सूचीबद्ध करना और हटाना जिनकी फिलहाल आवश्यकता नहीं है।

हमारे लिए महत्वपूर्ण कार्यों में से एक डेल्टा प्रतियां बनाने का कार्य है।

डेल्टा प्रतियों का मतलब है कि हम पूरे क्लस्टर का पूर्ण बैकअप नहीं बनाते हैं, बल्कि क्लस्टर में बदली हुई फ़ाइलों के केवल बदले हुए पृष्ठ बनाते हैं। ऐसा प्रतीत होता है कि कार्यात्मक रूप से यह वाल का उपयोग करके पुनर्प्राप्त करने की क्षमता के समान है। लेकिन हम समानांतर में वाल सिंगल-थ्रेडेड डेल्टा बैकअप रोल कर सकते हैं। तदनुसार, जब हम शनिवार को बुनियादी बैकअप बनाते हैं, डेल्टा बैकअप दैनिक करते हैं, और गुरुवार को हम विफल हो जाते हैं, तो हमें 4 डेल्टा बैकअप और 10 घंटे का वाल रोल करने की आवश्यकता होती है। इसमें लगभग उतना ही समय लगेगा क्योंकि डेल्टा बैकअप समानांतर में चलते हैं।

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

जैसा कि मैंने कहा, समानता पर काफ़ी ध्यान दिया गया।

लेकिन PostgreSQL में संग्रह एपीआई सुसंगत है। PostgreSQL एक WAL फ़ाइल को संग्रहीत करता है और इसे पुनर्स्थापित करते समय एक WAL फ़ाइल का अनुरोध करता है। लेकिन जब डेटाबेस "WAL-FETCH" कमांड का उपयोग करके एक WAL फ़ाइल का अनुरोध करता है, तो हम "WAL-PREFETCH" कमांड को कॉल करते हैं, जो समानांतर में ऑब्जेक्ट स्टोर से डेटा लाने के लिए अगली 8 फाइलें तैयार करता है।

और जब डेटाबेस हमसे एक फ़ाइल को संग्रहित करने के लिए कहता है, तो हम Archive_status को देखते हैं और देखते हैं कि क्या अन्य WAL फ़ाइलें हैं। और हम समानांतर में वाल डाउनलोड करने का भी प्रयास कर रहे हैं। यह एक महत्वपूर्ण प्रदर्शन लाभ प्रदान करता है और अनारक्षित वाल की संख्या में दूरी को काफी कम कर देता है। कई बैकअप सिस्टम डेवलपर्स का मानना ​​है कि यह इतना जोखिम भरा सिस्टम है क्योंकि हम कोड के आंतरिक ज्ञान पर भरोसा करते हैं जो कि PostgreSQL API नहीं है। PostgreSQL हमारे लिए Archive_status फ़ोल्डर की उपस्थिति की गारंटी नहीं देता है और वहां WAL फ़ाइलों के लिए शब्दार्थ, तत्परता संकेतों की उपस्थिति की गारंटी नहीं देता है। फिर भी, हम स्रोत कोड का अध्ययन कर रहे हैं, हम देखते हैं कि यह ऐसा है और हम इसका फायदा उठाने की कोशिश कर रहे हैं। और हम उस दिशा को नियंत्रित करते हैं जिसमें PostgreSQL विकसित हो रहा है; यदि अचानक यह तंत्र टूट जाता है, तो हम इसका उपयोग बंद कर देंगे।

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

इसका मतलब यह है कि हर बार जब हम मास्टर पर वाल को संग्रहित करते हैं, तो हम न केवल इसे संपीड़ित करते हैं, इसे एन्क्रिप्ट करते हैं और नेटवर्क पर भेजते हैं, बल्कि हम इसे उसी समय पढ़ते भी हैं। हम इसमें रिकॉर्ड का विश्लेषण करते हैं और पढ़ते हैं। हम समझते हैं कि कौन से ब्लॉक बदल गए हैं और डेल्टा फ़ाइलें एकत्र करते हैं।

एक डेल्टा फ़ाइल वाल फ़ाइलों की एक निश्चित श्रेणी का वर्णन करती है, इस जानकारी का वर्णन करती है कि वाल की इस श्रेणी में कौन से ब्लॉक बदले गए थे। और फिर इन डेल्टा फ़ाइलों को संग्रहीत भी किया जाता है।

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

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

यदि हमारे शाफ्ट पार्सिंग के इतिहास में कम से कम एक बिंदु है जहां हमें समझ नहीं आ रहा है कि क्या हो रहा है, तो, तदनुसार, अगले बैकअप के दौरान हमें पूरे क्लस्टर को फिर से पढ़ने के लिए मजबूर किया जाएगा, जैसा कि हमने नियमित एलएसएन के साथ किया था। -आधारित डेल्टा.

परिणामस्वरूप, हमारी सारी पीड़ा इस तथ्य के कारण हुई कि हमने वाल-जी पार्सिंग लाइब्रेरी को ओपन-सोर्स किया। जहां तक ​​मेरी जानकारी है, अभी तक इसका उपयोग कोई नहीं कर रहा है, लेकिन अगर कोई इसे लिखना और उपयोग करना चाहता है, तो यह सार्वजनिक डोमेन में है। (अद्यतन लिंक https://github.com/wal-g/wal-g/tree/master/internal/walparser)

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

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

चूँकि हमें इस बात की जानकारी है कि डेटाबेस के इतिहास में कौन से ब्लॉक और किस समय बदले गए, हम आगे बढ़े और कार्यक्षमता को एकीकृत करने का निर्णय लिया - एक पोस्टग्रेएसक्यूएल एक्सटेंशन जिसे "pg_prefaulter" कहा जाता है।

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

अभी कोड में यही है.

ऐसी विशेषताएं हैं जिन्हें हम जोड़ना चाहेंगे।

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

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

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

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

लेकिन यह अभी भी एक विचार है जिस पर हमारे भीतर सक्रिय रूप से चर्चा हो रही है, लेकिन यह अभी तक कोड तक नहीं पहुंच पाया है।

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

और इसी तरह, MySQL रिस्टोर के दौरान, कोई रिस्टोर कमांड नहीं है जो सिस्टम को बता सके कि मुझे फलां फाइल की जरूरत है। इससे पहले कि आप अपने क्लस्टर का पुनर्निर्माण शुरू करें, आपको यह जानना होगा कि आपको किन फ़ाइलों की आवश्यकता होगी। आपको स्वयं अनुमान लगाना होगा कि आपको किन फ़ाइलों की आवश्यकता होगी। लेकिन इन समस्याओं से किसी तरह बचा जा सकता है। (स्पष्टीकरण: MySQL पहले से ही समर्थित है)

रिपोर्ट में मैं उन मामलों के बारे में भी बात करना चाहता था जब वाल-जी आपके लिए उपयुक्त नहीं है।

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

मैं अक्सर लोगों को एक ही समय में WAL-G और WAL-E दोनों को चलाने का प्रयास करते देखता हूँ। हम इस अर्थ में बैकवर्ड संगतता का समर्थन करते हैं कि WAL-G, WAL-E से एक फ़ाइल को पुनर्स्थापित कर सकता है और WAL-E में बनाए गए बैकअप को पुनर्स्थापित कर सकता है। लेकिन चूंकि ये दोनों सिस्टम समानांतर वॉल-पुश का उपयोग करते हैं, इसलिए वे एक-दूसरे से फ़ाइलें चुराना शुरू कर देते हैं। यदि हम इसे WAL-G में ठीक कर दें, तो भी यह WAL-E में ही रहेगा। WAL-E में, यह संग्रह-स्थिति को देखता है, तैयार फ़ाइलों को देखता है और उन्हें संग्रहीत करता है, जबकि अन्य प्रणालियों को बस यह पता नहीं चलेगा कि यह WAL फ़ाइल मौजूद थी, क्योंकि PostgreSQL इसे दूसरी बार संग्रहीत करने का प्रयास नहीं करेगा।

हम यहां वाल-जी की ओर क्या ठीक करने जा रहे हैं? हम PostgreSQL को सूचित नहीं करेंगे कि यह फ़ाइल समानांतर में स्थानांतरित की गई थी, और जब PostgreSQL हमें इसे संग्रहीत करने के लिए कहता है, तो हमें पहले से ही पता चल जाएगा कि इस मोड-टाइम और इस md5 के साथ ऐसी फ़ाइल पहले ही संग्रहीत की जा चुकी है और हम बस PostgreSQL कहेंगे - ठीक है, बिना कुछ किए ही सब कुछ तैयार है।

लेकिन इस समस्या को WAL-E पक्ष पर ठीक किए जाने की संभावना नहीं है, इसलिए वर्तमान में एक संग्रह कमांड बनाना असंभव है जो फ़ाइल को WAL-G और WAL-E दोनों में संग्रहीत करेगा।

इसके अलावा, ऐसे मामले भी हैं जहां वाल-जी अब आपके लिए उपयुक्त नहीं है, लेकिन हम इसे निश्चित रूप से ठीक कर देंगे।

सबसे पहले, वर्तमान में हमारे पास अंतर्निहित बैकअप सत्यापन नहीं है। बैकअप या पुनर्प्राप्ति के दौरान हमारे पास सत्यापन नहीं होता है। बेशक, इसे क्लाउड में लागू किया गया है। लेकिन इसे केवल पूर्व-जाँच करके, केवल क्लस्टर को पुनर्स्थापित करके कार्यान्वित किया जाता है। मैं उपयोगकर्ताओं को यह कार्यक्षमता देना चाहूंगा. लेकिन सत्यापन से, मैं मानता हूं कि वाल-जी में क्लस्टर को पुनर्स्थापित करना और इसे शुरू करना और धुआं परीक्षण चलाना संभव होगा: pg_dumpall से /dev/null और amcheck सूचकांक सत्यापन।

वर्तमान में वाल-जी में वाल से एक बैकअप को स्थगित करने का कोई तरीका नहीं है। यानी हम कुछ विंडो को सपोर्ट करते हैं. उदाहरण के लिए, पिछले सात दिनों को संग्रहीत करना, अंतिम दस बैकअप संग्रहीत करना, अंतिम तीन पूर्ण बैकअप संग्रहीत करना। अक्सर लोग आते हैं और कहते हैं: "हमें नए साल पर जो हुआ उसका बैकअप चाहिए और हम इसे हमेशा के लिए रखना चाहते हैं।" वाल-जी अभी तक ऐसा नहीं कर सकता. (नोट - इसे पहले ही ठीक कर दिया गया है। और पढ़ें - बैकअप-मार्क विकल्प https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

और PITR को मान्य करते समय हमारे पास सभी शाफ्ट खंडों के लिए पेज चेकसम और अखंडता जांच नहीं होती है।

इन सब से मैंने Google Summer of Code के लिए एक प्रोजेक्ट तैयार किया। यदि आप ऐसे स्मार्ट छात्रों को जानते हैं जो गो में कुछ लिखना चाहते हैं और "जी" अक्षर वाली एक कंपनी से कई हजार डॉलर प्राप्त करना चाहते हैं, तो उन्हें हमारे प्रोजेक्ट की सिफारिश करें। मैं इस प्रोजेक्ट के लिए मेंटर की भूमिका निभाऊंगा, वे ऐसा कर सकते हैं। यदि कोई छात्र नहीं हैं, तो मैं इसे ले लूंगा और गर्मियों में इसे स्वयं करूंगा।

और हमारी कई अन्य छोटी-छोटी समस्याएं हैं जिन पर हम धीरे-धीरे काम कर रहे हैं। और कुछ बहुत ही अजीब चीजें घटती हैं।

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

हम नहीं जानते कि ऑफलाइन बैकअप कैसे करें। यदि डेटाबेस झूठ बोल रहा है तो हम उसका बैकअप नहीं ले सकते। लेकिन यहां सब कुछ बहुत सरल है. जब यह प्रारंभ हुआ तो हम बैकअप को LSN कहते हैं। अंतर्निहित आधार का एलएसएन नियंत्रण फ़ाइल से पढ़ा जाना चाहिए। और यह एक ऐसी अवास्तविक विशेषता है. कई बैकअप सिस्टम अंतर्निहित डेटाबेस का बैकअप ले सकते हैं। और यह सुविधाजनक है.

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

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

हमारे पास यांडेक्स डेटाबेस प्रबंधन में एक हजार से अधिक क्लस्टरों पर WAL-G चल रहा है। और यह हर दिन कई सौ टेराबाइट्स डेटा का बैकअप लेता है।

हमारे कोड में बहुत सारे TODO हैं। यदि आप प्रोग्राम करना चाहते हैं, तो आइए, हम पुल अनुरोधों की प्रतीक्षा कर रहे हैं, हम प्रश्नों की प्रतीक्षा कर रहे हैं।

सवाल

शुभ संध्या! धन्यवाद! मेरा अनुमान है कि यदि आप वाल-डेल्टा का उपयोग कर रहे हैं, तो आप संभवतः पूर्ण-पृष्ठ लेखन पर बहुत अधिक भरोसा कर रहे हैं। और यदि हां, तो क्या आपने परीक्षण चलाए? आपने एक सुंदर ग्राफ़ दिखाया. यदि एफपीडब्ल्यू बंद कर दिया जाए तो यह कितना अधिक सुंदर हो जाता है?

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

रिपोर्ट के लिए धन्यवाद! मेरे दो प्रश्न हैं. पहला सवाल यह है कि टेबलस्पेस का क्या होगा?

हम पुल अनुरोध की प्रतीक्षा कर रहे हैं. हमारे डेटाबेस SSD और NMVE डिस्क पर रहते हैं और हमें वास्तव में इस सुविधा की आवश्यकता नहीं है। मैं अभी इसे अच्छी तरह से करने पर गंभीर समय खर्च करने के लिए तैयार नहीं हूं। मैं तहे दिल से वकालत करता हूं कि हम इसका समर्थन करें। ऐसे लोग हैं जिन्होंने इसका समर्थन किया, लेकिन उस तरीके से इसका समर्थन किया जो उनके अनुकूल था। उन्होंने एक कांटा बनाया, लेकिन वे पुल अनुरोध नहीं करते। (संस्करण 0.2.13 में जोड़ा गया)

और दूसरा प्रश्न. आपने शुरुआत में ही कहा था कि वाल-जी मानता है कि यह अकेले काम करता है और किसी रैपर की जरूरत नहीं है। मैं स्वयं रैपर का उपयोग करता हूं। उनका उपयोग क्यों नहीं किया जाना चाहिए?

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

शुभ संध्या! रिपोर्ट के लिए धन्यवाद! हम GPG डिक्रिप्शन के साथ काम करने के लिए WAL-G को प्राप्त करने में असमर्थ थे। यह सामान्य रूप से एन्क्रिप्ट करता है, लेकिन डिक्रिप्ट नहीं करना चाहता। क्या यह कुछ ऐसा है जो हमारे लिए कारगर नहीं रहा? स्थिति निराशाजनक है.

GitHub पर एक मुद्दा बनाएं और आइए इसका पता लगाएं।

यानी आपका सामना नहीं हुआ?

त्रुटि रिपोर्ट की एक विशेषता यह है कि जब वाल-जी को समझ नहीं आता कि यह किस प्रकार की फ़ाइल है, तो वह पूछता है: "शायद यह एन्क्रिप्टेड है?" शायद समस्या एन्क्रिप्शन की नहीं है. मैं इस विषय पर लॉगिंग में सुधार करना चाहता हूं। उसे इसे समझना होगा. हम वर्तमान में इस विषय पर इस अर्थ में काम कर रहे हैं कि हमें वास्तव में यह पसंद नहीं है कि सार्वजनिक और निजी कुंजी प्राप्त करने की प्रणाली कैसे व्यवस्थित की जाती है। क्योंकि हम external GPG इसलिए कहते हैं ताकि वह हमें अपनी key दे सके। और फिर हम इन कुंजियों को लेते हैं और उन्हें आंतरिक जीपीजी में स्थानांतरित करते हैं, जो खुला पीजीपी है, जो हमारे लिए वाल-जी के अंदर संकलित है, और वहां हम एन्क्रिप्शन कहते हैं। इस संबंध में, हम सिस्टम में सुधार करना चाहते हैं और लिबसोडियम एन्क्रिप्शन का समर्थन करना चाहते हैं (संस्करण 0.2.15 में जोड़ा गया)। बेशक, डिकोडिंग काम करना चाहिए, आइए इसे समझें - आपको कुछ शब्दों की तुलना में एक लक्षण की अधिक आवश्यकता है। आप कभी वक्ता के कमरे में इकट्ठा होकर व्यवस्था देख सकते हैं. (बाहरी जीपीजी के बिना पीजीपी एन्क्रिप्शन - v0.2.9)

नमस्ते! रिपोर्ट के लिए धन्यवाद! मेरे दो प्रश्न हैं. मुझे दो प्रदाताओं में pg_basebackup और WAL लॉग इन करने की अजीब इच्छा है, यानी मैं एक क्लाउड और दूसरा करना चाहता हूं। क्या ऐसा करने का कोई तरीका है?

यह अब मौजूद नहीं है, लेकिन यह एक दिलचस्प विचार है।

मैं सिर्फ एक प्रदाता पर भरोसा नहीं करता, मैं चाहता हूं कि दूसरे प्रदाता पर भी वैसा ही भरोसा हो।

विचार दिलचस्प है. तकनीकी रूप से इसे लागू करना बिल्कुल भी मुश्किल नहीं है। विचार को लुप्त होने से बचाने के लिए, क्या मैं आपसे GitHub पर एक मुद्दा बनाने के लिए कह सकता हूँ?

हाँ, बिल्कुल.

और फिर, जब छात्र Google समर ऑफ़ कोड में आएंगे, तो हम उन्हें प्रोजेक्ट में जोड़ देंगे ताकि उनसे और अधिक प्राप्त करने के लिए और अधिक काम करना पड़े।

और दूसरा प्रश्न. GitHub पर एक समस्या है. मुझे लगता है कि यह पहले ही बंद हो चुका है। मरम्मत के दौरान भगदड़ मच गई। और इसे हराने के लिए आपने एक अलग सभा बनाई. मुद्दों में यह सही है. और एक थ्रेड में वेरिएबल वातावरण करने का विकल्प है। और इसीलिए यह बहुत धीमी गति से काम करता है। और हमें इस समस्या का सामना करना पड़ा, और इसे अभी तक ठीक नहीं किया गया है।

समस्या यह है कि जब हम उच्च संगामिति के साथ आते हैं तो किसी कारण से स्टोरेज (सीईपीएच) कनेक्शन को रीसेट कर देता है। इसके बारे में क्या किया जा सकता है? पुनः प्रयास तर्क इस तरह दिखता है. हम फ़ाइल को फिर से डाउनलोड करने का प्रयास कर रहे हैं। एक बार में, हमारे पास कई फ़ाइलें थीं जो डाउनलोड नहीं हुईं, हम उन सभी के लिए दूसरी फ़ाइल बनाएंगे जिन्होंने लॉग इन नहीं किया था। और जब तक प्रति पुनरावृत्ति कम से कम एक फ़ाइल लोड होती है, हम दोहराते हैं और दोहराते हैं और दोहराते हैं। हमने पुनः प्रयास के तर्क में सुधार किया - घातीय बैकऑफ़। लेकिन यह पूरी तरह से स्पष्ट नहीं है कि इस तथ्य का क्या किया जाए कि कनेक्शन केवल स्टोरेज सिस्टम की तरफ से टूट जाता है। यानी, जब हम एक स्ट्रीम पर अपलोड करते हैं, तो यह इन कनेक्शनों को नहीं तोड़ता है। हम यहां क्या सुधार कर सकते हैं? हमारे पास नेटवर्क थ्रॉटलिंग है, हम प्रत्येक कनेक्शन को उसके द्वारा भेजे जाने वाले बाइट्स की संख्या से सीमित कर सकते हैं। अन्यथा, मुझे नहीं पता कि इस तथ्य से कैसे निपटा जाए कि ऑब्जेक्ट स्टोरेज हमें समानांतर में इसे डाउनलोड करने या डाउनलोड करने की अनुमति नहीं देता है।

कोई एसएलए नहीं? क्या यह उनके लिए नहीं लिखा गया है कि वे किस प्रकार अपने आप को पीड़ा सहने देते हैं?

मुद्दा यह है कि जो लोग इस प्रश्न के साथ आते हैं उनके पास आमतौर पर अपनी तिजोरी होती है। यानी कोई भी Amazon या Google Cloud, या Yandex ऑब्जेक्ट स्टोरेज से नहीं आता है।

शायद सवाल अब आपके लिए नहीं है?

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

यह एक ऐसी चीज़ है जो मेल क्लाउड में होती है।

यदि आप एक पुनरुत्पादन बना सकते हैं...

इसे लगातार पुनरुत्पादित किया जाता है...

यदि कोई पुनरुत्पादन है, तो मुझे लगता है कि हम पुन: प्रयास रणनीतियों के साथ प्रयोग करेंगे और यह पता लगाएंगे कि पुन: प्रयास कैसे करें और समझें कि क्लाउड को हमसे क्या चाहिए। शायद यह हमारे लिए तीन कनेक्शन पर स्थिर रहेगा और कनेक्शन नहीं तोड़ेगा, फिर हम सावधानी से तीन तक पहुंचेंगे। क्योंकि अब हम कनेक्शन को बहुत जल्दी छोड़ देते हैं, यानी अगर हमने 16 थ्रेड्स के साथ एक रिकवरी लॉन्च की है, तो पहले पुनः प्रयास के बाद 8 थ्रेड्स, 4 थ्रेड्स, 2 थ्रेड्स और एक होगा। और फिर यह फ़ाइल को एक स्ट्रीम में खींच लेगा। यदि कुछ जादुई मूल्य हैं जैसे 7,5 धागे पंपिंग के लिए सर्वोत्तम हैं, तो हम उन पर ध्यान केन्द्रित करेंगे और अन्य 7,5 धागे बनाने का प्रयास करेंगे। यहाँ एक विचार है.

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

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

यानी हर बार जब हम वाल-जी लॉन्च करते हैं तो यह पूरा बैकअप बनाने की कोशिश करता है?

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

मोटे तौर पर कहें तो, यदि आप इसे हर बार शून्य के साथ चलाते हैं, तो क्या यह pg_basebackup की तरह व्यवहार करेगा?

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

Pg_basebackup को शाफ्ट के बिना चलाया जा सकता है।

हाँ, तब वे लगभग वैसा ही व्यवहार करेंगे। Pg_basebackup फ़ाइल सिस्टम में प्रतिलिपि बनाता है। वैसे, हमारे पास एक नई सुविधा है जिसका मैं उल्लेख करना भूल गया। अब हम pg_basebackup से फ़ाइल सिस्टम का बैकअप ले सकते हैं। मुझे नहीं पता कि इसकी आवश्यकता क्यों है, लेकिन यह मौजूद है।

उदाहरण के लिए, CephFS पर। हर कोई ऑब्जेक्ट स्टोरेज को कॉन्फ़िगर नहीं करना चाहता।

हाँ, शायद इसीलिए उन्होंने इस सुविधा के बारे में एक प्रश्न पूछा ताकि हम यह कर सकें। और हमने यह किया.

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

इस सूत्रीकरण में यह एक कठिन प्रश्न है। हाँ, हम समर्थन करते हैं, लेकिन यह कार्यक्षमता अभी तक किसी भी रिलीज़ में शामिल नहीं है। यानी, सभी प्री-रिलीज़ इसका समर्थन करते हैं, लेकिन रिलीज़ संस्करण इसका समर्थन नहीं करते हैं। यह कार्यक्षमता संस्करण 0.2 में जोड़ी गई थी। जैसे ही हम सभी ज्ञात बग्स को ठीक कर लेंगे, यह निश्चित रूप से जल्द ही जारी किया जाएगा। लेकिन अभी यह केवल प्री-रिलीज़ में ही किया जा सकता है। प्री-रिलीज़ में दो बग हैं। वाल-ई पुनर्प्राप्ति में समस्या, हमने इसे ठीक नहीं किया है। और नवीनतम प्री-रिलीज़ में डेल्टा-बैकअप के बारे में एक बग जोड़ा गया था। इसलिए, हम सभी को रिलीज़ संस्करणों का उपयोग करने की सलाह देते हैं। जैसे ही प्री-रिलीज़ में कोई और बग नहीं होगा, हम कह सकते हैं कि हम Google क्लाउड, S3-संगत चीज़ों और फ़ाइल स्टोरेज का समर्थन करते हैं।

नमस्ते, रिपोर्ट के लिए धन्यवाद. जैसा कि मैं इसे समझता हूं, वाल-जी बर्मेन की तरह किसी प्रकार की केंद्रीकृत प्रणाली नहीं है? क्या आप इस दिशा में आगे बढ़ने की योजना बना रहे हैं?

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

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

PS एक नया संस्करण जारी किया गया है 0.2.15, जिसमें आप .walg.json कॉन्फ़िगरेशन फ़ाइल का उपयोग कर सकते हैं, जो डिफ़ॉल्ट रूप से पोस्टग्रेज होम निर्देशिका में स्थित है। आप बैश स्क्रिप्ट को छोड़ सकते हैं. उदाहरण .walg.json इस अंक में है https://github.com/wal-g/wal-g/issues/545

वीडियो:

स्रोत: www.habr.com