केवल आपके PostgreSQL डेटाबेस का नियमित बैकअप होना आपदा पुनर्प्राप्ति के लिए पर्याप्त नहीं है - आपको यह सुनिश्चित करने की आवश्यकता है कि पुनर्स्थापना प्रक्रिया के लिए आवश्यक होने पर बैकअप फ़ाइलें सुलभ और स्वस्थ हों। PostgreSQL बैकअप के स्वचालित परीक्षण को सेटअप करने के कुछ उदाहरण देखने के लिए आगे पढ़ें।
बैकअप pg_basebackup का उपयोग करके बनाया गया
pg_basebackup बैकअप में डेटाबेसक्लस्टर के लिए संपूर्ण डेटा निर्देशिका होती है। इस निर्देशिका को आमतौर पर एक टारबॉल में पैक किया जाता है, कभी-कभी WAL फ़ाइलों के लिए एक अतिरिक्त टारबॉल के साथ जो बैकअप की शुरुआत के बाद से बनाई गई थी।
ऐसे pg_basebackup . का परीक्षण करने के लिए टैरबॉल, पहले टैरबॉल को खाली निर्देशिका में अनपैक करें। यदि कोई अलग WAL फ़ाइल टारबॉल है, तो उसे pg_wal . में अनपैक करें नई निर्देशिका के अंदर निर्देशिका:
$ mkdir backup-test
$ cd backup-test
$ tar --no-same-owner xvf /path/to/base.tar.gz
$ mkdir -p pg_wal
$ cd pg_wal
$ tar --no-same-owner xvf /path/to/pg_wal.tar.gzअब आप इस निर्देशिका के लिए PostgreSQL सर्वर प्रक्रिया शुरू कर सकते हैं:
$ pg_ctl -D path/to/backup-test start(नोट:pg_ctl मानक पोस्टग्रेज़ वितरण में शामिल एक कमांड-लाइन टूल है। यह हर जगह उपलब्ध है जो पोस्टग्रेज़ ही है, अन्य शामिल टूल जैसे psql के समान है। और pg_dump .pg_ctl के बारे में यहाँ और जानें।)
यदि इस मशीन पर पहले से ही एक PostgreSQL सर्वर स्थापित/चल रहा है, तो आप शायद डिफ़ॉल्ट 5432 के अलावा किसी अन्य पोर्ट पर प्रारंभ करना चाहेंगे:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startयदि अब तक सब कुछ सफल रहा है, तो आप जांचना चाहेंगे कि आपके पुनर्स्थापित डेटाबेस के अंदर डेटा समझदार है या नहीं। यदि आपके पास अपने डेटाबेस के विरुद्ध चलाने के लिए स्वचालित परीक्षण स्क्रिप्ट हैं, तो अब इस पुनर्स्थापित डेटाबेस के विरुद्ध उन परीक्षणों के कम से कम एक छोटे सेट को लॉन्च करने का एक अच्छा समय होगा। यदि नहीं, तो आप psql का उपयोग करके कुछ त्वरित जांचों को एक साथ हैक कर सकते हैं:
$ psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"उपरोक्त आदेश एक टेबल के खिलाफ एक साधारण क्वेरी करता है जो मौजूद होना चाहिए। psql का एग्जिट कोड आपको बताएगा कि क्वेरी सफल हुई या नहीं। बेशक, आप अधिक जटिल क्वेरी चला सकते हैं, या एक .sql फ़ाइल चला सकते हैं, या यहां तक कि एक अलग टेस्टस्क्रिप्ट भी चला सकते हैं जो इस डेटाबेस से कनेक्ट होगी और परीक्षण चलाएगी।
जब आप परीक्षण के साथ काम कर लेते हैं, तो आप पोस्टग्रेज सर्वर प्रक्रिया को इसके साथ रोक सकते हैं:
$ pg_ctl -D path/to/backup-test stopऔर संपूर्ण निकाले गए डेटाबेस क्लस्टर निर्देशिका को साफ़ करें:
$ rm -rf path/to/backup-testयहां बताया गया है कि जब यह सब एक साथ हो जाता है तो यह कैसा दिखता है:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzबैकअप pg_dump का उपयोग करके बनाया गया
pg_dump उपकरण (दस्तावेज़) का उपयोग बैकअप बनाने के लिए भी किया जा सकता है - यह अधिक लचीला है कि आप वैकल्पिक रूप से उस डेटाबेस/स्कीमा/तालिकाओं का चयन कर सकते हैं जिसका आप बैकअप लेना चाहते हैं, pg_basebackup के विपरीत जो एक सर्व-या-कुछ नहीं की प्रक्रिया है।
pg_dump . के साथ , आप एक .sql उत्पन्न कर सकते हैं स्क्रिप्ट या बाइनरी .pgdmp फ़ाइल जिसमें सभी डेटा शामिल हैं (और वैकल्पिक रूप से टेबल/इंडेक्स आदि बनाने के लिए डीडीएल स्टेटमेंट भी)। ऐसी फ़ाइल को पुनर्स्थापित करने के लिए, आपको एक livedatabase सर्वर से कनेक्ट करने और .sql/.pgdmp फ़ाइल के अंदर SQL कमांड चलाने की आवश्यकता है। जबकि आप नियमित psql . का उपयोग कर सकते हैं .sql फ़ाइल को चलाने के लिए, आपको pg_restore . का उपयोग करना होगा आदेश (दस्तावेज़) .pgdmp फ़ाइल को चलाने के लिए।
ऐसे बैकअप का परीक्षण करने के लिए, पहले हम फ़ाइल लाते हैं और फिर एक नया, खाली डेटाबेस क्लस्टर बनाते हैं:
$ rm -rf path/to/backup-test
$ pg_ctl -D path/to/backup-test initdbऔर उस पर एक पोस्टग्रेएसक्यूएल सर्वर शुरू करें, पोर्ट 6000 पर पहले की तरह सुनें:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startpg_dump . उत्पन्न करना संभव है फ़ाइलें जो पूरी तरह से स्व-निहित हैं, लेकिन ऐसा नहीं होने के लिए उन्हें उत्पन्न करना भी संभव है। इसलिए, डंप कैसे उत्पन्न हुआ, इस पर निर्भर करते हुए, कुछ सेटअप चरणों की आवश्यकता हो सकती है:
- डेटाबेस बनाएं
- टेबल, इंडेक्स आदि बनाएं.
- विशेषाधिकार प्रदान करें
एक बार यह हो जाने के बाद, आप या तो psql . का उपयोग कर सकते हैं या pg_restore डेटाबैक को जीवन में लाने के लिए:
# for .sql files
$ psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# for .pgdmp files
$ pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmpपहले की तरह, इस समय, पुनर्स्थापित डेटा की शुद्धता सुनिश्चित करने के लिए परीक्षण किए जा सकते हैं।
यह कैसा दिखता है, सभी को एक साथ रखा गया है:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest dump
# TODO: copy out the dump.sql or dump.pgdmp of latest backup
# create an empty database cluster
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
pg_ctl -D $BACKUP_DIR initdb
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# TODO: perform any specific setup steps here
# restore the file, .sql:
psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# or .pgdmp:
pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmp
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/dump.*ट्रिगर से सावधान रहें
pg_dump . को पुनर्स्थापित करते समय बैकअप, डेटा टेबल में डाला जाता है, ठीक उसी तरह जब कोई एप्लिकेशन करता है। यदि आपके पास ऐसे ट्रिगर हैं जो पंक्ति सम्मिलन की सूचना देने के लिए बाहरी सेवाओं से जुड़ते हैं, तो उन्हें पुनर्स्थापित करने की प्रक्रिया के दौरान अक्षम करना सबसे अच्छा होगा।
pg_dump . का आह्वान करते समय sql फ़ाइलों को उत्सर्जित करने के लिए, आप विकल्प का उपयोग कर सकते हैं--disable-triggers बताने के लिए pg_dump डालने के दौरान ट्रिगर्स को अक्षम करने के लिए स्क्रिप्ट उत्पन्न करने के लिए।
pg_restore . का आह्वान करते समय एक डेटाबेस पर जिसमें पहले से ही ट्रिगर हैं, आप --disable-triggers . का उपयोग कर सकते हैं pg_restore . में उसी प्रभाव को प्राप्त करने के लिए।
PITR परीक्षण
Postgres में पॉइंट-इन-टाइम-रिकवरी (PITR) pg_basebackup का उपयोग करके लिए गए पूर्ण बैकअप पर निर्भर करता है , और उस बिंदु से उस समय तक WAL फ़ाइलों का एक क्रम जब आप पुनर्प्राप्त करना चाहते हैं। इसलिए PITR के परीक्षण में पूर्ण बैकअप के साथ-साथ बाद की WAL फ़ाइलों का परीक्षण शामिल है।
स्वचालित बैकअप परीक्षण के लिए, हमारे पास कोई विशिष्ट पुनर्प्राप्ति लक्ष्य नहीं है। पिछले बैकअप से लेकर सबसे हाल के एक तक सभी संग्रहीत WAL फ़ाइलों का परीक्षण किया जाना चाहिए। इसका परीक्षण करने का सबसे आसान तरीका pg_basebackup . के समान चरणों का पालन करना है परीक्षण विधि, केवल एक अतिरिक्त चरण के साथ। नवीनतम बैकअप को अनपैक करने के बाद, सभी प्रासंगिक और उपलब्ध WAL फ़ाइलें प्राप्त करें और उन्हें pg_wal में रखें Postgres सर्वर शुरू करने से पहले। विशेष रूप से:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# --> this is the new extra step <--
# TODO: fetch all WAL files from the WAL archive since the last
# backup, and place them in $BACKUP_DIR/pg_wal
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzयह सत्यापित करना चाहिए कि क्या अंतिम बैकअप और बाद की WAL फाइलें दोनों अच्छी हैं, ताकि जरूरत पड़ने पर उनका उपयोग PITR के लिए किया जा सके।
