PostgreSQL बैकअप उपकरण। एंड्री सालनिकोव (डेटा एग्रेइट)

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

यह बात उपलब्ध PostgreSQL बैकअप टूल के बारे में है। तार्किक बैकअप, बाइनरी बैकअप, बिल्ट-इन बैकअप उपकरण और तीसरे पक्ष के उपकरण। वृद्धिशील बैकअप की जरूरत है जब वे वास्तव में मदद कर सकते हैं। आइए देखें कि कब और कौन सा उपकरण उपयोग करने के लिए अधिक उपयुक्त है। बैकअप प्रक्रिया को स्वचालित करने और बैकअप की अखंडता को सत्यापित करने का सबसे अच्छा तरीका क्या है? Pg_dump , pg_basebackup , barman , wal-e , wal-g , pgbackrest , BART और pg_probackup जैसे टूल पर करीब से नज़र डालें ।

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

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

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

PostgreSQL दुनिया में बैकअप बनाने के लिए उपकरणों की श्रेणी क्या है? यह अंतर्निहित pg_dump, pg_dumpall या pg_restore पुनर्प्राप्ति उपकरण है। यह एकमात्र उपकरण है जो आपको तार्किक बैकअप करने की अनुमति देता है। यही है, यह डेटा डंप करने के लिए SQL में और डेटा को डंप करने के लिए एक छोटे बाइनरी फॉर्मेट में, आपको pg_dump कर सकता है। और यह PostgreSQL के साथ बॉक्स से बाहर आता है।
बैकअप बनाने के लिए अगला टूल (pg_basebackup), जो बॉक्स से बाहर भी जाता है और आगे इस टूल से शुरू होता है, और आगे वे सभी बाइनरी डेटाबेस बैकअप बनाने के लिए टूल होंगे। Pg_basebackup भी एक उपकरण है जो बॉक्स से बाहर आता है, जो हमें पोस्टग्रेसीएल रिपॉजिटरी को अपलोड करने और डेटाबेस की एक बाइनरी कॉपी लेने, एक सतत डेटाबेस को शूट करने की अनुमति देता है और, यदि हम समय में संग्रह करने में सक्षम होना चाहते हैं, तो हम इसे डंप करने के लिए PostgreSQL को कॉन्फ़िगर कर सकते हैं। किसी तरह की डिस्क पर। ये मूल उपकरण हैं। वे अच्छे हैं, वे करते हैं, वे 5 पर अपनी कार्यक्षमता का प्रदर्शन करते हैं, लेकिन वे प्रबंधन और किसी तरह के द्रव्यमान के मामले में असुविधाजनक हैं। जब आपके पास 20 डेटाबेस होंगे, तो आपको इसकी स्क्रिप्टिंग स्वयं करनी होगी।
अगले दो उपकरण विशिष्ट हैं, शुद्ध क्लाउड उपकरण - वाल-ई और वाल-जी। वही लोग उन्हें विकसित कर रहे हैं, लेकिन वाल-ई विकास खत्म हो गया था, और वे वाल-जी पर स्विच कर गए। ये उपकरण मुख्य रूप से AWS के लिए और S3 में स्टोरेज के लिए तैयार हैं। Wal-e अभी भी Google क्लाउड के साथ, एज़्योर के साथ और डिस्क सिस्टम के साथ काम करने में सक्षम है, आप बस किसी प्रकार की रिमोट ड्राइव निर्दिष्ट कर सकते हैं। Wal-g केवल AWS के साथ काम करता है, केवल S3 के साथ। खैर, या S3 के साथ किसी अन्य समान इंटरफ़ेस। हम उनका उपयोग करते हैं, अच्छी चीजें। मैं प्रत्येक उपकरण को विस्तार से बताऊंगा।

