WAL-G: PostgreSQL DBMS चे बॅकअप आणि पुनर्प्राप्ती

एसक्यूएल डंपमध्ये बॅकअप बनवणे (वापरून pg_dump किंवा pg_dumpall) ही चांगली कल्पना नाही. PostgreSQL DBMS चा बॅकअप घेण्यासाठी, कमांड वापरणे चांगले pg_basebackup, जे WAL लॉगची बायनरी प्रत बनवते. परंतु जेव्हा तुम्ही प्रत तयार करण्याच्या आणि पुनर्संचयित करण्याच्या संपूर्ण प्रक्रियेचा अभ्यास करण्यास प्रारंभ कराल, तेव्हा तुम्हाला हे समजेल की हे कार्य करण्यासाठी तुम्हाला कमीतकमी दोन ट्रायसायकल लिहिण्याची आवश्यकता आहे आणि तुम्हाला वर आणि खाली दोन्ही वेदना होणार नाहीत. दुःख कमी करण्यासाठी, WAL-G विकसित केले गेले.

WAL-G पोस्टग्रेएसक्यूएल डेटाबेसचा बॅकअप आणि पुनर्संचयित करण्यासाठी गो मध्ये लिहिलेले एक साधन आहे (आणि अगदी अलीकडे MySQL/MariaDB, MongoDB आणि FoundationDB). हे Amazon S3 स्टोरेज (आणि analogues, उदाहरणार्थ, Yandex Object Storage), तसेच Google Cloud Storage, Azure Storage, Swift Object Storage आणि फक्त फाइल सिस्टमसह कार्य करण्यास समर्थन देते. संपूर्ण सेटअप सोप्या चरणांवर येतो, परंतु त्याबद्दलचे लेख इंटरनेटवर विखुरलेले असल्यामुळे, सुरुवातीपासून शेवटपर्यंतच्या सर्व चरणांचा समावेश असणारे कोणतेही पूर्ण कसे करायचे मॅन्युअल नाही (हॅब्रेवर अनेक पोस्ट आहेत, परंतु तेथे बरेच मुद्दे चुकले आहेत).

हा लेख प्रामुख्याने माझे ज्ञान व्यवस्थित करण्यासाठी लिहिला गेला आहे. मी डीबीए नाही आणि मी कुठेतरी सामान्य माणसाच्या भाषेत स्वतःला व्यक्त करू शकतो, त्यामुळे कोणत्याही सुधारणांचे स्वागत आहे!

स्वतंत्रपणे, मी लक्षात घेतो की खाली दिलेली प्रत्येक गोष्ट संबंधित आहे आणि उबंटू 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 कॉन्फिगर करणे आवश्यक आहे.

WAL-G सेट करत आहे

बॅकअप संचयित करण्याच्या उदाहरणासाठी, Amazon S3 वापरला जाईल (कारण ते माझ्या सर्व्हरच्या जवळ आहे आणि त्याचा वापर खूप स्वस्त आहे). त्याच्यासह कार्य करण्यासाठी, आपल्याला "s3 बादली" आणि प्रवेश की आवश्यक आहेत.

WAL-G बद्दलच्या मागील सर्व लेखांमध्ये पर्यावरण व्हेरिएबल्स वापरून कॉन्फिगरेशन वापरले, परंतु या प्रकाशनासह सेटिंग्ज येथे स्थित असू शकतात .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_COMPRESSION_METHOD - कम्प्रेशन पद्धत, ब्रॉटली वापरणे चांगले आहे (अंतिम आकार आणि कॉम्प्रेशन/डीकंप्रेशन गती दरम्यान हे सोनेरी मध्यम आहे);
• WALG_DELTA_MAX_STEPS - पूर्ण बॅकअप तयार करण्यापूर्वी "डेल्टा" ची संख्या (ते वेळ आणि डाउनलोड केलेल्या डेटाचा आकार वाचवतात, परंतु पुनर्प्राप्ती प्रक्रिया थोडी कमी करू शकतात, म्हणून मोठ्या मूल्यांचा वापर करणे उचित नाही);
• PGDATA - तुमच्या डेटाबेस डेटासह निर्देशिकेचा मार्ग (आपण कमांड चालवून शोधू शकता pg_lsclusters);
• PGHOST - डेटाबेसशी कनेक्ट करणे, स्थानिक बॅकअपसह ते या उदाहरणाप्रमाणे युनिक्स-सॉकेटद्वारे करणे चांगले आहे.

