आपदा वसूली के लिए PostgreSQL प्रतिकृति

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

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

उच्च उपलब्धता

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

स्ट्रीमिंग प्रतिकृति की स्थापना के लिए विशिष्टताओं के लिए, सेवेनाइन्स के पास एक विस्तृत डीप डाइव उपलब्ध है। आधिकारिक PostgreSQL स्ट्रीमिंग प्रतिकृति दस्तावेज़ीकरण में स्ट्रीमिंग प्रतिकृति प्रोटोकॉल और यह सब कैसे काम करता है, इस बारे में विस्तृत जानकारी है।

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

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

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

ध्यान दें:जब एक स्ट्रीमिंग प्रतिकृति में विफल हो जाता है, तो यह पिछले मास्टर द्वारा छोड़े गए स्थान को उठाएगा, इसलिए यह डेटाबेस को ऑनलाइन रखने में मदद करता है, लेकिन गलती से खोए हुए डेटा को पुनर्प्राप्त नहीं करता है।

प्वाइंट इन टाइम रिकवरी

एक अन्य डिजास्टर रिकवरी विकल्प प्वाइंट इन टाइम रिकवरी (PITR) है। PITR के साथ, डेटाबेस की एक प्रति को हम किसी भी समय वापस लाया जा सकता है, जब तक कि हमारे पास उस समय से पहले का आधार बैकअप हो, और उस समय तक सभी WAL खंडों की आवश्यकता हो।

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

पॉइंट इन टाइम रिकवरी डेटाबेस के आवधिक स्नैपशॉट बनाकर काम करता है, आमतौर पर प्रोग्राम pg_basebackup का उपयोग करके, और मास्टर द्वारा उत्पन्न सभी WAL फ़ाइलों की संग्रहीत प्रतियों को रखते हुए

प्वाइंट इन टाइम रिकवरी सेटअप

सेटअप के लिए मास्टर पर सेट किए गए कुछ कॉन्फ़िगरेशन विकल्पों की आवश्यकता होती है, जिनमें से कुछ वर्तमान नवीनतम संस्करण, PostgreSQL 11 पर डिफ़ॉल्ट मानों के साथ जाने के लिए अच्छे हैं। इस उदाहरण में, हम rsync का उपयोग करके सीधे अपने दूरस्थ PITR होस्ट पर 16MB फ़ाइल की प्रतिलिपि बनाएँगे , और उन्हें क्रॉन जॉब के साथ दूसरी तरफ संपीड़ित करना।

वाल संग्रह

मास्टर postgresql.conf

wal_level = replica
archive_mode = on
archive_command = 'rsync -av -z %p [email protected]:/mnt/db/wal_archive/%f'

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

[वैकल्पिक] संग्रहीत WAL फ़ाइलों को संपीड़ित करें:

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

compress_WAL_archive.sh:

#!/bin/bash
# Compress any WAL files found that are not yet compressed
gzip /mnt/db/wal_archive/*[0-F]

नोट: किसी भी पुनर्प्राप्ति विधि के दौरान, किसी भी संपीड़ित फ़ाइलों को बाद में विघटित करने की आवश्यकता होगी। कुछ व्यवस्थापक केवल X संख्या के दिनों के बाद फ़ाइलों को संपीड़ित करने का विकल्प चुनते हैं, समग्र स्थान कम रखते हुए, लेकिन अतिरिक्त कार्य के बिना पुनर्प्राप्ति के लिए हाल की WAL फ़ाइलों को भी तैयार रखते हैं। अपनी पुनर्प्राप्ति गति को अधिकतम करने के लिए विचाराधीन डेटाबेस के लिए सबसे अच्छा विकल्प चुनें।

आधार बैकअप

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

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

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

base_backup.sh:

#!/bin/bash
backup_dir="$(date +'%Y-%m-%d')_backup"
cd /mnt/db/backups
mkdir $backup_dir
pg_basebackup -h <replica host> -p <replica port> -U replication -D $backup_dir -Ft -z

नोट: pg_basebackup कमांड मानता है कि यह होस्ट मास्टर पर उपयोगकर्ता 'प्रतिकृति' के लिए पासवर्ड रहित पहुंच के लिए स्थापित किया गया है, जो या तो इस PITR बैकअप होस्ट के लिए pg_hba में 'ट्रस्ट' द्वारा किया जा सकता है, .pgpass फ़ाइल में पासवर्ड, या अन्य सुरक्षित तरीके . बैकअप सेट करते समय सुरक्षा को ध्यान में रखें।

PITR पुनर्प्राप्ति परिदृश्य

पॉइंट इन टाइम रिकवरी सेट करना काम का केवल एक हिस्सा है, डेटा रिकवर करना दूसरा हिस्सा है। सौभाग्य से, ऐसा कभी नहीं हो सकता है, हालांकि यह सुनिश्चित करने के लिए कि सिस्टम काम करता है, और यह सुनिश्चित करने के लिए कि प्रक्रिया सही ढंग से ज्ञात / स्क्रिप्टेड है, समय-समय पर PITR बैकअप की बहाली करने का अत्यधिक सुझाव दिया जाता है।

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

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

मास्टर शट डाउन करें

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

पुनर्प्राप्ति के लिए आधार बैकअप सेट करें

इसके बाद, हमारे PITR होस्ट पर, हम इवेंट से पहले अपना सबसे हालिया बेस बैकअप प्राप्त करते हैं, जो बैकअप '2018-12-21_बैकअप' है।

mkdir /var/lib/pgsql/11/data
chmod 700 /var/lib/pgsql/11/data
cd /var/lib/pgsql/11/data
tar -xzvf /mnt/db/backups/2018-12-21_backup/base.tar.gz
cd pg_wal
tar -xzvf /mnt/db/backups/2018-12-21_backup/pg_wal.tar.gz
mkdir /mnt/db/wal_archive/pitr_restore/

इसके साथ, बेस बैकअप, साथ ही pg_basebackup द्वारा प्रदान की गई WAL फाइलें जाने के लिए तैयार हैं, अगर हम इसे अभी ऑनलाइन लाते हैं, तो यह बैकअप के बिंदु तक ठीक हो जाएगा, लेकिन हम बीच के सभी WAL लेनदेन को पुनर्प्राप्त करना चाहते हैं। मध्यरात्रि और 11:59 पूर्वाह्न, इसलिए हमने अपनी पुनर्प्राप्ति.कॉन्फ़ फ़ाइल सेट की।

recovery.conf बनाएं

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

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

नई पुनर्प्राप्ति.conf:

recovery_target_time = '2018-12-21 11:59:00-07'
restore_command = 'cp /mnt/db/wal_archive/%f.gz /var/lib/pgsql/test_recovery/pitr_restore/%f.gz && gunzip /var/lib/pgsql/test_recovery/pitr_restore/%f.gz && mv /var/lib/pgsql/test_recovery/pitr_restore/%f "%p"'

पुनर्प्राप्ति प्रक्रिया प्रारंभ करें

अब जब सब कुछ सेट हो गया है, हम पुनर्प्राप्ति के लिए प्रक्रिया शुरू करेंगे। जब ऐसा होता है, तो यह सुनिश्चित करने के लिए डेटाबेस लॉग को पूंछना एक अच्छा विचार है कि यह इरादे के अनुसार बहाल हो रहा है।

डीबी प्रारंभ करें:

pg_ctl -D /var/lib/pgsql/11/data start

लॉग को टेल करें:

कई लॉग प्रविष्टियाँ होंगी जो दिखाती हैं कि डेटाबेस संग्रह फ़ाइलों से पुनर्प्राप्त हो रहा है, और एक निश्चित बिंदु पर, यह "लेन-देन करने से पहले पुनर्प्राप्ति रोकना ..." कहते हुए एक पंक्ति दिखाएगा।

2018-12-22 04:21:30 UTC [20565]: [705-1] user=,db=,app=,client= LOG:  restored log file "000000010000000400000074" from archive
2018-12-22 04:21:30 UTC [20565]: [706-1] user=,db=,app=,client= LOG:  restored log file "000000010000000400000075" from archive
2018-12-22 04:21:31 UTC [20565]: [707-1] user=,db=,app=,client= LOG:  restored log file "000000010000000400000076" from archive
2018-12-22 04:21:31 UTC [20565]: [708-1] user=,db=,app=,client= LOG:  restored log file "000000010000000400000077" from archive
2018-12-22 04:21:31 UTC [20565]: [709-1] user=,db=,app=,client= LOG:  recovery stopping before commit of transaction 611765, time 2018-12-21 11:59:01.45545+07

इस बिंदु पर, पुनर्प्राप्ति प्रक्रिया ने सभी WAL फ़ाइलों को निगल लिया है, लेकिन मास्टर के रूप में ऑनलाइन आने से पहले इसकी समीक्षा की भी आवश्यकता है। इस उदाहरण में, लॉग नोट करता है कि 11:59:00 के पुनर्प्राप्ति लक्ष्य समय के बाद अगला लेन-देन 11:59:01 था, और इसे पुनर्प्राप्त नहीं किया गया था। सत्यापित करने के लिए, डेटाबेस में लॉग इन करें और एक नज़र डालें, चल रहे डेटाबेस को ठीक 11:59 बजे तक एक स्नैपशॉट होना चाहिए।

जब सब कुछ अच्छा लगे, तो एक मास्टर के रूप में पुनर्प्राप्ति को बढ़ावा देने का समय आ गया है।

postgres=# SELECT pg_wal_replay_resume();
 pg_wal_replay_resume
----------------------

(1 row)

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

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

समय पर पुनर्प्राप्ति परिदृश्य में अन्य बिंदु

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

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

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