और उपकरणों के अगले बंडल पर, ये ऐसे उपकरण हैं जो pg_basebackup पर भरोसा करते हैं या इसे सीधे उपयोग करते हैं, या किसी तरह इसकी कार्यक्षमता को लागू करते हैं। वे सभी डेवलपर्स द्वारा लिखे गए हैं जो मुख्य PostgreSQL के लिए प्रतिबद्ध हैं और उनके स्वयं के कांटे वाणिज्यिक हैं, जो उनके प्रभाव के सर्कल में बढ़ावा देते हैं।
सबसे लोकप्रिय बारमैन उपकरण, जिसका हम देश में काफी व्यापक रूप से उपयोग करते हैं। यह अनिवार्य रूप से pg_basebackup के आसपास पायथन आवरण है। यह ssh प्रोटोकॉल पर भी काम कर सकता है। एक बहुत ही दिलचस्प और बहुत आशाजनक pgbackrest उपकरण। PostgreSQL विकास में शामिल है और सक्रिय रूप से इसके लिए प्रतिबद्ध है। यह मूल रूप से पायथन में लिखा गया था। अब जिस संस्करण का उपयोग किया जाता है - यह तेजी लाने के लिए सी में लिखा गया है और बैकअप के समानांतर हटाने की संभावना है।
Pg_probackup PostgreSQL व्यावसायिक में हमारे रूसी सहयोगियों से एक उपयोगिता है जो आपको वृद्धिशील बैकअप बनाने की अनुमति देती है, जो आकार में काफी छोटे हैं।
और लेटेस्ट यूटिलिटी EnterpriseDB से बैकअप और रिकवरी टूल (BART) है। वह हमारे साथ बहुत लोकप्रिय नहीं है। यह मुख्य रूप से CentOS और Red Hat के लिए है। उबंटू के लिए, उसके साथ, मेरी राय में, कठिन। और हमारे साथ BART की कम लोकप्रियता के कारण, यह (BART) प्रतिष्ठानों में लगभग कहीं भी नहीं पाया जाता है।

मैं इन उपकरणों को कुछ चीजों में तोड़ने की कोशिश करूंगा जो महत्वपूर्ण हैं।

• सबसे पहले, यह हमारे लिए महत्वपूर्ण है कि हम इसे कैसे स्टोर करेंगे, किस ड्राइव पर और किन सेवाओं पर। और विशेषताओं की एक सूची है जो हम गुजरेंगे।

  
  

• निम्नलिखित डेटा पृथक्करण, यहाँ मैं क्या कर सकता / सकती हूँ, जब हम किसी बैकअप को हटाते हैं या किसी बैकअप को पुनर्स्थापित करते हैं, तो पूरे डेटाबेस सर्वर (सर्वर) से कुछ टुकड़ा काटने के लिए और इसके साथ एक अभिन्न, अभिन्न डेटाबेस के रूप में काम करते हैं।

  
  

• वे डेटाबेस के विभिन्न संस्करणों का कितना समर्थन करते हैं।

  
  

• समांतरता के संदर्भ में उनके पास कौन से ऑपरेटिंग मोड हैं, कुछ प्रकार के स्वचालन और पसंद के संदर्भ में।

  
  

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

  
  

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

  
  

  और अब, आइए इन छह बड़े बिंदुओं पर अधिक विस्तार से देखें। और मैं वहां निशान लगाऊंगा कि कौन सा साधन हमें देगा।

  
  

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

• डेटा की एक तार्किक प्रति हमें केवल pg_dump, pg_dumpall द्वारा प्रदान की जाती है। उनके बीच अंतर यह है कि pg_dumpall पूरे डेटाबेस इंस्टेंस (सर्वर) को संसाधित करता है, pg_dump में आप इंस्टेंस पर एक विशिष्ट डेटाबेस निर्दिष्ट कर सकते हैं और इसके साथ काम कर सकते हैं।
• बाइनरी प्रतियां सभी बाकी हैं।
• भंडारण के दौरान एक महत्वपूर्ण कारक यह है कि यदि हम डिस्क संसाधनों द्वारा किसी तरह से सीमित हैं, तो अक्सर स्थिति उत्पन्न होती है जब हम डेटाबेस को विभिन्न तालिका स्थानों में विभाजित करते हैं। यह लोहे के सर्वर के लिए भी सही है, क्योंकि आप RAID से पीड़ित नहीं होना चाहते हैं। यह बादलों के लिए सच है, क्योंकि क्योंकि एक निश्चित सीमा है, खासकर जब आप NVME डिस्क के साथ एक कार लेते हैं और कितने जुड़े हुए हैं, तो कई जुड़े हुए हैं। AWS के उदाहरणों का विस्तार होता है, लेकिन EBS ड्राइव्स के साथ। और डेटा को पुनर्स्थापित करते समय, हमारे लिए यह महत्वपूर्ण होगा कि हम इन टेबल स्पेस को फिर से वितरित कर सकें, उन्हें नए रास्तों और नए डिस्क के साथ असाइन करें। और अब यह अच्छी संपत्ति वाल-ई पर मौजूद है। वाल-जी में वे अभी भी नहीं जानते कि इसके साथ कैसे काम किया जाए। Pg_probackup इसके साथ काम कर सकता है। बर्मन, बेसबैकअप, पगबैकेस्ट। यह बात अक्सर महत्वपूर्ण होती है, खासकर जब आपके पास 8-10 टीबी डेटाबेस हो। हमारे उत्पादन ग्राहकों के बीच, इनमें से लगभग सभी डेटाबेस टेबल स्पेस में ढह गए हैं।

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

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

