वाल-जी: PostgreSQL DBMS का बैकअप और पुनर्प्राप्ति

यह लंबे समय से ज्ञात है कि SQL डंप में बैकअप बनाना (उपयोग करना)। पीजी_डंप या pg_dumpall) एक अच्छा विचार नहीं है. PostgreSQL DBMS का बैकअप लेने के लिए कमांड का उपयोग करना बेहतर है pg_basebackup, जो वाल लॉग की एक बाइनरी कॉपी बनाता है। लेकिन जब आप एक प्रतिलिपि बनाने और पुनर्स्थापित करने की पूरी प्रक्रिया का अध्ययन करना शुरू करते हैं, तो आप समझेंगे कि इसे काम करने के लिए आपको कम से कम कुछ ट्राइसाइकिल लिखने की आवश्यकता है और इससे आपको ऊपर और नीचे दोनों जगह दर्द नहीं होगा। पीड़ा को कम करने के लिए, वाल-जी विकसित किया गया था।

वाल-जी PostgreSQL डेटाबेस का बैकअप लेने और पुनर्स्थापित करने के लिए Go में लिखा गया एक टूल है (और हाल ही में MySQL/MariaDB, MongoDB और फाउंडेशनDB). यह अमेज़ॅन एस 3 स्टोरेज (और एनालॉग्स, उदाहरण के लिए, यांडेक्स ऑब्जेक्ट स्टोरेज) के साथ-साथ Google क्लाउड स्टोरेज, एज़्योर स्टोरेज, स्विफ्ट ऑब्जेक्ट स्टोरेज और बस फ़ाइल सिस्टम के साथ काम करने का समर्थन करता है। पूरा सेटअप सरल चरणों में आता है, लेकिन इस तथ्य के कारण कि इसके बारे में लेख इंटरनेट पर बिखरे हुए हैं, कोई पूर्ण कैसे करें मैनुअल नहीं है जिसमें शुरू से अंत तक सभी चरण शामिल होंगे (हैबे पर कई पोस्ट हैं, लेकिन वहां कई बिंदु छूट गए हैं)।

यह लेख मुख्य रूप से मेरे ज्ञान को व्यवस्थित करने के लिए लिखा गया था। मैं डीबीए नहीं हूं और मैं खुद को आम आदमी की भाषा में व्यक्त कर सकता हूं, इसलिए किसी भी सुधार का स्वागत है!

अलग से, मैं नोट करता हूं कि नीचे दी गई हर चीज प्रासंगिक है और Ubuntu 12.3 पर PostgreSQL 18.04 के लिए परीक्षण की गई है, सभी कमांड को एक विशेषाधिकार प्राप्त उपयोगकर्ता के रूप में निष्पादित किया जाना चाहिए।

स्थापना

इस लेख को लिखने के समय, WAL-G का स्थिर संस्करण है v0.2.15 (मार्च 2020). यही हम उपयोग करेंगे (लेकिन यदि आप इसे मास्टर शाखा से स्वयं बनाना चाहते हैं, तो जीथब रिपॉजिटरी में इसके लिए सभी निर्देश हैं). डाउनलोड और इंस्टॉल करने के लिए आपको यह करना होगा:

#!/bin/bash

curl -L "https://github.com/wal-g/wal-g/releases/download/v0.2.15/wal-g.linux-amd64.tar.gz" -o "wal-g.linux-amd64.tar.gz"
tar -xzf wal-g.linux-amd64.tar.gz
mv wal-g /usr/local/bin/

इसके बाद, आपको पहले WAL-G और फिर PostgreSQL को कॉन्फ़िगर करना होगा।

वाल-जी की स्थापना

बैकअप संग्रहीत करने के उदाहरण के लिए, अमेज़ॅन S3 का उपयोग किया जाएगा (क्योंकि यह मेरे सर्वर के करीब है और इसका उपयोग बहुत सस्ता है). इसके साथ काम करने के लिए, आपको एक "s3 बकेट" और एक्सेस कुंजियों की आवश्यकता होगी।

