PostgreSQL में डेटा कैसे न खोएं

PostgreSQL डेटा बैकअप के लिए कई विकल्प प्रदान करता है। उन सभी को पहले से ही एक से अधिक बार बताया गया है, जिसमें हबर भी शामिल है। लेकिन मूल रूप से यह विधियों की तकनीकी विशेषताओं के बारे में बताता है। मैं आपको सामान्य बैकअप रणनीति के बारे में बताने की कोशिश करना चाहता हूं, एक प्रभावी प्रणाली में सभी तरीकों को संयोजित करना जो आपको सभी डेटा को बचाने और महत्वपूर्ण परिस्थितियों में मृत तंत्रिका कोशिकाओं की संख्या को कम करने में मदद करेगा।
इनपुट: PostgreSQL 9.2 सर्वर, आधार आकार> 100Gb।

बैकअप विकल्प

मैनुअल से निम्नानुसार, डेटा बैकअप के 3 तरीके हैं:

• स्ट्रीमिंग प्रतिकृति
• डेटाबेस फ़ाइलों की प्रतिलिपि बनाएँ
• SQL डंप

उन सभी की अपनी विशेषताएं हैं, इसलिए हम इन सभी तरीकों का उपयोग करते हैं।

स्ट्रीमिंग प्रतिकृति

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

डेटाबेस फ़ाइलों की प्रतिलिपि बनाएँ

हमने सर्वर क्रैश का पता लगा लिया है, अब हम मानव कारक से निपटेंगे, जब किसी कारण से तालिकाओं में डेटा, या टेबल स्वयं या स्नानागार का डेटाबेस हटा दिया जाता है। इस मामले में, आपको बैकअप से डेटा को पुनर्स्थापित करना होगा। एप्लिकेशन का परीक्षण करने के लिए डेटाबेस की एक और प्रति की आवश्यकता हो सकती है। ऐसी प्रतिलिपि दो तरीकों से बनाई जा सकती है - डेटाबेस को डंप करें या संपूर्ण डेटा निर्देशिका को कॉपी करें। लंबे समय तक हमने पहला विकल्प इस्तेमाल किया - डेटाबेस डंप एक फाइल के लिए। लेकिन डंप में एक बड़ा माइनस है - प्रक्रिया तालिकाओं को अवरुद्ध करती है, और अन्य प्रक्रियाएं अब उनके साथ काम नहीं कर सकती हैं ( UPD : pg_dump तालिकाओं को ब्लॉक नहीं करता है। हालांकि, यह डेटाबेस पर एक बड़ा भार बनाता है)। बड़े डेटाबेस के लिए, यह महत्वपूर्ण है।
अब, डेटाबेस का बैकअप लेने के लिए, हम pg_basebackup उपयोगिता का उपयोग करते हैं, जो अनिवार्य रूप से सभी डेटाबेस फ़ाइलों को एक बड़े संग्रह में कॉपी करता है।
हम 4 साप्ताहिक प्रतियां और 6 मासिक रखते हैं। प्रतियां समान GlusterFS भंडारण पर संग्रहीत की जाती हैं। हम इस तरह से प्रतियां बनाते हैं कि वे आत्मनिर्भर हैं, अर्थात्, वे अतिरिक्त वाल फाइलों को डाउनलोड करने की आवश्यकता के बिना, तैनाती के तुरंत बाद काम करते हैं। इसलिए, हम आसानी से एक आधार तैनात कर सकते हैं, उदाहरण के लिए, तीन महीने पहले।
यह उल्लेखनीय है कि pg_basebackup उपयोगिता को गुलाम सर्वर पर चलाया जा सकता है (कुछ शर्तों के तहत), इसलिए बैकअप बनाने से विज़ार्ड को लोड नहीं होता है।
गुलाम पर काम करने के लिए pg_basebackup के लिए, आपको WAL फ़ाइलों को सहेजने में सक्षम करने की आवश्यकता है, ऐसा करने के लिए, postgresql.conf में विकल्प सेट करें:

wal_level = hot_standby wal_keep_segments = 1000 

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

 /usr/bin/pg_basebackup -U postgres -D /tmp/pg_backup -Ft -z -Xf 

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