इतर पॅरामीटर्स दस्तऐवजीकरणामध्ये आढळू शकतात: https://github.com/wal-g/wal-g/blob/v0.2.15/PostgreSQL.md#configuration.

PostgreSQL सेट करत आहे

डेटाबेसमधील आर्काइव्हरला क्लाउडवर WAL लॉग अपलोड करण्यासाठी आणि त्यांच्याकडून ते पुनर्संचयित करण्यासाठी (आवश्यक असल्यास), तुम्हाला कॉन्फिगरेशन फाइलमध्ये अनेक पॅरामीटर्स सेट करणे आवश्यक आहे. /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 – WAL लॉगमध्ये किती माहिती लिहायची, “प्रतिकृती” – सर्वकाही लिहा;
• संग्रहण_मोड - पॅरामीटरमधील कमांड वापरून WAL लॉग डाउनलोड करणे सक्षम करा archive_command;
• archive_command - पूर्ण केलेले WAL लॉग संग्रहित करण्यासाठी आदेश;
• संग्रहण_कालबाह्य - लॉगचे संग्रहण पूर्ण झाल्यावरच केले जाते, परंतु जर तुमचा सर्व्हर डेटाबेसमध्ये थोडासा डेटा बदलत/जोडत असेल, तर काही सेकंदात येथे मर्यादा सेट करणे अर्थपूर्ण आहे, त्यानंतर संग्रहण आदेश जबरदस्तीने कॉल केला जाईल (मी प्रत्येक सेकंदाला डेटाबेसवर गहनपणे लिहितो, म्हणून मी हे पॅरामीटर उत्पादनात सेट न करण्याचा निर्णय घेतला);
• restore_command - जर "पूर्ण बॅकअप" (बेस बॅकअप) डेटाबेसमध्ये नवीनतम बदल नसतील तर बॅकअपमधून WAL लॉग पुनर्संचयित करण्याची आज्ञा वापरली जाईल.

अधिकृत दस्तऐवजीकरणाच्या भाषांतरामध्ये आपण या सर्व पॅरामीटर्सबद्दल अधिक वाचू शकता: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

बॅकअप शेड्यूल सेट करत आहे

कोणी काहीही म्हणो, तो चालवण्याचा सर्वात सोयीस्कर मार्ग म्हणजे क्रॉन. हे आम्ही बॅकअप तयार करण्यासाठी कॉन्फिगर करू. पूर्ण बॅकअप तयार करण्याच्या आदेशासह प्रारंभ करूया: wal-g मध्ये हा लॉन्च युक्तिवाद आहे बॅकअप-पुश. परंतु प्रथम, सर्व काही ठीक आहे याची खात्री करण्यासाठी पोस्टग्रेस वापरकर्त्याकडून ही आज्ञा व्यक्तिचलितपणे चालवणे चांगले आहे (आणि प्रवेश त्रुटी नाहीत):

#!/bin/bash

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

लॉन्च वितर्क डेटा निर्देशिकेचा मार्ग दर्शवितात - मी तुम्हाला आठवण करून देतो की तुम्ही ते चालवून शोधू शकता pg_lsclusters.

जर सर्व काही त्रुटींशिवाय झाले असेल आणि डेटा S3 स्टोरेजमध्ये लोड केला गेला असेल, तर तुम्ही क्रॉन्टॅबमध्ये नियतकालिक लाँच कॉन्फिगर करू शकता:

#!/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 वाजता सुरू होते.

जुने बॅकअप हटवत आहे

बहुधा, तुम्हाला मेसोझोइक कालखंडातील सर्व बॅकअप्स ठेवण्याची गरज नाही, त्यामुळे तुमचे स्टोरेज वेळोवेळी "साफ करणे" ("पूर्ण बॅकअप" आणि WAL लॉग दोन्ही) उपयुक्त ठरेल. आम्ही हे सर्व क्रॉन टास्कद्वारे करू:

#!/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 दिवसांच्या प्रती वगळता सर्वकाही (पूर्ण बॅकअप, डेल्टा आणि WAL) हटवेल, परंतु किमान एक बॅकअप सोडेल. ते निर्दिष्ट तारीख जेणेकरून कोणताही बिंदू после PITR मध्ये तारखा समाविष्ट केल्या होत्या.

बॅकअपमधून पुनर्संचयित करत आहे

हे गुपित नाही की निरोगी डेटाबेसची गुरुकिल्ली वेळोवेळी पुनर्संचयित करणे आणि आतील डेटाच्या अखंडतेची पडताळणी आहे. मी तुम्हाला या विभागात WAL-G वापरून पुनर्प्राप्त कसे करायचे ते सांगेन आणि आम्ही चेकबद्दल नंतर बोलू.

हे स्वतंत्रपणे लक्षात घेण्यासारखे आहे चाचणी वातावरणात पुनर्संचयित करण्यासाठी (प्रोडक्शन नसलेली प्रत्येक गोष्ट) तुम्हाला S3 मध्ये फक्त वाचनीय खाते वापरण्याची आवश्यकता आहे जेणेकरून चुकून बॅकअप ओव्हरराइट होऊ नये. WAL-G च्या बाबतीत, तुम्हाला S3 वापरकर्त्यासाठी गट धोरणामध्ये खालील अधिकार सेट करणे आवश्यक आहे (प्रभाव: परवानगी द्या): s3:GetObject, s3:ListBucket, s3:GetBucketLocation. आणि, अर्थातच, सेट करण्यास विसरू नका archive_mode=बंद सेटिंग्ज फाइलमध्ये 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, इ.).

पुनर्प्राप्तीनंतर डेटा तपासत आहे

पुनर्संचयित केल्यानंतर डेटाबेसची अखंडता तपासणे अत्यावश्यक आहे, जेणेकरून तुटलेली/कुटिल बॅकअप असलेली परिस्थिती उद्भवणार नाही. आणि प्रत्येक तयार केलेल्या संग्रहासह हे करणे अधिक चांगले आहे, परंतु कुठे आणि कसे हे केवळ आपल्या कल्पनेवर अवलंबून असते (आपण प्रति तास वैयक्तिक सर्व्हर वाढवू शकता किंवा CI मध्ये तपासणी करू शकता). परंतु किमान, डेटाबेसमधील डेटा आणि निर्देशांक तपासणे आवश्यक आहे.

डेटा तपासण्यासाठी, तो डंपद्वारे चालवणे पुरेसे आहे, परंतु डेटाबेस तयार करताना आपण चेकसम सक्षम केलेले असणे चांगले आहे (डेटा चेकसम):

#!/bin/bash

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

निर्देशांक तपासण्यासाठी - अस्तित्वात आहे amcheck मॉड्यूल, त्यासाठी sql क्वेरी घेऊ WAL-G चाचण्या आणि त्याभोवती थोडे तर्क तयार करा:

#!/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

सारांश करणे

प्रकाशन तयार करण्यात मदत केल्याबद्दल मी आंद्रे बोरोडिन यांचे आभार मानू इच्छितो आणि डब्ल्यूएएल-जीच्या विकासात दिलेल्या योगदानाबद्दल त्यांचे विशेष आभार!

यावरून ही नोंद संपते. मला आशा आहे की मी सेटअपची सुलभता आणि तुमच्या कंपनीमध्ये हे साधन वापरण्याची प्रचंड क्षमता सांगू शकलो. मी WAL-G बद्दल खूप ऐकले आहे, पण बसून ते शोधण्यासाठी कधीच वेळ मिळाला नाही. आणि मी घरी ते अंमलात आणल्यानंतर, माझ्याकडून हा लेख बाहेर आला.

स्वतंत्रपणे, हे लक्षात घेण्यासारखे आहे की WAL-G खालील DBMS सह देखील कार्य करू शकते:

• मायएसQL / मारियाडीबी;
• MongoDB;
• फाउंडेशनडीबी;
• आणि वचनबद्धतेनुसार, आणखी अनेक अपेक्षित आहेत!

स्त्रोत: www.habr.com