वाल-जी के बारे में पिछले सभी लेखों में पर्यावरण चर का उपयोग करके कॉन्फ़िगरेशन का उपयोग किया गया था, लेकिन इस रिलीज़ के साथ सेटिंग्स का पता लगाया जा सकता है .walg.json फ़ाइल पोस्टग्रेज़ उपयोगकर्ता की होम निर्देशिका में। इसे बनाने के लिए, निम्नलिखित बैश स्क्रिप्ट चलाएँ:

#!/bin/bash

cat > /var/lib/postgresql/.walg.json << EOF
{
    "WALG_S3_PREFIX": "s3://your_bucket/path",
    "AWS_ACCESS_KEY_ID": "key_id",
    "AWS_SECRET_ACCESS_KEY": "secret_key",
    "WALG_COMPRESSION_METHOD": "brotli",
    "WALG_DELTA_MAX_STEPS": "5",
    "PGDATA": "/var/lib/postgresql/12/main",
    "PGHOST": "/var/run/postgresql/.s.PGSQL.5432"
}
EOF
# обязательно меняем владельца файла:
chown postgres: /var/lib/postgresql/.walg.json

आइए मैं सभी मापदंडों के बारे में थोड़ा समझाता हूं:

• WALG_S3_PREFIX - आपके S3 बकेट का पथ जहां बैकअप अपलोड किया जाएगा (आप या तो रूट पर या किसी फ़ोल्डर में कर सकते हैं);
• AWS_ACCESS_KEY_ID - S3 में एक्सेस कुंजी (परीक्षण सर्वर पर पुनर्प्राप्ति के मामले में, इन कुंजियों में केवल पढ़ने योग्य नीति होनी चाहिए! पुनर्प्राप्ति अनुभाग में इसका अधिक विस्तार से वर्णन किया गया है।);
• AWS_SECRET_ACCESS_KEY - S3 भंडारण में गुप्त कुंजी;
• WALG_संपीड़न_विधि - संपीड़न विधि, ब्रॉटली का उपयोग करना बेहतर है (क्योंकि यह अंतिम आकार और संपीड़न/डीकंप्रेसन गति के बीच का सुनहरा मतलब है);
• WALG_DELTA_MAX_STEPS - पूर्ण बैकअप बनाने से पहले "डेल्टा" की संख्या (वे समय और डाउनलोड किए गए डेटा का आकार बचाते हैं, लेकिन पुनर्प्राप्ति प्रक्रिया को थोड़ा धीमा कर सकते हैं, इसलिए बड़े मूल्यों का उपयोग करना उचित नहीं है);
• पीजीडेटा - आपके डेटाबेस डेटा के साथ निर्देशिका का पथ (आप कमांड चलाकर पता लगा सकते हैं pg_lsclusters);
• पीजीहोस्ट - डेटाबेस से कनेक्ट करना, स्थानीय बैकअप के साथ यूनिक्स-सॉकेट के माध्यम से करना बेहतर है जैसा कि इस उदाहरण में है।

अन्य पैरामीटर दस्तावेज़ में पाए जा सकते हैं: https://github.com/wal-g/wal-g/blob/v0.2.15/PostgreSQL.md#configuration.

PostgreSQL को कॉन्फ़िगर करना

डेटाबेस के अंदर संग्रहकर्ता के लिए वाल लॉग को क्लाउड पर अपलोड करने और उन्हें उनसे पुनर्स्थापित करने के लिए (यदि आवश्यक हो), आपको कॉन्फ़िगरेशन फ़ाइल में कई पैरामीटर सेट करने की आवश्यकता है /etc/postgresql/12/main/postgresql.conf. सिर्फ शुरुआत के लिए आपको यह सुनिश्चित करना होगानीचे दी गई कोई भी सेटिंग किसी अन्य मान पर सेट नहीं है, ताकि जब कॉन्फ़िगरेशन पुनः लोड हो, तो DBMS क्रैश न हो। आप इन मापदंडों का उपयोग करके जोड़ सकते हैं:

#!/bin/bash

echo "wal_level=replica" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_mode=on" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_command='/usr/local/bin/wal-g wal-push "%p" >> /var/log/postgresql/archive_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf
echo “archive_timeout=60” >> /etc/postgresql/12/main/postgresql.conf
echo "restore_command='/usr/local/bin/wal-g wal-fetch "%f" "%p" >> /var/log/postgresql/restore_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf

# перезагружаем конфиг через отправку SIGHUP сигнала всем процессам БД
killall -s HUP postgres

सेट किए जाने वाले पैरामीटर का विवरण:

• wal_level - वाल लॉग में कितनी जानकारी लिखनी है, "प्रतिकृति" - सब कुछ लिखें;
• पुरालेख_मोड - पैरामीटर से कमांड का उपयोग करके वाल लॉग डाउनलोड करना सक्षम करें संग्रह_कमांड;
• संग्रह_कमांड - पूर्ण वाल लॉग को संग्रहीत करने के लिए आदेश;
• Archive_timeout - लॉग का संग्रह तभी किया जाता है जब यह पूरा हो जाता है, लेकिन यदि आपका सर्वर डेटाबेस में थोड़ा डेटा बदलता/जोड़ता है, तो यहां सेकंड में एक सीमा निर्धारित करना समझ में आता है, जिसके बाद संग्रह कमांड को जबरन कॉल किया जाएगा (मैं हर सेकंड डेटाबेस पर गहनता से लिखता हूं, इसलिए मैंने इस पैरामीटर को उत्पादन में सेट नहीं करने का फैसला किया);
• पुनर्स्थापना_कमांड - यदि "पूर्ण बैकअप" (बेस बैकअप) में डेटाबेस में नवीनतम परिवर्तनों का अभाव है, तो बैकअप से वाल लॉग को पुनर्स्थापित करने के लिए कमांड का उपयोग किया जाएगा।

आप आधिकारिक दस्तावेज़ के अनुवाद में इन सभी मापदंडों के बारे में अधिक पढ़ सकते हैं: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

बैकअप शेड्यूल सेट करना

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

#!/bin/bash

su - postgres -c '/usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main'

लॉन्च तर्क डेटा निर्देशिका के पथ को इंगित करते हैं - मैं आपको याद दिलाता हूं कि आप इसे चलाकर पता लगा सकते हैं pg_lsclusters.

यदि सब कुछ त्रुटियों के बिना हुआ और डेटा S3 स्टोरेज में लोड किया गया था, तो आप crontab में आवधिक लॉन्च को कॉन्फ़िगर कर सकते हैं:

#!/bin/bash

echo "15 4 * * *    /usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main >> /var/log/postgresql/walg_backup.log 2>&1" >> /var/spool/cron/crontabs/postgres
# задаем владельца и выставляем правильные права файлу
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

इस उदाहरण में, बैकअप प्रक्रिया हर दिन सुबह 4:15 बजे शुरू होती है।

पुराने बैकअप हटाना

सबसे अधिक संभावना है, आपको मेसोज़ोइक युग के सभी बैकअप रखने की ज़रूरत नहीं है, इसलिए समय-समय पर आपके स्टोरेज को "साफ़" करना उपयोगी होगा (दोनों "पूर्ण बैकअप" और वाल लॉग)। हम यह सब एक क्रॉन कार्य के माध्यम से करेंगे:

#!/bin/bash

echo "30 6 * * *    /usr/local/bin/wal-g delete before FIND_FULL $(date -d '-10 days' '+%FT%TZ') --confirm >> /var/log/postgresql/walg_delete.log 2>&1" >> /var/spool/cron/crontabs/postgres
# ещё раз задаем владельца и выставляем правильные права файлу (хоть это обычно это и не нужно повторно делать)
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

