WAL-G: резервни копия и възстановяване на СУБД PostgreSQL

Отдавна е известно, че правенето на резервни копия в SQL-дампове (използвайки pg_dump или pg_dumpall) – не е най-добрата идея. За резервно копиране на бази данни PostgreSQL е по-добре да се използва командата pg_basebackup, която прави бинарно копие на WAL журналите. Но когато започнете да изучавате целия процес на създаване на копия и възстановяване, ще разберете, че трябва да напишете поне няколко триколесни велосипеда, за да може всичко да работи и да не ви причинява болка нито отгоре, нито отдолу. За да облекчи страданията, бе разработен WAL-G.

WAL-G – е инструмент, написан на Go за резервно копиране и възстановяване на бази данни PostgreSQL (а от скоро и MySQL/MariaDB, MongoDB и FoundationDB). Той поддържа работа с хранилища Amazon S3 (както и аналози, например Yandex Object Storage), както и Google Cloud Storage, Azure Storage, Swift Object Storage и просто с файловата система. Цялата настройка е сведена до прости стъпки, но поради факта, че статии за него са разпръснати из интернет – няма пълен how-to наръчник, който да включва всички стъпки от начало до край (в Хабра има няколко поста, но много моменти са пропуснати).

Тази статия е написана преди всичко, за да систематизира моите знания. Не съм DBA и затова някъде може да се изразявам с по-обикновен разработческо език, затова всички корекции са добре дошли!

Отделно ще подчертая, че всичко по-долу е актуално и проверено за PostgreSQL 12.3 на Ubuntu 18.04, всички команди трябва да се изпълняват от привилегирован потребител.

Инсталиране на

В момента на написването на тази статия стабилната версия на WAL-G е v0.2.15 (март 2020). Ние ще я използваме (но ако искате да я компилирате сами от master бранча, в репото на 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 (при възстановяване на тестов сървър – тези ключове трябва да имат ReadOnly Policy! Подробности са написани в раздела за възстановяване);
• AWS_SECRET_ACCESS_KEY – таен ключ за хранилището S3;
• WALG_COMPRESSION_METHOD – метод на компресия, най-добре е да се използва Brotli (тъй като е златна среда между окончателния размер и скоростта на компресиране/разкомпресиране);
• WALG_DELTA_MAX_STEPS – брой «дельти» преди създаването на пълно резервно копие (позволяват да се спести време и размер на качените данни, но могат малко да забавят процеса на възстановяване, затова не е желателно да се използват големи стойности);
• PGDATA – пътят към директорията с данните на вашата база (може да бъде получен чрез изпълнение на командата pg_lsclusters);
• PGHOST – свързване с базата, при локално резервно копие е най-добре да се прави чрез Unix socket, както в този пример.

Останалите параметри могат да бъдат намерени в документацията: https://github.com/wal-g/wal-g/blob/v0.2.15/PostgreSQL.md#configuration.

Настройка на PostgreSQL

За да архиваторът в базата сам качва WAL журнали в облака и да се възстановява от тях (в случай на нужда) – трябва да зададете няколко параметъра в конфигурационния файл /etc/postgresql/12/main/postgresql.conf. Просто първо трябва да се уверите, че никои от следващите настройки не са зададени на други стойности, за да не се срине СУБД при презареждане на конфигурацията. Добавете тези параметри с помощта на:

#!/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 журналите, „replica“ – записвайте всичко;
• archive_mode – активиране на качването на WAL журналите с команда от параметъра archive_command;
• archive_command – команда за архивиране на завършен WAL журнал;
• archive_timeout – архивирането на журналите се извършва само когато той е завършен, но ако вашият сървър рядко променя/добавя данни в базата, има смисъл да зададете лимит в секунди, след което архивиращата команда ще бъде извикана принудително (имам интензивно записване в базата всяка секунда, затова се отказах от задаване на този параметър в продукция);
• restore_command – команда за възстановяване на WAL журнал от резервно копие, ще се използва, ако в „пълното резервно копие“ (base backup) липсват последните изменения в базата.

Повече за всички тези параметри можете да прочетете в превода на официалната документация: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

Настройка на графика за резервно копиране

Каквото и да кажем, най-удобният начин за стартиране е cron. Именно него ще настроим за създаване на резервни копия. Нека започнем с командата за създаване на пълен бекъп: в wal-g това е аргумент за стартиране backup-push. Но за начало е по-добре да изпълните тази команда ръчно от потребителя 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 журнали). Ще направим всичко това също през cron задача:

#!/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 Group Policy (Effect: Allow): 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

За тези, които искат да проверят процеса на възстановяване — по-долу е подготвен малък фрагмент от bash-магия, така че при проблеми с възстановяването скриптът да излезе с ненулев exit код. В този пример се извършват 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). Но поне трябва да се проверяват данните и индексите в базата.

За проверка на данните е достатъчно да ги пропуснете през дампа, но е по-добре при създаване на базата да имате включени контролните суми (data 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 може да работи и с следните СУБД:

• MySQL/MariaDB;
• MongoDB;
• FoundationDB;
• И съдейки по комитите – се очакват още няколко!

Източник: habr.com