WAL-G: PostgreSQL DBMS को ब्याकअप र रिकभरी

यो लामो समयदेखि ज्ञात छ कि SQL डम्पहरूमा ब्याकअप बनाउने (प्रयोग गरेर pg_dump वा pg_dumpall) राम्रो विचार होइन। PostgreSQL DBMS ब्याकअप गर्न, यो आदेश प्रयोग गर्न राम्रो छ pg_basebackup, जसले WAL लगहरूको बाइनरी प्रतिलिपि बनाउँछ। तर जब तपाइँ प्रतिलिपि सिर्जना गर्ने र पुनर्स्थापना गर्ने सम्पूर्ण प्रक्रियाको अध्ययन सुरु गर्नुहुन्छ, तपाइँले यो काम गर्नको लागि कम्तिमा दुईवटा ट्राइसाइकलहरू लेख्नु आवश्यक छ र तपाइँलाई माथि र तल दुवै दुखाइ नदिने कुरा बुझ्नुहुनेछ। पीडा कम गर्न, WAL-G को विकास गरिएको थियो।

वाल-जी PostgreSQL डाटाबेसहरू ब्याकअप र पुनर्स्थापनाको लागि Go मा लेखिएको एउटा उपकरण हो (र हालसालै MySQL/MariaDB, MongoDB र FoundationDB)। यसले Amazon S3 भण्डारण (र एनालगहरू, उदाहरणका लागि, यान्डेक्स वस्तु भण्डारण), साथै Google क्लाउड भण्डारण, Azure भण्डारण, स्विफ्ट वस्तु भण्डारण र केवल फाइल प्रणालीसँग काम गर्न समर्थन गर्दछ। सम्पूर्ण सेटअप साधारण चरणहरूमा तल आउँछ, तर यस तथ्यको कारणले गर्दा यसको बारेमा लेखहरू इन्टरनेटमा छरिएका छन्, त्यहाँ कुनै पूर्ण कसरी गर्ने म्यानुअल छैन जसमा सुरुदेखि अन्त्यसम्म सबै चरणहरू समावेश हुन्छन् (हब्रेमा धेरै पोष्टहरू छन्, तर त्यहाँ धेरै बिन्दुहरू छुटेका छन्)।

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

अलग रूपमा, म नोट गर्छु कि तलका सबै सान्दर्भिक छन् र Ubuntu 12.3 मा PostgreSQL 18.04 को लागि परीक्षण गरिएको छ, सबै आदेशहरू विशेषाधिकार प्राप्त प्रयोगकर्ताको रूपमा कार्यान्वयन गरिनु पर्छ।

सेटिङ

यो लेख लेख्ने समयमा, WAL-G को स्थिर संस्करण हो v0.2.15 (मार्च 2020)। यो हामीले प्रयोग गर्नेछौं (तर यदि तपाइँ यसलाई मास्टर शाखाबाट आफैं निर्माण गर्न चाहनुहुन्छ भने, त्यसपछि github भण्डारमा यसको लागि सबै निर्देशनहरू छन्।)। डाउनलोड गर्न र स्थापना गर्न तपाईंले गर्नु पर्छ:

#!/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 फाइल postgres प्रयोगकर्ताको गृह निर्देशिकामा। यसलाई सिर्जना गर्न, निम्न bash स्क्रिप्ट चलाउनुहोस्:

#!/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 लग संग्रह गर्न आदेश;
• archive_timeout - लगहरूको अभिलेख पूरा भएपछि मात्र प्रदर्शन गरिन्छ, तर यदि तपाइँको सर्भरले डाटाबेसमा थोरै डाटा परिवर्तन गर्दछ/थप्छ भने, सेकेन्डमा यहाँ सीमा सेट गर्नुको अर्थ हुन्छ, त्यसपछि अभिलेख आदेश जबरजस्ती बोलाइनेछ (म प्रत्येक सेकेन्ड डाटाबेसमा गहन रूपमा लेख्छु, त्यसैले मैले उत्पादनमा यो प्यारामिटर सेट नगर्ने निर्णय गरें);
• restore_command - यदि "पूर्ण ब्याकअप" (आधार ब्याकअप) डाटाबेसमा भर्खरको परिवर्तनहरू नभएको खण्डमा ब्याकअपबाट WAL लग पुनर्स्थापना गर्ने आदेश प्रयोग गरिनेछ।

