WAL-G: PostgreSQL DBMS 백업 및 복구

SQL 덤프로 백업을 만드는 것은 오랫동안 알려져 왔습니다. pg_dump 또는 pg_dumpall) 좋은 생각이 아닙니다. PostgreSQL DBMS를 백업하려면 다음 명령을 사용하는 것이 좋습니다. pg_basebackup, WAL 로그의 바이너리 복사본을 만듭니다. 그러나 복사본을 만들고 복원하는 전체 과정을 연구하기 시작하면 이것이 작동하고 위아래 모두 고통을 유발하지 않으려면 최소한 두 개의 세발 자전거를 작성해야한다는 것을 이해하게 될 것입니다. 고통을 완화하기 위해 WAL-G가 개발되었습니다.

월지 PostgreSQL 데이터베이스를 백업하고 복원하기 위해 Go로 작성된 도구입니다(그리고 최근에는 MySQL/MariaDB, MongoDB 및 FoundationDB). Amazon S3 스토리지(및 Yandex Object Storage와 같은 유사 제품)는 물론 Google Cloud Storage, Azure Storage, Swift Object Storage 및 간단한 파일 시스템 작업을 지원합니다. 전체 설정은 간단한 단계로 이루어지지만 이에 대한 기사가 인터넷에 흩어져 있기 때문에 처음부터 끝까지 모든 단계를 포함하는 완전한 사용 설명서가 없습니다. (Habré에 여러 게시물이 있습니다. 그러나 거기에는 많은 점이 빠졌습니다).

이 글은 주로 제가 알고 있는 지식을 체계화하기 위해 작성되었습니다. 저는 DBA가 아니며 어딘가에서 일반인의 언어로 표현할 수 있으므로 어떤 수정이라도 환영합니다!

이와 별도로, 아래의 모든 내용은 Ubuntu 12.3의 PostgreSQL 18.04과 관련이 있으며 테스트되었으며 모든 명령은 권한 있는 사용자로 실행되어야 합니다.

설치

이 기사를 작성하는 시점에서 WAL-G의 안정 버전은 다음과 같습니다. v0.2.15 (2020년 XNUMX월). 이것이 우리가 사용할 것입니다 (하지만 마스터 브랜치에서 직접 빌드하려면 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 정책이 있어야 합니다! 이에 대해서는 복구 섹션에서 자세히 설명합니다.);
• AWS_SECRET_ACCESS_KEY – S3 저장소의 비밀 키
• WALG_COMPRESSION_METHOD – 압축 방법, Brotli를 사용하는 것이 더 좋습니다(이것이 최종 크기와 압축/압축 해제 속도 사이의 황금 평균이기 때문입니다).
• WALG_DELTA_MAX_STEPS – 전체 백업을 생성하기 전의 "델타" 수(다운로드한 데이터의 시간과 크기를 절약하지만 복구 프로세스가 약간 느려질 수 있으므로 큰 값을 사용하는 것은 바람직하지 않습니다)
• PG데이터 – 데이터베이스 데이터가 있는 디렉터리 경로(명령을 실행하여 알 수 있습니다 pg_lsclusters);
• 유령 – 데이터베이스에 연결하려면 로컬 백업을 사용하여 이 예와 같이 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 로그에 쓸 정보의 양, "replica" – 모든 것을 씁니다.
• 아카이브_모드 – 매개변수의 명령을 사용하여 WAL 로그 다운로드를 활성화합니다. 아카이브 명령;
• 아카이브 명령 – 완성된 WAL 로그를 보관하는 명령;
• archive_timeout – 로그 보관은 완료된 경우에만 수행되지만 서버가 데이터베이스에 약간의 데이터를 변경/추가하는 경우 여기에서 초 단위로 제한을 설정하는 것이 합리적이며 그 후에 보관 명령이 강제로 호출됩니다(매초 데이터베이스에 집중적으로 쓰기 때문에 프로덕션에서는 이 매개변수를 설정하지 않기로 결정했습니다.);
• 복원 명령 – "전체 백업"(기본 백업)에 데이터베이스의 최신 변경 사항이 없는 경우 백업에서 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 로그 모두)를 주기적으로 "정리"하는 것이 유용할 것입니다. 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분에 이 작업을 실행하여 지난 10일 동안의 복사본을 제외한 모든 항목(전체 백업, 델타 및 WAL)을 삭제하지만 하나 이상의 백업은 남겨둡니다. 에 특정 날짜에 어떤 지점이라도 후 날짜가 PITR에 포함되었습니다.

백업에서 복원

건강한 데이터베이스의 핵심은 내부 데이터의 무결성을 주기적으로 복원하고 확인하는 것입니다. 이 섹션에서는 WAL-G를 사용하여 복구하는 방법을 설명하고 나중에 확인 사항에 대해 설명하겠습니다.

따로 따로 주목할만한 가치 테스트 환경(프로덕션이 아닌 모든 것)에서 복원하려면 실수로 백업을 덮어쓰지 않도록 S3에서 읽기 전용 계정을 사용해야 합니다. WAL-G의 경우 그룹 정책(그룹 정책)에서 S3 사용자에 대해 다음 권한을 설정해야 합니다.효과: 허용): s3:GetObject, s3:리스트버킷, 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

복구 프로세스를 확인하려는 분들을 위해 아래에 작은 bash 매직 조각이 준비되어 있으므로 복구에 문제가 있을 경우 120이 아닌 종료 코드로 스크립트가 충돌합니다. 이 예에서는 신호 파일이 삭제되었는지 여부를 확인하기 위해 5초의 시간 초과(복구에 총 10분)를 사용하여 XNUMX개의 검사가 수행되었습니다(이는 복구가 성공했음을 의미함).

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

요약

출판물을 준비하는 데 도움을 준 Andrey Borodin에게 감사의 말씀을 전하고 WAL-G 개발에 기여한 데 특별한 감사를 표하고 싶습니다!

이것으로 이 노트를 마칩니다. 설정이 간편하고 회사에서 이 도구를 사용할 수 있는 엄청난 잠재력을 전달할 수 있었으면 좋겠습니다. 나는 WAL-G에 대해 많이 들었지만 앉아서 알아낼 시간이 충분하지 않았습니다. 그리고 집에서 구현해본 결과 이런 글이 나왔어요.

이와 별도로 WAL-G가 다음 DBMS에서도 작동할 수 있다는 점은 주목할 가치가 있습니다.

• MySQL / MariaDB;
• MongoDB의;
• 파운데이션DB;
• 그리고 커밋으로 판단하면 몇 가지가 더 있을 것으로 예상됩니다!

출처 : habr.com