आपने जो लिखा उसके बारे में मैंने सोचा और यहां आपके लिए कुछ उपाय दिए गए हैं:
- यदि आपको बैकअप की आवश्यकता है जो वास्तव में किसी समय के अनुरूप होगा तो आपको pg_basebackup या pg_barman (आंतरिक रूप से pg_basebackup का उपयोग करता है) का उपयोग करना चाहिए - स्पष्टीकरण नीचे 1 लिंक में है। नवीनतम pg_basebackup 10 स्ट्रीम WAL लॉग करता है ताकि आप बैकअप के दौरान किए गए सभी परिवर्तनों का भी बैकअप लें। बेशक यह बैकअप केवल संपूर्ण PG उदाहरण लेता है। दूसरी ओर यह किसी भी टेबल को लॉक नहीं करता है। और अगर आप इसे रिमोट इंस्टेंस से करते हैं तो यह पीजी इंस्टेंस पर केवल छोटे सीपीयू लोड का कारण बनता है और डिस्क आईओ उतना बड़ा नहीं है जितना कुछ ग्रंथों का सुझाव है। मेरे अनुभवों के बारे में लिंक 4 देखें। बहाली काफी सरल है - लिंक 5 देखें।
- यदि आप pg_dump का उपयोग करते हैं तो आपको यह समझना चाहिए कि आपको इस बात की कोई गारंटी नहीं है कि आपका बैकअप वास्तव में समय के अनुरूप है - फिर से लिंक देखें। डेटाबेस के स्नैपशॉट का उपयोग करने की संभावना है (लिंक 2 और 3 देखें) लेकिन इसके साथ भी आप 100% स्थिरता पर भरोसा नहीं कर सकते। हमने अपने विश्लेषणात्मक डेटाबेस पर केवल pg_dump का उपयोग किया है जो प्रति दिन केवल 1x नया लोड करता है (कल उत्पादन डेटाबेस से विभाजन)। आप इसे समानांतर विकल्प के साथ गति दे सकते हैं (केवल निर्देशिका बैकअप प्रारूप के लिए काम करता है)। लेकिन पीजी इंस्टेंस पर बहुत अधिक भार है - उच्च CPU उपयोग, बहुत अधिक डिस्क IO। भले ही आप दूरस्थ रूप से pg_dump चलाते हैं - ऐसे में आप बैकअप फ़ाइलों को सहेजने के लिए केवल डिस्क IO सहेजते हैं। साथ ही pg_dump को टेबल पर रीड लॉक लगाने की आवश्यकता होती है ताकि यह या तो नए इंसर्ट या प्रतिकृति के साथ टकरा सके (जब प्रतिकृति पर लिया जाए)। लेकिन जब आपका डेटाबेस सैकड़ों जीबी तक पहुंच जाता है तो समानांतर डंप में भी घंटों लग सकते हैं और उस पल में आपको वैसे भी pg_basebackup पर स्विच करना होगा।
- pg_barman, pg_basebackup + का "आरामदायक संस्करण" है, यह आपको तब भी डेटा हानि को रोकने की अनुमति देता है जब आपका PG इंस्टेंस बहुत बुरी तरह से क्रैश हो जाता है। इसे काम पर सेट करने के लिए और अधिक बदलावों की आवश्यकता है लेकिन यह निश्चित रूप से इसके लायक है। आपको वाल लॉग संग्रह सेट करना होगा (लिंक 6 देखें) और यदि आप पीजी <10 हैं तो आपको "max_wal_senders" और "max_replication_slots" सेट करना होगा (जो आपको वैसे भी प्रतिकृति के लिए चाहिए) - सब कुछ पीजी-बर्मन मैनुअल में है हालांकि विवरण बिल्कुल महान नहीं है। pg_barman बैकअप के बीच भी WAL रिकॉर्ड को स्ट्रीम और स्टोर करेगा ताकि आप सुनिश्चित हो सकें कि बहुत खराब दुर्घटना के मामले में डेटा हानि लगभग कोई नहीं होगी। लेकिन इसे काम करने में कई घंटे लग सकते हैं क्योंकि विवरण बिल्कुल अच्छे नहीं हैं। pg-barman अपने आदेशों के साथ बैकअप और पुनर्स्थापना दोनों करता है।
आपका डेटाबेस 5GB बड़ा है इसलिए कोई भी बैकअप तरीका जल्दी होगा। लेकिन आपको यह तय करना होगा कि आपको पॉइंट इन टाइम रिकवरी और लगभग शून्य डेटा हानि की आवश्यकता है या नहीं - इसलिए यदि आप पीजी-बर्मन की स्थापना के लिए समय का निवेश करेंगे या नहीं।
कड़ियाँ:
- PostgreSQL, बैकअप और सब कुछ आपको जानने की जरूरत है
- कागज के लिए समीक्षा:14-Serializable PostgreSQL में स्नैपशॉट अलगाव - स्नैपशॉट के बारे में
- डेटाबेस का समानांतर डंपिंग - उदाहरण स्नैपशॉट का उपयोग कैसे करें
- pg_basebackup अनुभव
- pg_basebackup - टार बैकअप बहाल करें
- स्क्रिप्ट का उपयोग करके WAL लॉग को संग्रहित करना