तपाईं आधिकारिक कागजातको अनुवादमा यी सबै प्यारामिटरहरूको बारेमा थप पढ्न सक्नुहुन्छ: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

ब्याकअप तालिका सेट अप गर्दै

जे होस्, यसलाई चलाउनको लागि सबैभन्दा सुविधाजनक तरिका क्रोन हो। यो हामी ब्याकअपहरू सिर्जना गर्न कन्फिगर गर्नेछौं। पूर्ण ब्याकअप सिर्जना गर्न आदेशको साथ सुरू गरौं: wal-g मा यो सुरुवात तर्क हो ब्याकअप-पुश। तर पहिले, यो आदेश म्यानुअल रूपमा चलाउन राम्रो छ postgres प्रयोगकर्ताबाट सबै कुरा ठीक छ भनेर सुनिश्चित गर्न (र त्यहाँ पहुँच त्रुटिहरू छैनन्):

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

यस उदाहरणमा, ब्याकअप प्रक्रिया हरेक दिन बिहान ४:१५ बजे सुरु हुन्छ।

पुराना ब्याकअपहरू मेटाउँदै

सम्भवतः, तपाईंले Mesozoic युगका सबै ब्याकअपहरू राख्न आवश्यक छैन, त्यसैले यो आवधिक रूपमा तपाईंको भण्डारण (दुवै "पूर्ण ब्याकअप" र 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 दिनका प्रतिलिपिहरू बाहेक सबै (पूर्ण ब्याकअप, डेल्टा र WALs) मेटाउने, तर कम्तिमा एउटा ब्याकअप छोडेर। गर्न निर्दिष्ट मिति ताकि कुनै पनि बिन्दु после मितिहरू PITR मा समावेश गरिएको थियो।

ब्याकअपबाट पुनर्स्थापना गर्दै

यो कुनै गोप्य कुरा छैन कि स्वस्थ डाटाबेसको कुञ्जी आवधिक पुनर्स्थापना र भित्रको डाटाको अखण्डताको प्रमाणीकरण हो। म तपाईंलाई यस खण्डमा WAL-G प्रयोग गरेर कसरी पुन: प्राप्ति गर्ने भनेर बताउनेछु, र हामी जाँचहरूको बारेमा पछि कुरा गर्नेछौं।

यो छुट्टै ध्यान दिन लायक छ जुन परीक्षण वातावरणमा पुनर्स्थापना गर्न (उत्पादन नभएको सबै कुरा) तपाईंले S3 मा पढ्ने मात्रै खाता प्रयोग गर्न आवश्यक छ ताकि गल्तिले ब्याकअपहरू अधिलेखन नगर्नुहोस्। WAL-G को मामलामा, तपाईंले समूह नीतिमा S3 प्रयोगकर्ताका लागि निम्न अधिकारहरू सेट गर्न आवश्यक छ (प्रभाव: अनुमति दिनुहोस्): s3: GetObject, s3: ListBucket, s3: GetBucketLocation। र, निस्सन्देह, सेट गर्न नबिर्सनुहोस् archive_mode=off सेटिंग्स फाइल मा 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 मा चेक चलाउन सक्नुहुन्छ)। तर न्यूनतममा, डाटाबेसमा डाटा र अनुक्रमणिकाहरू जाँच गर्न आवश्यक छ।

डाटा जाँच गर्न, यो डम्प मार्फत चलाउन पर्याप्त छ, तर यो राम्रो छ कि डाटाबेस सिर्जना गर्दा तपाईंले checksums सक्षम (डाटा चेकसमहरू):

#!/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 को बारेमा धेरै सुनेको छु, तर बस्न र यो पत्ता लगाउन पर्याप्त समय थिएन। र मैले यसलाई घरमा लागू गरेपछि, यो लेख मबाट बाहिर आयो।

अलग रूपमा, यो ध्यान दिन लायक छ कि WAL-G ले निम्न DBMS सँग पनि काम गर्न सक्छ:

• MySQL / MariaDB;
• MongoDB;
• फाउन्डेसन डीबी;
• र कमिटहरू द्वारा न्याय गर्दै, धेरै धेरै आशा गरिन्छ!

स्रोत: www.habr.com