WAL-G: სარეზერვო ასლები და PostgreSQL DBMS-ის აღდგენა

დიდი ხანია ცნობილია, რომ სარეზერვო ასლების შექმნა SQL dump-ში (გამოყენებით pg_dump ან pg_dumpall) არ არის კარგი იდეა. PostgreSQL DBMS-ის სარეზერვო ასლისთვის უმჯობესია გამოიყენოთ ბრძანება pg_basebackup, რომელიც ქმნის WAL ჟურნალების ორობით ასლს. მაგრამ როდესაც დაიწყებთ ასლის შექმნისა და აღდგენის მთელი პროცესის შესწავლას, მიხვდებით, რომ ამ მოქმედებისთვის საჭიროა დაწეროთ მინიმუმ რამდენიმე ტრიციკლი და არ შეგაწუხოთ ტკივილი როგორც ზემოთ, ასევე ქვემოთ. ტანჯვის შესამსუბუქებლად შეიქმნა WAL-G.

უოლ-ჯი არის Go-ში დაწერილი ინსტრუმენტი PostgreSQL მონაცემთა ბაზების სარეზერვო ასლის შესაქმნელად და აღდგენისთვის (და ახლახან MySQL/MariaDB, MongoDB და FoundationDB). იგი მხარს უჭერს მუშაობას Amazon S3 საცავთან (და ანალოგებთან, მაგალითად, Yandex Object Storage), ისევე როგორც Google Cloud Storage, Azure Storage, Swift Object Storage და უბრალოდ ფაილურ სისტემასთან. მთელი დაყენება მარტივი ნაბიჯებით მოდის, მაგრამ იმის გამო, რომ მის შესახებ სტატიები მიმოფანტულია ინტერნეტში, არ არსებობს სრული სახელმძღვანელო, რომელიც მოიცავს ყველა საფეხურს თავიდან ბოლომდე (არსებობს რამდენიმე პოსტი Habré-ზე, მაგრამ იქ ბევრი ქულა გამოტოვებულია).

ეს სტატია დაიწერა ძირითადად ჩემი ცოდნის სისტემატიზაციისთვის. მე არ ვარ DBA და შემიძლია სადღაც გამოვხატო საკუთარი თავი ხალხურ ენაზე, ამიტომ ნებისმიერი შესწორება მისასალმებელია!

ცალკე, მე აღვნიშნავ, რომ ყველაფერი ქვემოთ არის შესაბამისი და ტესტირება PostgreSQL 12.3-ისთვის Ubuntu 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 bucket" და წვდომის გასაღებები.

ყველა წინა სტატია 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 თაიგულისკენ, სადაც სარეზერვო ასლები აიტვირთება (შეგიძლიათ ან root-ში ან საქაღალდეში);
• AWS_ACCESS_KEY_ID - წვდომის გასაღები S3-ში (სატესტო სერვერზე აღდგენის შემთხვევაში, ამ კლავიშებს უნდა ჰქონდეს მხოლოდ წაკითხვის პოლიტიკა! ეს უფრო დეტალურად არის აღწერილი აღდგენის განყოფილებაში.);
• AWS_SECRET_ACCESS_KEY – საიდუმლო გასაღები S3 საცავში;
• WALG_COMPRESSION_METHOD – შეკუმშვის მეთოდი, უმჯობესია გამოიყენოთ ბროტლი (რადგან ეს არის ოქროს შუალედი საბოლოო ზომასა და შეკუმშვის/დეკომპრესიის სიჩქარეს შორის);
• WALG_DELTA_MAX_STEPS – „დელტას“ რაოდენობა სრული სარეზერვო ასლის შექმნამდე (ისინი დაზოგავენ დროს და გადმოწერილი მონაცემების ზომას, მაგრამ შეუძლიათ ოდნავ შეანელონ აღდგენის პროცესი, ამიტომ არ არის მიზანშეწონილი დიდი მნიშვნელობების გამოყენება);
• PGDATA – ბილიკი დირექტორიაში თქვენი მონაცემთა ბაზის მონაცემებით (ამის გარკვევა შეგიძლიათ ბრძანების გაშვებით pg_lsclusters);
• PGHOST – მონაცემთა ბაზასთან დაკავშირება, ლოკალური სარეზერვო საშუალებით უმჯობესია ამის გაკეთება unix-სოკეტის მეშვეობით, როგორც ამ მაგალითში.

