ProHoster > Blog > administracja > Wprowadzenie do systemu tworzenia kopii zapasowych wal-g PostgreSQL

Wprowadzenie do systemu tworzenia kopii zapasowych wal-g PostgreSQL

WAL-G to proste i skuteczne narzędzie do tworzenia kopii zapasowych PostgreSQL w chmurach. Pod względem głównej funkcjonalności jest spadkobiercą popularnego narzędzia KRAJKA, ale przepisany w Go. Ale jest jedna ważna nowość w WAL-G - kopie delta. kopie delta WAL-G przechowuj strony plików, które uległy zmianie od czasu poprzedniej wersji kopii zapasowej. WAL-G implementuje całkiem sporo technologii do równoległego tworzenia kopii zapasowych. WAL-G jest znacznie szybszy niż WAL-E.

Szczegóły działania wal-g znajdziesz w artykule: Podkręcamy kopię zapasową. Wykład Yandexa

Protokół przechowywania S3 stał się popularny do przechowywania danych. Jedną z zalet S3 jest możliwość dostępu poprzez API, co pozwala na elastyczną interakcję z magazynem, w tym publiczny dostęp do odczytu, a aktualizacja informacji w magazynie odbywa się wyłącznie przez osoby upoważnione.

Istnieje kilka implementacji pamięci publicznych i prywatnych, które korzystają z protokołu S3. Dzisiaj przyjrzymy się popularnemu rozwiązaniu do organizacji małego przechowywania - Minio.

Pojedynczy serwer PostgreSQL jest w porządku do testowania wal-g, a Minio jest używany jako zamiennik S3.

Miniserwer

Instalacja Minia

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

Edytuj AccessKey i SecretKey w pliku /etc/minio/minio.conf

vi /etc/minio/minio.conf

Jeśli nie będziesz używać Nginx przed Minio, musisz to zmienić

--address 127.0.0.1:9000

--address 0.0.0.0:9000

Uruchomienie Minio

systemctl start minio

Przejdź do interfejsu internetowego Minio http://ip-адрес-сервера-minio:9000 i utwórz wiadro (na przykład pg-backups).

Serwer DB

WAL-G w obr./min jest montowany przeze mnie (Anton Patsev). Github, Fedora COPR.

Kto nie ma systemu opartego na RPM, skorzystaj z oficjalnego instrukcja poprzez instalację.

Oprócz pliku binarnego wal-g,rpm zawiera skrypty importujące zmienne z pliku /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

Zainstaluj Walga.

yum -y install yum-plugin-copr
yum copr enable -y antonpatsev/wal-g
yum install -y wal-g

Sprawdzam wersję wal-g.

wal-g --version
wal-g version v0.2.14

Edytuj plik /etc/wal-gd/server-s3.conf zgodnie ze swoimi potrzebami.

Pliki konfiguracyjne i pliki danych używane przez klaster bazy danych są tradycyjnie przechowywane razem w katalogu danych klastra, powszechnie nazywanym 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 # Какой метод сжатия использовать.

Konfigurując WAL-G, określasz WALG_DELTA_MAX_STEPS - liczbę kroków, w których kopia delta jest maksymalna w stosunku do podstawowej kopii zapasowej, i określasz politykę kopiowania delta. Albo tworzysz kopię z ostatniej istniejącej delty, albo tworzysz deltę z oryginalnej pełnej kopii zapasowej. Jest to konieczne w przypadku, gdy w Twojej bazie danych ciągle zmienia się ten sam element bazy danych, te same dane ulegają ciągłym zmianom.

Instalacja bazy danych.

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

Inicjujemy bazę danych.

/usr/pgsql-9.6/bin/postgresql96-setup initdb
Initializing database ... OK

Jeśli testujesz na 1 serwerze, musisz ponownie skonfigurować parametr wal_level, aby archiwizować dla PostgreSQL w wersji starszej niż 10 i replikę dla PostgreSQL w wersji 10 i starszej.