यह बात अच्छी है, लेकिन हमने आगे बढ़ने का फैसला किया और वृद्धिशील बैकअप के साथ आए। वृद्धिशील बैकअप दो प्रकार के होते हैं।

पहला फ़ाइल स्तर पर है। यह केवल उस बैकअप में अंतर बैकअप से भिन्न होता है, अंतर बैकअप आपके डेटाबेस के एक पूर्ण बैकअप पर केंद्रित होता है, और एक पूर्ण बैकअप के संबंध में यह प्रतियां फाइलों और प्रतियों को अलग करती है। वृद्धिशील बैकअप विभेदक बैकअप पर ध्यान केंद्रित कर सकता है, केवल उन परिवर्तित फ़ाइलों की प्रतिलिपि बनाता है जो अंतर बैकअप की तुलना में बदल गए हैं। वृद्धिशील के लिए, आपको बैकअप की पूरी श्रृंखला की आवश्यकता होगी। यही है, मुख्य बैकअप -> 1 वृद्धिशील बैकअप (यह हमेशा अंतर होगा) -> फिर सभी वृद्धिशील बैकअप। डिफरेंशियल बैकअप हमेशा एक पूर्ण बैकअप डेटाबेस पर केंद्रित होता है। वृद्धिशील अन्य प्रकार के बैकअप पर ध्यान केंद्रित कर सकता है।
Pg_probackup और BART ब्लॉक द्वारा वृद्धिशील बैकअप बनाने का तरीका गया। क्योंकि हम पूरी फाइल को नहीं, बल्कि डेटा ब्लॉक को बदल सकते हैं। और ये उपयोगिताओं वाल फाइलों के माध्यम से चलती हैं और उन ब्लॉकों का चयन करती हैं जो आप से बदल गए हैं। ये बैकअप ब्लॉक बैकअप के लिए कॉपी किए जाते हैं। इस तरह के वृद्धिशील बैकअप के साथ पुनर्प्राप्त करने के लिए, आपको डेटाबेस की पूरी प्रतिलिपि की भी आवश्यकता होगी और इसके अलावा आपको अभी भी इन वृद्धिशील टुकड़ों को बचाने की आवश्यकता है जो कि वॉल से टाइप किए गए हैं। यह उपयोगिता की कुछ सीमाओं को लागू करता है, क्योंकि उन्हें वाल फाइलों के माध्यम से चलना चाहिए। PostgreSQL Professional में डेटाबेस की फ़ाइल संरचना पर एक परत भी है। इसलिए, वे बहुत जल्दी इन ब्लॉकों की तलाश में हैं। इस तरह के वृद्धिशील बैकअप बहुत छोटे हैं। यदि आपके पास एक छोटा सा% डेटाबेस परिवर्तन है और इस तथ्य के कारण कि वाल फ़ाइल में काफी तकनीकी जानकारी लिखी गई है, तो ये उपयोगिताओं 1 वाल के लिए दसियों किलोवाट डेटा का बैकअप लेती हैं।

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

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

डेटाबेस के कई संस्करणों के साथ काम कैसे किया जाता है? यहाँ भी, सब कुछ काफी दिलचस्प है। Pg_dump बहुत अच्छा है कि हम डेटाबेस के किस संस्करण से पुनर्स्थापित करने के लिए बंधे नहीं हैं। सादा पाठ मोड है, और यह सिर्फ शुद्ध एसक्यूएल है, जो डेटाबेस की संपूर्ण संरचना, सभी डेटा का वर्णन करता है। सिद्धांत रूप में, आप इस डंप में कुछ संपादन के साथ Oracle में, MySQL में, MSSQL में, MSSQL में, जहाँ भी चाहें, उससे उबर सकते हैं। PostgreSQL के प्रमुख संस्करणों के बीच, ये डंप भी उपयोग करने में काफी आसान हैं।
मल्टी-वर्जनिंग, मुझे इससे क्या मतलब है? यह है कि उपयोगिता डेटाबेस के विभिन्न संस्करणों को संसाधित कर सकती है और PostgreSQL 9.6, 10, 11. के साथ एक साथ काम कर सकती है। बिल्ट-इन छोड़कर pg_dump और pg_basebackup से सब कुछ, क्योंकि वे उस विशिष्ट संस्करण से बंधे हुए हैं जो इसके साथ आते हैं। बाकी इन उपयोगिताओं पर केंद्रित है। उन्हें संकेत दिया जा सकता है कि विभिन्न संस्करणों के pg_basebackup, pg_dump कहाँ स्थित हैं। वे क्रमशः PostgreSQL के संस्करण के साथ बैकअप हटाने के लिए नवीनतम उपयोगिता चुनते हैं।
Pg_dump को छोड़कर सभी उपयोगिताओं प्रतिकृतियां और स्टैंडबाय सर्वर बनाने के लिए उपयुक्त हैं, क्योंकि ये तार्किक बैकअप हैं। इन उपयोगिताओं में से किसी का उपयोग करके, आप सर्वर को पुनर्स्थापित कर सकते हैं और इस सर्वर की प्रतिकृति के रूप में काम करने के लिए विज़ार्ड से कनेक्ट कर सकते हैं।