სხვა პარამეტრები შეგიძლიათ იხილოთ დოკუმენტაციაში: 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 ჟურნალების ჩამოტვირთვა პარამეტრის ბრძანების გამოყენებით არქივი_ბრძანება;
• არქივი_ბრძანება – დასრულებული WAL ჟურნალის არქივის ბრძანება;
• archive_timeout - ჟურნალების დაარქივება ხორციელდება მხოლოდ დასრულების შემდეგ, მაგრამ თუ თქვენი სერვერი ცვლის/დაამატებს მცირე მონაცემებს მონაცემთა ბაზაში, მაშინ აზრი აქვს აქ ლიმიტის დაწესებას წამებში, რის შემდეგაც იძულებით გამოიძახება დაარქივების ბრძანება (ყოველ წამს ინტენსიურად ვწერ მონაცემთა ბაზაში, ამიტომ გადავწყვიტე არ დამეყენებინა ეს პარამეტრი წარმოებაში);
• restore_command – სარეზერვო ასლიდან WAL ჟურნალის აღდგენის ბრძანება გამოყენებული იქნება იმ შემთხვევაში, თუ „სრული სარეზერვო ასლი“ (ბაზის სარეზერვო ასლს) აკლია მონაცემთა ბაზაში უახლესი ცვლილებები.

ყველა ამ პარამეტრის შესახებ მეტი შეგიძლიათ წაიკითხოთ ოფიციალური დოკუმენტაციის თარგმანში: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

სარეზერვო განრიგის დაყენება

რაც არ უნდა თქვას, მისი გაშვების ყველაზე მოსახერხებელი გზაა cron. ეს არის ის, რასაც ჩვენ დავაკონფიგურირებთ სარეზერვო ასლების შესაქმნელად. დავიწყოთ სრული სარეზერვო ასლის შექმნის ბრძანებით: wal-g-ში ეს არის გაშვების არგუმენტი სარეზერვო-ბიძგი. მაგრამ პირველ რიგში, უმჯობესია ეს ბრძანება ხელით გაუშვათ postgres-ის მომხმარებლისგან, რათა დარწმუნდეთ, რომ ყველაფერი კარგად არის (და არ არის წვდომის შეცდომები):

#!/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 საათზე.

ძველი სარეზერვო ასლების წაშლა

სავარაუდოდ, თქვენ არ გჭირდებათ მეზოზოური ეპოქის აბსოლუტურად ყველა სარეზერვო ასლის შენახვა, ამიტომ სასარგებლო იქნება თქვენი მეხსიერების პერიოდულად „გასუფთავება“ (როგორც „სრული სარეზერვო ასლები“ ​​ასევე 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

Cron შეასრულებს ამ ამოცანას ყოველდღე დილის 6:30 საათზე, წაშლის ყველაფერს (სრულ სარეზერვო ასლებს, დელტას და WAL-ებს) ბოლო 10 დღის ასლების გარდა, მაგრამ დატოვებს მინიმუმ ერთ სარეზერვო ასლს. დან მითითებული თარიღი ისე, რომ ნებისმიერი წერტილი შემდეგ თარიღები ჩართული იყო PITR-ში.

აღდგენა სარეზერვოდან

საიდუმლო არ არის, რომ ჯანსაღი მონაცემთა ბაზის გასაღები არის პერიოდული აღდგენა და შიდა მონაცემების მთლიანობის შემოწმება. მე გეტყვით, თუ როგორ უნდა აღდგეს WAL-G-ის გამოყენებით ამ განყოფილებაში, ხოლო ჩეკებზე მოგვიანებით ვისაუბრებთ.

ცალკე უნდა აღინიშნოს რომ სატესტო გარემოში აღსადგენად (ყველაფერი, რაც არ არის წარმოებული) თქვენ უნდა გამოიყენოთ Read Only ანგარიში 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-ის შესახებ, მაგრამ არასდროს მქონია საკმარისი დრო, რომ დავჯდე და გამეგო. და მას შემდეგ რაც სახლში განვახორციელე, ეს სტატია გამოვიდა ჩემგან.

ცალკე, აღსანიშნავია, რომ WAL-G ასევე შეუძლია იმუშაოს შემდეგ DBMS-თან:

• MySQL / MariaDB;
• MongoDB;
• FoundationDB;
• და თუ ვიმსჯელებთ ვალდებულებების მიხედვით, კიდევ რამდენიმეა მოსალოდნელი!

წყარო: www.habr.com