wal_level = archive

Twórzmy kopie zapasowe archiwów WAL co 60 sekund, używając samego PostgreSQL. W prodzie będziesz mieć inną wartość Archive_timeout.

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Каждые 60 секунд будет выполнятся команда archive_command.

Uruchamiam PostgreSQL

systemctl start postgresql-9.6

W osobnej konsoli przeglądamy logi PostgreSQL pod kątem błędów: (zmień postgresql-Wed.log na bieżący).

tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

Przejdźmy do psql.

su - postgres
psql

Utwórz bazę danych w psql

Utwórz tabelę w teście bazy danych1.

create database test1;

Przejdź do testu bazy danych.

postgres=# c test1;

Tworzymy tabelę indeksowanie_tabela.

test1=# CREATE TABLE indexing_table(created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW());

Dodawanie danych.

Rozpoczynamy wprowadzanie danych. Czekamy 10-20 minut.

#!/bin/bash
# postgres
while true; do
psql -U postgres -d test1 -c "INSERT INTO indexing_table(created_at) VALUES (CURRENT_TIMESTAMP);"
sleep 60;
done

Pamiętaj o wykonaniu pełnej kopii zapasowej.

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

Przeglądamy rekordy w tabeli w teście bazy danych1

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+

Ciąg oznacza bieżący czas.

Zobacz listę pełnych kopii zapasowych

/usr/local/bin/backup-list.sh

Testowanie regeneracji

Pełne odzyskiwanie z walcowaniem wszystkich dostępnych WAL.

Zatrzymaj Postgresql.

Usuń wszystko z folderu /var/lib/pgsql/9.6/data.

Uruchom skrypt /usr/local/bin/backup-fetch.sh jako użytkownik postgres.

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

Ekstrakcja kopii zapasowej została ukończona.

Dodaj plik recovery.conf do folderu /var/lib/pgsql/9.6/data z następującą zawartością.

restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'

Uruchamiamy PostgreSQL. PostgreSQL rozpocznie proces odzyskiwania ze zarchiwizowanych WAL i dopiero wtedy otworzy się baza danych. 

systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

Regeneracja przez określony czas.

Jeśli chcemy przywrócić bazę danych do określonej minuty, to do pliku recovery.conf dodajemy parametr recovery_target_time - wskazujemy, o której godzinie ma zostać przywrócona baza danych.

restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'
recovery_target_time = '2020-01-29 09:46:25'

Po odzyskaniu spójrz na tabelę indeksowanie_tabela

 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

Uruchamiamy PostgreSQL. PostgreSQL rozpocznie proces odzyskiwania ze zarchiwizowanych WAL i dopiero wtedy otworzy się baza danych. 

systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

Testowanie

Generowanie bazy danych o rozmiarze 1 GB zgodnie z opisem tutaj https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

Żądanie rozmiaru zasobnika po wygenerowaniu 1 GB danych.

postgres=# SELECT pg_size_pretty(pg_database_size('test1'));
pg_size_pretty
----------------
1003 MB

s4cmd to bezpłatne narzędzie wiersza poleceń do pracy z danymi znajdującymi się w pamięci Amazon S3. Narzędzie napisano w języku programowania Python, dzięki czemu można go używać zarówno w systemach operacyjnych Windows, jak i Linux.

Instalowanie 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

Brotli

После генерации 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

Porównanie wyników na wykresie.

Wprowadzenie do systemu tworzenia kopii zapasowych wal-g PostgreSQL

Jak widać Brotli jest porównywalny pod względem wielkości do LZMA, ale kopia zapasowa wykonywana jest w czasie LZ4.

Czat rosyjskojęzycznej społeczności PostgreSQL: https://t.me/pgsql

Jeśli korzystasz, daj gwiazdkę Githubowi wal-g

Źródło: www.habr.com

Dodaj komentarz