wal-g PostgreSQL სარეზერვო სისტემის შესავალი

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

დეტალები, თუ როგორ მუშაობს wal-g, შეგიძლიათ იხილოთ სტატიაში: ჩვენ გადატვირთავთ სარეზერვო ასლს. Yandex-ის ლექცია

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

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

ერთი PostgreSQL სერვერი კარგია wal-g-ის შესამოწმებლად, ხოლო Minio გამოიყენება S3-ის შემცვლელად.

Minio სერვერი

მინიოს ინსტალაცია

yum -y install yum-plugin-copr
yum copr enable -y lkiesow/minio
yum install -y minio

შეცვალეთ AccessKey და SecretKey-ში /etc/minio/minio.conf

vi /etc/minio/minio.conf

თუ თქვენ არ იყენებთ nginx-ს Minio-მდე, მაშინ უნდა შეცვალოთ

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Minio-ს გაშვება

systemctl start minio

გადადით Minio ვებ ინტერფეისზე http://ip-адрес-сервера-minio:9000 და შექმენით bucket (მაგალითად, pg-backups).

DB სერვერი

WAL-G ბრუნში აწყობილია ჩემი (ანტონ ფაცევი). Github, Fedora COPR.

ვისაც არ აქვს 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

დააინსტალირეთ walg.

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 სერვერზე, მაშინ ხელახლა უნდა დააკონფიგურიროთ wal_level პარამეტრი, რათა დაარქივოთ PostgreSQL 10-ზე ნაკლები ვერსიისთვის და ასლი PostgreSQL 10 და უფრო ძველი ვერსიისთვის.

wal_level = archive

მოდით შევქმნათ სარეზერვო WAL არქივები ყოველ 60 წამში, თავად PostgreSQL-ის გამოყენებით. პროდზე გექნებათ განსხვავებული 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 საქაღალდიდან.

გაუშვით /usr/local/bin/backup-fetch.sh სკრიპტი, როგორც პოსტგრესის მომხმარებელი.

su - postgres
/usr/local/bin/backup-fetch.sh

სარეზერვო მოპოვება დასრულდა.

დაამატეთ recovery.conf საქაღალდეში /var/lib/pgsql/9.6/data შემდეგი შინაარსით.

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

ტესტირება

1 GB მონაცემთა ბაზის გენერირება, როგორც ეს აღწერილია აქ https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

თაიგულის ზომის მოთხოვნა 1 გბ მონაცემთა გენერირების შემდეგ.

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

შედეგების შედარება დიაგრამაზე.

როგორც ხედავთ, ბროტლი ზომით შედარებულია LZMA-სთან, მაგრამ სარეზერვო ასლი შესრულებულია LZ4 დროში.

რუსულენოვანი PostgreSQL საზოგადოების ჩატი: https://t.me/pgsql

გთხოვთ, მიეცით ვარსკვლავი Github-ს, თუ იყენებთ უოლ-გ

წყარო: www.habr.com