हम इस स्क्रिप्ट के साथ शनिवार को मुकुट पर बैकअप करते हैं:

 #!/bin/bash mkdir /tmp/pg_backup /usr/bin/pg_basebackup -U postgres -D /tmp/pg_backup -Ft -z -Xf WEEK=$(date +"%V") MONTH=$(date +"%b") let "INDEX = WEEK % 5" test -e /collector/db-backup/base.${INDEX}.tar.gz && rm /collector/db-backup/base.${INDEX}.tar.gz cp /tmp/pg_backup/base.tar.gz /collector/db-backup/base.${INDEX}.tar.gz test -e /collector/db-backup/base.${MONTH}.tar.gz && rm /collector/db-backup/base.${MONTH}.tar.gz ln /collector/db-backup/base.${INDEX}.tar.gz /collector/db-backup/base.${MONTH}.tar.gz test -e /collector/db-backup/base.last.tar.gz && rm /collector/db-backup/base.last.tar.gz ln /collector/db-backup/base.${INDEX}.tar.gz /collector/db-backup/base.last.tar.gz rm -r /tmp/pg_backup 

इस प्रकार, 3 प्रत्ययों के साथ एक फ़ाइल बनाई जाती है: सप्ताह की संख्या के साथ, महीने का नाम और अंतिम सेवा के साथ।
डेटाबेस को प्रतिलिपि से पुनर्स्थापित करने के लिए, आपको डेटा निर्देशिका से PostgreSQL को रोकने, पुराने डेटा को हटाने (या स्थानांतरित) करने की आवश्यकता है, वहां संग्रह सामग्री को अनपैक करें और सर्वर शुरू करें। एक दिलचस्प बात है। चूँकि हमने दास पर pg_basebackup किया था, रिकवरी.कॉन्फ़ फ़ाइल को डेटा के साथ अनपैक किया जाएगा। इसलिए, यदि हम डेटा को अंतिम संभव स्थिति में पुनर्स्थापित करना चाहते हैं, तो इस फ़ाइल को छोड़ दिया जाना चाहिए, इस मामले में, सर्वर शुरू होने के बाद, Postgres पुनर्प्राप्ति में निर्दिष्ट स्थान से वाल फ़ाइलों को खींचना शुरू कर देगा ।conf। यदि हम अंतिम साप्ताहिक बैकअप लेते हैं, तो हमारे पास सभी आवश्यक वाल फाइलें होंगी (चूंकि हम उन्हें 8 दिनों के लिए संग्रहीत करते हैं), और हम डेटाबेस को अंतिम सामान्य स्थिति में पुनर्स्थापित कर सकते हैं।
यदि हमें बैकअप बनाते समय डेटा की आवश्यकता होती है, तो डेटाबेस को शुरू करने से पहले हमें Recovery.conf फ़ाइल को हटाना होगा।

हम परीक्षण प्रयोजनों के लिए बैकअप प्रतियों का भी उपयोग करते हैं, एक के लिए, एक बैकअप प्रतिलिपि बनाने की शुद्धता की भी जाँच की जाती है।
Base.last.tar.gz नाम का उपयोग हमारे द्वारा परीक्षण डेटाबेस में अंतिम प्रतिलिपि को पुनर्स्थापित करने के लिए किया जाता है। हमारे परीक्षण डेटाबेस को हर रात इस स्क्रिप्ट के साथ बहाल किया जाता है:

 #!/bin/bash /etc/init.d/postgresql stop rm -r /data/* tar -zxf /collector/db-backup/base.last.tar.gz -C /data/ rm /data/recovery.conf /etc/init.d/postgresql start 

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

SQL डंप

हम एक बड़े डेटाबेस का एक पूर्ण SQL डंप लंबे समय से नहीं कर रहे हैं, लेकिन हम उन टेबल को डंप कर रहे हैं जो बदल गए हैं, 1 टेबल - 1 फ़ाइल। यह आपको उन मामलों में बहुत जल्दी डेटा को पुनर्स्थापित करने की अनुमति देता है जहां केवल एक तालिका दूषित है - बैकअप से पूरे डेटाबेस को अनपैक करने की आवश्यकता नहीं है।
PostgreSQL हमें तालिकाओं में परिवर्तन की संख्या के बारे में आँकड़े प्रदान करता है, और हर रात हम देखते हैं कि कौन सी तालिकाएँ बदली गई हैं और उन्हें डंप किया गया है। हम आंकड़ों को कुछ इस तरह से देखते हैं:
select schemaname,relname,n_tup_ins+n_tup_upd+n_tup_del from pg_stat_user_tables ;
निचला रेखा: एसक्यूएल डंप छोटी त्रुटियों को ठीक करने में मदद करेगा। इस स्थिति में, डंप के समय डेटा प्रासंगिक होगा।

निष्कर्ष में

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