क्रॉन हर दिन सुबह 6:30 बजे इस कार्य को चलाएगा, पिछले 10 दिनों की प्रतियों को छोड़कर सब कुछ (पूर्ण बैकअप, डेल्टा और वाल) हटा देगा, लेकिन कम से कम एक बैकअप छोड़ देगा से निर्दिष्ट तिथि ताकि कोई भी बिंदु के बाद तारीखें PITR में शामिल की गईं।

बैकअप से पुनर्स्थापित किया जा रहा है

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

अलग से ध्यान देने योग्य परीक्षण परिवेश में पुनर्स्थापित करने के लिए (वह सब कुछ जो उत्पादन नहीं किया गया है) आपको S3 में रीड ओनली खाते का उपयोग करने की आवश्यकता है ताकि गलती से बैकअप ओवरराइट न हो जाए। वाल-जी के मामले में, आपको समूह नीति में S3 उपयोगकर्ता के लिए निम्नलिखित अधिकार सेट करने होंगे (प्रभाव: अनुमति दें): s3:गेटऑब्जेक्ट, s3: सूची बकेट, s3:बकेट स्थान प्राप्त करें. और हां, सेट करना न भूलें संग्रह_मोड=बंद सेटिंग्स फ़ाइल में postgresql.conf, ताकि आपका परीक्षण डेटाबेस चुपचाप बैकअप नहीं लेना चाहे।

हाथ की हल्की सी हरकत से बहाली की जाती है सभी PostgreSQL डेटा हटाना (उपयोगकर्ताओं सहित), इसलिए कृपया निम्नलिखित आदेश चलाते समय बेहद सावधान रहें।

#!/bin/bash

# если есть балансировщик подключений (например, pgbouncer), то вначале отключаем его, чтобы он не нарыгал ошибок в лог
service pgbouncer stop
# если есть демон, который перезапускает упавшие процессы (например, monit), то останавливаем в нём процесс мониторинга базы (у меня это pgsql12)
monit stop pgsql12
# или останавливаем мониторинг полностью
service monit stop
# останавливаем саму базу данных
service postgresql stop
# удаляем все данные из текущей базы (!!!); лучше предварительно сделать их копию, если есть свободное место на диске
rm -rf /var/lib/postgresql/12/main
# скачиваем резервную копию и разархивируем её
su - postgres -c '/usr/local/bin/wal-g backup-fetch /var/lib/postgresql/12/main LATEST'
# помещаем рядом с базой специальный файл-сигнал для восстановления (см. https://postgrespro.ru/docs/postgresql/12/runtime-config-wal#RUNTIME-CONFIG-WAL-ARCHIVE-RECOVERY ), он обязательно должен быть создан от пользователя postgres
su - postgres -c 'touch /var/lib/postgresql/12/main/recovery.signal'
# запускаем базу данных, чтобы она инициировала процесс восстановления
service postgresql start

जो लोग पुनर्प्राप्ति प्रक्रिया की जांच करना चाहते हैं, उनके लिए नीचे बैश मैजिक का एक छोटा सा टुकड़ा तैयार किया गया है, ताकि पुनर्प्राप्ति में समस्याओं के मामले में, स्क्रिप्ट गैर-शून्य निकास कोड के साथ क्रैश हो जाएगी। इस उदाहरण में, यह पता लगाने के लिए कि क्या सिग्नल फ़ाइल हटा दी गई थी (इसका मतलब यह होगा कि पुनर्प्राप्ति सफल रही थी) 120 सेकंड के टाइमआउट (पुनर्प्राप्ति के लिए कुल 5 मिनट) के साथ 10 जाँचें की जाती हैं:

#!/bin/bash

CHECK_RECOVERY_SIGNAL_ITER=0
while [ ${CHECK_RECOVERY_SIGNAL_ITER} -le 120 ]
do
    if [ ! -f "/var/lib/postgresql/12/main/recovery.signal" ]
    then
        echo "recovery.signal removed"
        break
    fi
    sleep 5
    ((CHECK_RECOVERY_SIGNAL_ITER+1))
