wal-g의 작동 방식에 대한 자세한 내용은 다음 기사에서 확인할 수 있습니다.
S3 스토리지 프로토콜은 데이터 저장에 널리 사용됩니다. S3의 장점 중 하나는 API를 통해 액세스할 수 있다는 것입니다. 이를 통해 공개 읽기 액세스를 포함하여 스토리지와의 유연한 상호 작용을 구성할 수 있으며 스토리지의 정보 업데이트는 권한 있는 사람만 수행할 수 있습니다.
S3 프로토콜을 사용하는 여러 공용 및 개인 저장소 구현이 있습니다. 오늘은 소규모 스토리지 정리를 위한 인기 있는 솔루션인 Minio를 살펴보겠습니다.
wal-g 테스트에는 단일 PostgreSQL 서버가 적합하며 S3 대신 Minio가 사용됩니다.
미니오 서버
미니오 설치
yum -y install yum-plugin-copr
yum copr enable -y lkiesow/minio
yum install -y minio
/etc/minio/minio.conf에서 AccessKey 및 SecretKey를 편집하세요.
vi /etc/minio/minio.conf
Minio 이전에 nginx를 사용하지 않으려면 변경해야 합니다.
--address 127.0.0.1:9000
--address 0.0.0.0:9000
미니오 출시
systemctl start minio
Minio 웹 인터페이스로 이동
DB 서버
rpm 단위의 WAL-G는 나(Anton Patsev)가 조립했습니다.
RPM 기반 시스템이 없는 분들은 공식 시스템을 이용하세요.
wal-g 바이너리와 함께 rpm에는 /etc/wal-gd/server-s3.conf 파일에서 변수를 가져오는 스크립트가 포함되어 있습니다.
backup-fetch.sh
backup-list.sh
backup-push.sh
wal-fetch.sh
wal-g-run.sh
wal-push.sh
월그를 설치합니다.
yum -y install yum-plugin-copr
yum copr enable -y antonpatsev/wal-g
yum install -y wal-g
wal-g 버전을 확인하는 중입니다.
wal-g --version
wal-g version v0.2.14
필요에 맞게 /etc/wal-gd/server-s3.conf를 편집합니다.
데이터베이스 클러스터에서 사용하는 구성 파일과 데이터 파일은 일반적으로 클러스터 데이터 디렉터리에 함께 저장됩니다. PGDATA
#!/bin/bash
export PG_VER="9.6"
export WALE_S3_PREFIX="s3://pg-backups" # бакет, который мы создали в S3
export AWS_ACCESS_KEY_ID="xxxx" # AccessKey из /etc/minio/minio.conf
export AWS_ENDPOINT="http://ip-адрес-сервера-minio:9000"
export AWS_S3_FORCE_PATH_STYLE="true"
export AWS_SECRET_ACCESS_KEY="yyyy" # SecretKey из /etc/minio/minio.conf
export PGDATA=/var/lib/pgsql/$PG_VER/data/
export PGHOST=/var/run/postgresql/.s.PGSQL.5432 # Сокет для подключения к PostgreSQL
export WALG_UPLOAD_CONCURRENCY=2 # Кол-во потоков для закачки
export WALG_DOWNLOAD_CONCURRENCY=2 # Кол-во потоков для скачивания
export WALG_UPLOAD_DISK_CONCURRENCY=2 # Кол-во потоков на диске для закачки
export WALG_DELTA_MAX_STEPS=7
export WALG_COMPRESSION_METHOD=brotli # Какой метод сжатия использовать.
WAL-G를 구성할 때 기본 백업에서 델타 백업이 최대 단계 수인 WALG_DELTA_MAX_STEPS를 지정하고 델타 복사 정책을 지정합니다. 마지막 기존 델타에서 복사본을 만들거나 원본 전체 백업에서 델타를 만듭니다. 이는 데이터베이스의 동일한 구성 요소가 데이터베이스에서 항상 변경되고 동일한 데이터가 지속적으로 변경되는 경우에 필요합니다.
데이터베이스를 설치 중입니다.
yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.
noarch.rpm
yum install -y postgresql96 postgresql96-server mc
데이터베이스를 초기화해 보겠습니다.
/usr/pgsql-9.6/bin/postgresql96-setup initdb
Initializing database ... OK
1개의 서버에서 테스트하는 경우 버전 10 미만의 PostgreSQL에 대해 아카이브하고 PostgreSQL 버전 10 이하에 대한 복제본을 보관하도록 wal_level 매개변수를 재구성해야 합니다.
wal_level = archive
PostgreSQL 자체를 사용하여 60초마다 WAL 아카이브를 백업해 보겠습니다. prod에서는 다른 archive_timeout 값을 갖게 됩니다.
archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Каждые 60 секунд будет выполнятся команда archive_command.
PostgreSQL을 시작해보자
systemctl start postgresql-9.6
별도의 콘솔에서 PostgreSQL 로그에서 오류를 확인합니다. (postgresql-Wed.log를 현재 로그로 변경)
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log
psql로 가보자.
su - postgres
psql
psql에서 데이터베이스 생성
데이터베이스 test1에 테이블을 만듭니다.
create database test1;
데이터베이스 테스트로 전환합니다.
postgres=# c test1;
indexing_table 테이블을 생성합니다.
test1=# CREATE TABLE indexing_table(created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW());
데이터를 추가합니다.
데이터 삽입을 시작합니다. 우리는 10-20 분을 기다리고 있습니다.
#!/bin/bash
# postgres
while true; do
psql -U postgres -d test1 -c "INSERT INTO indexing_table(created_at) VALUES (CURRENT_TIMESTAMP);"
sleep 60;
done
반드시 전체 백업을 하시기 바랍니다.
su - postgres
/usr/local/bin/backup-push.sh
test1 데이터베이스의 테이블에 있는 항목을 살펴봅니다.
select * from indexing_table;
2020-01-29 09:41:25.226198+
2020-01-29 09:42:25.336989+
2020-01-29 09:43:25.356069+
2020-01-29 09:44:25.37381+
2020-01-29 09:45:25.392944+
2020-01-29 09:46:25.412327+
2020-01-29 09:47:25.432564+
2020-01-29 09:48:25.451985+
2020-01-29 09:49:25.472653+
2020-01-29 09:50:25.491974+
2020-01-29 09:51:25.510178+
문자열은 현재 시간입니다.
전체 백업 목록 보기
/usr/local/bin/backup-list.sh
복구 테스트
사용 가능한 모든 WAL을 롤링하여 전체 복구.
PostgreSQL을 중지합니다.
/var/lib/pgsql/9.6/data 폴더에서 모든 항목을 삭제합니다.
postgres 사용자로 /usr/local/bin/backup-fetch.sh 스크립트를 실행합니다.
su - postgres
/usr/local/bin/backup-fetch.sh
백업 추출이 완료되었습니다.
다음 내용으로 /var/lib/pgsql/9.6/data 폴더에 Recovery.conf를 추가합니다.
restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'
PostgreSQL을 시작합니다. PostgreSQL은 보관된 WAL에서 복구 프로세스를 시작한 다음 데이터베이스를 엽니다.
systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log
일정 시간 동안 회복됩니다.
특정 분까지 데이터베이스를 복원하려면 Recovery.conf에 Recovery_target_time 매개변수를 추가합니다. 즉, 데이터베이스를 복원할 시간을 나타냅니다.
restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'
recovery_target_time = '2020-01-29 09:46:25'
복구 후 indexing_table 테이블을 살펴보세요.
2020-01-29 09:41:25.226198+00
2020-01-29 09:42:25.336989+00
2020-01-29 09:43:25.356069+00
2020-01-29 09:44:25.37381+00
2020-01-29 09:45:25.392944+00
PostgreSQL을 시작합니다. PostgreSQL은 보관된 WAL에서 복구 프로세스를 시작한 다음 데이터베이스를 엽니다.
systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log
테스트
여기에 설명된 대로 1GB 데이터베이스 생성
1GB의 데이터를 생성한 후 버킷 크기를 요청합니다.
postgres=# SELECT pg_size_pretty(pg_database_size('test1'));
pg_size_pretty
----------------
1003 MB
s4cmd는 Amazon S3 스토리지에 있는 데이터 작업을 위한 무료 명령줄 도구입니다. 이 유틸리티는 Python 프로그래밍 언어로 작성되었으므로 Windows 및 Linux 운영 체제 모두에서 사용할 수 있습니다.
s4cmd 설치
pip install s4cmd
LZ4
s4cmd --endpoint-url=http://ip-адрес-сервера-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822 s3://pg-backups/wal_005/
840 МБ в формате lz4 только WAL логов
Полный бекап с lz4 - 1GB данных
time backup_push.sh
real 0m18.582s
Размер S3 бакета после полного бекапа
581480085 s3://pg-backups/basebackups_005/
842374424 s3://pg-backups/wal_005
581 МБ занимает полный бекап
LZMA
После генерации 1ГБ данных
338413694 s3://pg-backups/wal_005/
338 мб логов в формате lzma
Время генерации полного бекапа
time backup_push.sh
real 5m25.054s
Размер бакета в S3
270310495 s3://pg-backups/basebackups_005/
433485092 s3://pg-backups/wal_005/
270 мб занимает полный бекап в формате lzma
브로 틀리
После генерации 1ГБ данных
459229886 s3://pg-backups/wal_005/
459 мб логов в формате brotli
Время генерации полного бекапа
real 0m23.408s
Размер бакета в S3
312960942 s3://pg-backups/basebackups_005/
459309262 s3://pg-backups/wal_005/
312 мб занимает полный бекап в формате brotli
차트의 결과를 비교합니다.
보시다시피 Brotli는 크기가 LZMA와 비슷하지만 백업은 LZ4 시간에 수행됩니다.
러시아어를 사용하는 PostgreSQL 커뮤니티 채팅:
사용하시는 경우 Github에 별표를 남겨주세요
출처 : habr.com