बैकअप को सामान्य रूप से कैसे हटाया जा सकता है, बैकअप हटाने के लिए कौन से मोड मौजूद हैं। आप बस मानक ओएस उपकरण का उपयोग करके फ़ाइलों की प्रतिलिपि बना सकते हैं: ssh (rsync, scp) प्रोटोकॉल के माध्यम से और संभवतः कुछ अन्य उपयोगिताओं जो हैं। ऐसा अवसर क्यों है, क्योंकि वे आपको नकल को समानांतर करने की अनुमति देते हैं। Pgbackrest केवल इस तरह से काम करता है, barman यह उस तरह से काम कर सकता है, और यह PostgreSQL प्रोटोकॉल का उपयोग करके काम कर सकता है।
PostgreSQL प्रोटोकॉल - जब बैकअप उपयोगिता PostgreSQL से जुड़ती है और सभी फाइलों और संग्रह लॉग को खींचती है जो प्रतिकृति प्रोटोकॉल का उपयोग करके बैकअप प्रक्रिया के दौरान उत्पन्न होती है। बाकी सब और बरमान कर सकते हैं।
मूल रूप से, सब कुछ एक प्रतिकृति से बैकअप कर सकते हैं, यह PostgreSQL के संस्करण पर निर्भर करता है। PostgreSQL 10 और 11 के साथ, हम एक प्रतिकृति से बैकअप निकाल सकते हैं। लेकिन मैं इसकी सिफारिश नहीं करता, सामान्य तौर पर, हमारी कंपनी में से कोई भी इसकी सिफारिश नहीं करेगा। क्योंकि ऐसी स्थितियां हैं जब वे निगरानी से चूक गए, उन्होंने एक महीने के लिए प्रतिकृति से बैकअप लिया, जो मास्टर सर्वर से गिर गया और प्रासंगिक नहीं है। यही है, किसी भी मामले में बैकअप हमेशा मास्टर सर्वर से हटा दिया जाना चाहिए। केवल इस मामले में आप सुनिश्चित होंगे कि आपके पास बैकअप अप-टू-डेट डेटाबेस है।
मल्टीप्रेडिंग बैकअप - हर कोई ऐसा कर सकता है, क्योंकि सब कुछ अलग-अलग कारणों से होता है, किसी को ssh प्रोटोकॉल के माध्यम से, किसी ने डेटाबेस कॉपी स्तर पर लागू किया। Pg_basebackup और BART को छोड़कर, क्योंकि BART ऑपरेशन केवल pg_basebackup पर है जब बैकअप निकाला जाता है और यह दुर्भाग्य से, एकल-थ्रेडेड है और बहु-थ्रेडेड नहीं होगा।

मल्टीथ्रेडिंग का एक उदाहरण। मैं 8 टीबी डेटाबेस बहाल कर रहा था। जब आप बैकअप निकालने के लिए एक सिस्टम चुनने पर ध्यान केंद्रित करते हैं, तो पता है कि वाल-ई को पायथन में लिखा गया है, वाल-जी को गोलंग में लिखा गया है। मुझे 8 टीबी बेस बहाल करना था। वाल-ई पायथन सीमा में भाग गया और मुझे 600 एमबीपीएस की गति से एडब्ल्यूएस के साथ खींच लिया। जब मैंने वाल-जी पर स्विच किया, तो उसके पास एक स्थिति थी कि वह वाल-ई बैकअप के साथ काम नहीं कर सकता था, लेकिन वह वॉल फाइलों को खींच सकता था। इसलिए, यहां यह मध्य चित्र डेटाबेस की बहाली है। फिर लुढ़का हुआ चलना, जो एस 3 में वहां पड़ा था और एक निश्चित समय में बहाल हो गया था। Wal-e Python की सीमा में चला गया और Python में संक्षिप्तता, यह इतनी सशर्त है। S3 इंटरफ़ेस में एक वाल-जी चलता था, अर्थात, S3 कितनी तेजी से हर पल दे सकता था, इसलिए जल्दी से इसे ले लिया। औसतन, यह 2 जीबी / एस था, जो काफी अच्छा है। यही है, वाल-ई के साथ, डेटाबेस के एक घंटे के परिवर्तन को रोलिंग बैकअप के 45 मिनट में प्राप्त किया गया था। वाल-जी के साथ, यह पता चला कि उन्होंने लगभग 5 मिनट के लिए डेटाबेस में कहीं एक घंटे लुढ़का दिया।