done

# если после всех проверок файл всё равно существует, то падаем с ошибкой
if [ -f "/var/lib/postgresql/12/main/recovery.signal" ]
then
    echo "recovery.signal still exists!"
    exit 17
fi

सफल पुनर्प्राप्ति के बाद, सभी प्रक्रियाओं को वापस शुरू करना न भूलें (pgbouncer/monit, आदि)।

पुनर्प्राप्ति के बाद डेटा की जाँच करना

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

डेटा की जांच करने के लिए, इसे डंप के माध्यम से चलाना पर्याप्त है, लेकिन यह बेहतर है कि डेटाबेस बनाते समय आपके पास चेकसम सक्षम हो (डेटा चेकसम):

#!/bin/bash

if ! su - postgres -c 'pg_dumpall > /dev/null'
then
    echo 'pg_dumpall failed'
    exit 125
fi

अनुक्रमणिका की जाँच करने के लिए - मौजूद है एमचेक मॉड्यूलआइए इसके लिए एसक्यूएल क्वेरी लें वाल-जी परीक्षण और इसके चारों ओर थोड़ा तर्क बनाएं:

#!/bin/bash

# добавляем sql-запрос для проверки в файл во временной директории
cat > /tmp/amcheck.sql << EOF
CREATE EXTENSION IF NOT EXISTS amcheck;
SELECT bt_index_check(c.oid), c.relname, c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree'
AND c.relpersistence != 't'
AND i.indisready AND i.indisvalid;
EOF
chown postgres: /tmp/amcheck.sql

# добавляем скрипт для запуска проверок всех доступных баз в кластере
# (обратите внимание что переменные и запуск команд – экранированы)
cat > /tmp/run_amcheck.sh << EOF
for DBNAME in $(su - postgres -c 'psql -q -A -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;" ')
do
    echo "Database: ${DBNAME}"
    su - postgres -c "psql -f /tmp/amcheck.sql -v 'ON_ERROR_STOP=1' ${DBNAME}" && EXIT_STATUS=$? || EXIT_STATUS=$?
    if [ "${EXIT_STATUS}" -ne 0 ]
    then
        echo "amcheck failed on DB: ${DBNAME}"
        exit 125
    fi
done
EOF
chmod +x /tmp/run_amcheck.sh

# запускаем скрипт
/tmp/run_amcheck.sh > /tmp/amcheck.log

# для проверки что всё прошло успешно можно проверить exit code или grep’нуть ошибку
if grep 'amcheck failed' "/tmp/amcheck.log"
then
    echo 'amcheck failed: '
    cat /tmp/amcheck.log
    exit 125
fi

सारांश

मैं प्रकाशन तैयार करने में मदद के लिए एंड्री बोरोडिन का आभार व्यक्त करना चाहता हूं और वाल-जी के विकास में उनके योगदान के लिए विशेष धन्यवाद देना चाहता हूं!

इससे यह नोट समाप्त होता है। मुझे आशा है कि मैं सेटअप में आसानी और आपकी कंपनी में इस टूल के उपयोग की विशाल संभावनाओं के बारे में बताने में सक्षम था। मैंने वाल-जी के बारे में बहुत कुछ सुना है, लेकिन मेरे पास कभी बैठकर इसका पता लगाने का पर्याप्त समय नहीं था। और जब मैंने इसे घर पर लागू किया, तो यह लेख मेरे सामने आया।

अलग से, यह ध्यान देने योग्य है कि वाल-जी निम्नलिखित डीबीएमएस के साथ भी काम कर सकता है:

• MySQL / MariaDB;
• MongoDB;
• फाउंडेशनडीबी;
• और प्रतिबद्धताओं को देखते हुए, कई और अपेक्षाएँ अपेक्षित हैं!

स्रोत: www.habr.com