Preambuła
Ilu obecnych użytkowników Barmana pomyślało o zapisywaniu kopii zapasowych w zdalnym miejscu docelowym w chmurze? Ile osób myślało o pobraniu kopii zapasowej bezpośrednio z samego serwera PostgreSQL?
Cóż, od czasu Barmana 2.10 jest to teraz możliwe!
Jak?
Odkryjmy to razem w kolejnych artykułach.
Wymagania
Poniższe dwa artykuły mają być praktycznym wprowadzeniem do nowego barman-cloud-wal-archive i barman-cloud-backup narzędzia dodane w barman-cli pakiet.
Pierwsza część obejmie barman-cloud-wal-archive polecenie, podczas gdy drugie obejmie barman-cloud-backup polecenie.
Czytelnicy potrzebują podstawowej wiedzy na temat metod archiwizacji i tworzenia kopii zapasowych PostgreSQL WAL oraz Barmana. Zaleca się również, aby znać technologie w chmurze dla rozwiązań pamięci masowej, takich jak Amazon S3.
Archiwum WAL
Barman od wielu lat działa jako zdalne archiwum WAL, a pakiet Barman CLI został zaprojektowany w celu zwiększenia niezawodności i niezawodności archiwizacji po stronie PostgreSQL. W rzeczywistości barman-cli udostępnia skrypty takie jak barman-wal-restore umożliwienie węzłowi rezerwowemu inteligentnego i bezpiecznego przywracania plików WAL z archiwum Barmana za pomocą restore_command parametr w postgresql.auto.conf plik (lub recovery.conf plik do PostgreSQL 12) i barman-wal-archive do archiwizacji plików WAL z węzła głównego do Barmana za pomocą archive_command parametr skonfigurowany w postgresql.conf plik.
Archiwum WAL w chmurze
Dzięki opiniom użytkowników programiści Barman wprowadzili dwa nowe narzędzia w wersji 2.10 :
barman-cloud-wal-archivebarman-cloud-backup
Wersja 2.11 będzie zawierać dwa dodatkowe narzędzia do odzyskiwania, zwane barman-cloud-wal-restore i barman-cloud-restore .
Ten post jest w całości poświęcony barman-cloud-wal-archive , który może przechowywać pliki WAL w chmurze, umożliwiając wielopoziomową archiwizację w programie Barman i rozszerzając zasady przechowywania kopii zapasowych.
W rzeczy samej, barman-cloud-wal-archive może być użyty jako skrypt przechwytujący konfigurujący pre_archive_retry_script parametr w Barman, aby skopiować pliki WAL do skonfigurowanej pamięci masowej w chmurze, zwiększając redundancję archiwum i umożliwiając wybór dłuższej polityki przechowywania niż ta Barman.
To nie wszystko!
barman-cloud-wal-archive może zastąpić barman-wal-archive polecenie w archive_command parametr, aby bezpośrednio archiwizować pliki WAL w chmurze, zamiast kopiować je na serwer Barman. W ten sposób nawet klaster PostgreSQL, który nie ma oddzielnego dedykowanego serwera kopii zapasowych, może polegać na usłudze zdalnego przechowywania w celu archiwizacji plików WAL.
Jak to działa?
Poniższe instrukcje dotyczą tylko instalacji i konfiguracji barman-cloud-wal-archive jako archive_command w PostgreSQL.
Najpierw zdecyduj, gdzie archiwizować pliki WAL. W tym artykule wykorzystamy Amazon S3, który w chwili pisania tego tekstu jest jedyną obsługiwaną technologią. Chociaż inne technologie obsługujące interfejs API podobny do S3 (Google Cloud, DigitalOcean, Microsoft Azure itp.) mogą współpracować z biblioteką boto3, nie zostały one jeszcze przetestowane.
Wymagania
- barman-cli 2.10 (lub nowszy)
- Konto Amazon AWS
- awscli
- Wiaderko S3
- Instancja PostgreSQL
W tym artykule przetestujemy Barman CLI na maszynie wirtualnej z Debian Buster i PostgreSQL 12 który jest już uruchomiony.
Instalacja
-
- Zainstaluj repozytorium publiczne drugiej kwadrantu
- Zainstaluj pakiet barman-cli
[email protected]:~# apt update [email protected]:~# apt install barman-cli
- Zainstaluj awscli
[email protected]:~# apt install awscli
Konfiguracja i konfiguracja
Przeczytajmy instrukcję:
[email protected]:~$ man barman-cloud-wal-archive [...] SYNOPSIS barman-cloud-wal-archive [OPTIONS] DESTINATION_URL SERVER_NAME WAL_PATH [...] POSITIONAL ARGUMENTS DESTINATION_URL URL of the cloud destination, such as a bucket in AWS S3. For example: s3://BUCKET_NAME/path/to/folder (where BUCKET_NAME is the bucket you have created in AWS). SERVER_NAME the name of the server as configured in Barman. WAL_PATH the value of the `%p' keyword (according to `archive_command'). [...]
Tak więc, aby poprawnie z niego korzystać, wystarczy skonfigurować poświadczenia AWS za pomocą
awsclinarzędzie jakopostgresużytkownika, kopiując klucz dostępu i klucz tajny utworzony wcześniej w sekcji IAM w konsoli AWS:[email protected]:~$ aws configure --profile barman-cloud AWS Access Key ID [None]: AKI***************** AWS Secret Access Key [None]: **************************************** Default region name [None]: eu-west-1 Default output format [None]: json
Upewnij się, że masz dostępny zasobnik S3 w AWS. Zdecydowałem się nazwać to
barman-s3-testżeby było jasne.
Powinniśmy być teraz w stanie przetestowaćbarman-cloud-wal-archivepolecenie:[email protected]:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/000000010000000000000001 [email protected]:~$ echo $? 0
Status wyjścia potwierdza, że komenda się powiodła. Możemy teraz dodać następujący wiersz na dole pliku konfiguracyjnego PostgreSQL i zrestartować instancję:
archive_mode = on[email protected]:~# systemctl restart [email protected]
Ponieważ nasze dane zostaną skopiowane do zdalnego magazynu, poza naszą kontrolą, ważne jest, abyśmy je przechowywali skompresowane i zaszyfrowane .
barman-cloud-wal-archivepolecenie obsługuje dwie różne metody kompresji:[email protected]:~$ barman-cloud-wal-archive --help [...] -z, --gzip gzip-compress the WAL while uploading to the cloud -j, --bzip2 bzip2-compress the WAL while uploading to the cloud -e ENCRYPTION, --encryption ENCRYPTION Enable server-side encryption for the transfer. Allowed values: 'AES256', 'aws:kms' [...]
Opcja szyfrowania poinformuje zasobnik S3, której metody użyć do przechowywania zaszyfrowanych danych. Zaszyfrowanych danych nie może odczytać żaden inny użytkownik AWS poza właścicielem zasobnika. Chmura Barmana nie szyfruje żadnego obiektu przed wysłaniem go do S3, po prostu prosi kubeł o przechowywanie ich w postaci zaszyfrowanej, jeśli S3 został odpowiednio skonfigurowany. Jednak wszelkie połączenia z S3 są bezpiecznie nawiązywane przez
https.Dodajmy następujący wiersz na dole
postgresql.confplik:archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'Tym razem wystarczy przeładować konfigurację, aby zastosować nowe zmiany:
[email protected]:~$ psql -c “SELECT pg_reload_conf()”
Aby sprawdzić, czy nowe polecenie archive_command działa, PostgreSQL powinien generować pliki WAL do archiwizacji, dlatego musimy wykonać trochę ruchu za pomocą
pgbenchnarzędzie:[email protected]:~$ createdb pg_bench_db [email protected]:~$ pgbench -i -s10 pg_bench_db [some irrelevant output here] [email protected]:~$ pgbench -c 10 -j 2 -T 30 pg_bench_db starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 10 query mode: simple number of clients: 10 number of threads: 2 duration: 30 s number of transactions actually processed: 84501 latency average = 3.552 ms tps = 2815.224687 (including connections establishing) tps = 2815.427535 (excluding connections establishing)
W tym momencie powinniśmy zobaczyć pliki WAL zarchiwizowane w wiadrze S3. Sprawdźmy to, budując ścieżkę docelową z nazwą serwera i katalogiem docelowym WAL:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/ PRE 0000000100000000/
Zajrzyjmy do katalogu 0000000100000000:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/0000000100000000/ 2020-01-08 08:20:54 1624168 000000010000000000000001.bz2 2020-01-08 08:21:00 293422 000000010000000000000002.bz2 2020-01-08 08:21:06 301934 000000010000000000000003.bz2 2020-01-08 08:21:11 295648 000000010000000000000004.bz2 2020-01-08 08:21:16 293675 000000010000000000000005.bz2 2020-01-08 08:21:21 299348 000000010000000000000006.bz2 2020-01-08 08:21:27 551249 000000010000000000000007.bz2 2020-01-08 08:21:33 976523 000000010000000000000008.bz2 2020-01-08 08:21:37 4542104 000000010000000000000009.bz2 2020-01-08 08:21:46 5052693 00000001000000000000000A.bz2
Świetnie!
Pliki WAL są kompresowane przed przesłaniem do zasobnika S3 i są przechowywane w postaci zaszyfrowanej, co oszczędza nam miejsce (i pieniądze) i zwiększa poziom bezpieczeństwa naszych danych.
Wnioski
barman-cloud-wal-archivepolecenie jest tym, na co użytkownicy czekali przez długi czas.Jeśli jesteś jednym z tych, którzy użyli
pre_archive_retry_scriptw celu zaimplementowania niestandardowego skryptu do przesyłania plików WAL do wiadra S3, można go użyć jako lepszego zamiennika, ponieważ jest on opracowany i utrzymywany przez programistów Barman oraz jest testowany i dostarczany przez system ciągłego dostarczania 2nd Quadrant.Jeśli jeszcze o tym nie pomyślałeś, otwierają się nowe zasady przechowywania, które mogą być dłuższe dla przechowywania w chmurze niż lokalne Barman, zwiększając wiek obiektów w chmurze, jednocześnie oszczędzając miejsce w pamięci lokalnej, poprzez odpowiednie ustawienie dłuższe zasady przechowywania w konfiguracji zasobników S3.
W przeciwnym razie można go użyć, tak jak to zrobiliśmy w tym artykule, do archiwizacji plików WAL bezpośrednio z serwera PostgreSQL. Chociaż usuwa to etap pośredni, RPO wzrost w porównaniu z metodą strumieniową, ponieważ PostgreSQL zarchiwizuje plik WAL dopiero po jego zamknięciu. Dlatego w przypadku problemów na węźle PostgreSQL możemy stracić pewne zmiany. Jeśli to możliwe, zalecamy wdrożenie tej metody wraz z przesyłaniem strumieniowym na serwer Barman, aby osiągnąć RPO=0 (z synchronicznym przesyłaniem strumieniowym).
Teraz, gdy mamy system ciągłej archiwizacji, możemy wykonać naszą pierwszą kopie zapasowe w chmurze za pomocą
barman-cloud-backupnarzędzie.Do zobaczenia w drugiej części artykułu.
