हमने बैकअप को ओवरक्लॉक किया। यांडेक्स व्याख्यान

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


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

सिद्धांत रूप में PostgreSQL में बैकअप के बारे में बात करते हैं। डेटा ट्रांसफर करने के लिए मानक उपयोगिता - pg_dump - को कंसोल यूटिलिटी के रूप में परिभाषित किया गया है जो आपके डेटा के तार्किक प्रतिनिधित्व के साथ एक फ़ाइल बनाता है।

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


सबसे पहले, pg_dump के बारे में आपको यह जानना होगा कि यह एक डेवलपर टूल है।

यह एक डेटाबेस रखरखाव उपकरण नहीं है। pg_dump को अत्यधिक लोड किए गए डेटाबेस के साथ काम करने के लिए डिज़ाइन नहीं किया गया है।


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

_{^{स्लाइड से लिंक करें}}

बैकअप हटाने के अंतिम समय और एक प्रमुख रिकॉर्ड की उपस्थिति के बाद, आप अपने डेटाबेस के जीवन काल में वांछित बिंदु पर पुनर्प्राप्त कर सकते हैं।

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

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

उसके कई फायदे हैं। मुख्य प्लस एक बहुत ही सामान्य उपयोगिता है, इसमें एक विशाल समुदाय है, ढेर ओवरफ्लो पर भारी संख्या में प्रश्न हैं।



आपको बस एक बैकअप सर्वर लेने की जरूरत है, और वहां अपने सभी PostgreSQL का बैकअप लें। यह बहुत सुविधाजनक है - जब तक कि एक बैकअप सर्वर आपके लिए पर्याप्त है।

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

एक बहुत सरल बैकअप हटाने उपयोगिता है जिसे वाल-ई कहा जाता है।


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

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


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


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

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

_{^{स्लाइड से लिंक करें}}

इसकी मुख्य विशेषता यह है कि इसे गो में फिर से लिखा गया है, इसकी लगभग कोई बाहरी निर्भरता नहीं है, यदि आप बाहरी एन्क्रिप्शन का उपयोग नहीं करते हैं, और यह बहुत अधिक उत्पादक है।

_{^{स्लाइड से लिंक करें}}

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

_{^{स्लाइड से लिंक करें}}

वाल-जी में काफी स्थिर बैंडविड्थ है। साइटस डेटा के परीक्षण में, उन्होंने दिखाया कि वह लगभग 800 एमबी / सेकेंड के "शाफ्ट" भेजता है।

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

_{^{स्लाइड से लिंक करें}}

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



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


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

सिद्धांत रूप में हमें डेटाबेस की डेल्टा प्रतियों की आवश्यकता क्यों है? सिद्धांत रूप में, आपके पास एक वाल है, और इसलिए आप कहीं भी रोल कर सकते हैं।

व्यस्त सर्वर पर, अतीत के पांच भौतिक सेकंड के वाल को खेलने से वर्तमान के चार भौतिक सेकंड लग सकते हैं। यदि आपको चार दिनों में वाल रोल करने के लिए कहा जाता है, तो इसका मतलब है कि यह संभव है कि जो व्यक्ति ऐसा करने के लिए कहता है, उसे तीन दिन इंतजार करना चाहिए। हमेशा स्वीकार्य स्थिति नहीं।

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


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


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




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


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

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



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



बैकअप की एक सूची है।


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


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

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


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


यह सभी पर्यावरण चर द्वारा निर्धारित किया गया है।


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

हमारी मुख्य विशेषता वास्तव में प्रौद्योगिकी के बारे में नहीं है।

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

लगभग एक साल पहले, झेन्या ने वाल-ई बग को तय किया, और हमने इसे छह महीने के लिए भेज दिया ( गीथहेड - लगभग एड। लिंक ।)। अक्सर खुले स्रोत के समाधान में अक्सर इस तथ्य के साथ एक समस्या होती है कि वे बहुत अच्छी तरह से बनाए नहीं रखते हैं।


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

समुदाय से मानक अनुरोध सरल है - "चलो इसे सबसे करें।"

अधिक क्रिप्टोग्राफी, अधिक प्लेटफ़ॉर्म। शायद न केवल PostgreSQL, लेकिन MySQL अभी भी बैकअप या कुछ और? मैं कुछ और चीजें देखता हूं।


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

और जब क्रोन दूसरे डेल्टा बैकअप के साथ आता है, तो हम पूरे डेटाबेस को स्कैन नहीं कर सकते हैं, डिस्क रीडिंग के उस दांत को दर्ज कर सकते हैं और बस यह जान सकते हैं कि हमें कौन से पेजों को क्लाउड पर ड्रैग करना है।

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


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


PTRACK के मामले में, हमें डेल्टा फ़ाइल में परिवर्तन प्राप्त होते हैं, जो पिछले प्राप्त डेल्टा से शुरू होता है। हमारे पास बैकअप की शुरुआत से पहले, परिवर्तनों की शुरुआत से पहले सटीक डेल्टा समय नहीं है। यह PTRACK की मुख्य समस्या नहीं है, सामान्य तौर पर, यह अच्छी तरह से काम करता है, लेकिन अभी तक इसे स्वीकार करना मुश्किल है।


PTRACK LATEST_FULL मोड में डेल्टा हटाने की अनुमति नहीं देता है, क्योंकि यह इस नक्शे के पिछले निष्कासन से परिवर्तित ब्लॉकों का एक नक्शा संग्रहीत करता है। ओरेकल के पास एक दिलचस्प तकनीक है, 8 पिछले कार्ड हैं जो वे सिर्फ मामले में बचाते हैं। हो सकता है कि हम भी कुछ ऐसा कर सकें, लेकिन अभी तक हम इस दिशा में काम नहीं कर रहे हैं।

_{^{स्लाइड से लिंक करें}}

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

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

मुझे बेसबैकअप में एक बॉक्स में क्या देखना पसंद होगा? हम, शायद, बादलों को देखना चाहते हैं। और डेल्टा प्रतियां।


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