ऑपरेटिंग मोड, बैकअप सिस्टम में यहां क्या दिलचस्प है।

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

सेवाक्षमता, बैकअप सिस्टम के लिए यहाँ क्या दिलचस्प है?

• CLI — , , , , . , CLI, , , . , , .
• barman, pgbackrest BART, . , 20-30 , , , , backup- . , , .
• – , , backup-, , backup-. , - . . .
• – backup-, , - . , , . , , , , wal , , . wal-e, wal-g, , backup - . 7 backup .

backup. , backup, backup , , . , . , . . stage . , , backup . CLI , backup .

, , . , backup . , . , . , . . checksum PostgreSQL. , checksum PostgreSQL. checksum, .

pgbackrest pg_probackup backup , checksum. checksum.

, backup, checksum , , checksum . .

:

• https://www.postgresql.org/docs/10/static/app-pgdump.html
• https://www.postgresql.org/docs/10/static/app-pgbasebackup.html
• https://www.2ndquadrant.com/en/resources/barman/
• https://github.com/wal-e/wal-e
• https://github.com/wal-g/wal-g
• https://pgbackrest.org/
• https://www.enterprisedb.com/products/edb-postgres-platform/edb-backup-and-recovery-tool
• https://postgrespro.ru/products/extensions/pg_probackup

. , . , .

: , backup , , , . , , backup. , , - , , , , , , . - ?

: , , . . . - , , backup , , , . , . , , , , , , / . , , . , . , . , .

: , , ? .

: . 4 . . . backup. . , .

: ?

: . . wal-e, wal-g, pgbackrest. borman, pg_dump, basebackup. , , . .

: , - PostgreSQL, , , postgis - -?

: , backup , . checksum , PostgreSQL checksum, , . postgis, - . Pg_dump , , , SQL . SQL . . , , . dump, .

: , . , - ?

: . dump , . , – , , - , , . , . , - , .

: , , , bloat ?

: .

: — , - . , Symantec, Veritas Backup Exec . PostgreSQL?

: , , . PostgreSQL , pg_start_backup. , . .

: , - Symantec, Veritas Backup Exec .

: .

: , , . checksum - , , - ?

: — . stage , . stage . . . , -, . . .

: , WAL , S3. wal-e, wal-g - awscli . ?

( ): wal-g. wal-g. 40 wal-g . . , . , prefetch, wal , . , — , wal. wal , page cache , , wal, , . , .

: . , PostgreSQL — -> /dev/null, , . , . smoke . amcheck , . , , , .

: 10 . . . . wal — . ?

: . . . , .

: , pg_dump, . ?

: - . , .

: , , - ?

: pg_dump , .

: pg_dump, , , , , .

: , -, .

: , .

: , - .

: . . . . , , . . Pg_dump , - , exit_code . , , . , .

PS №1 pg_dump, pg_basebackup.

पुनश्च संख्या 2 त्रुटियां, लेख के तहत सुधार, धुरी तालिका में जोड़ पुल अनुरोध के माध्यम से किए जा सकते हैं

PS # 3 Wal-g प्रलेखन के साथ मदद करने के लिए स्वयंसेवकों का स्वागत करता है।

पीएस नंबर 4 आरपीएम का उपयोग करके वॉल-जी स्थापित करने के लिए आप मेरे भंडार का उपयोग कर सकते हैं: जीथूब , फेडोरा सीओपीआर ।

PS नंबर 5 S3 बनाने और स्टोर करने में पूर्ण बैकअप और वृद्धिशील बैकअप कैसे करें, और केवल पूर्ण बैकअप को टेप करने के लिए कैसे बचाएं? अगर आपके पास विचार हैं, तो मुझे टिप्पणियों में या पीएम में बताएं।

सर्वेक्षण: आप किस बैकअप टूल का उपयोग करते हैं?

PS नंबर 6 टेलीग्राम चैनल PostgreSQL: https://t.me/pgsql