Tworzenie konfiguracji replikacji PostgreSQL na Debianie / Ubuntu

PostgreSQL może działać oddzielnie na wielu maszynach z tą samą strukturą danych, dzięki czemu warstwa trwałości aplikacji jest bardziej odporna i przygotowana na nieoczekiwane zdarzenia, które mogą zagrozić ciągłości usługi.

Ideą tego jest poprawienie czasu odpowiedzi systemu poprzez dystrybucję żądań w sieci „Round Robin”, w której każdy obecny węzeł jest klastrem. W tego typu konfiguracji nie jest ważne, który z żądań zostanie dostarczony do przetworzenia, ponieważ odpowiedź będzie zawsze taka sama.

W tym blogu wyjaśnimy, jak replikować klaster PostgreSQL przy użyciu narzędzi dostarczonych w instalacji programu. Używana wersja to PostgreSQL 11.5, aktualna stabilna, ogólnie dostępna wersja dla systemu operacyjnego Debian Buster. W przypadku przykładów na tym blogu zakłada się, że znasz już Linuksa.

Programy PostgreSQL

W katalogu /usr/bin/ znajduje się program odpowiedzialny za zarządzanie klastrem.

# 1. Lists the files contained in the directory
# 2. Filters the elements that contain 'pg_' in the name
ls /usr/bin/ | grep pg_

Działania prowadzone za pośrednictwem tych programów mogą być wykonywane sekwencyjnie lub nawet w połączeniu z innymi programami. Uruchamianie bloku tych czynności za pomocą jednego polecenia jest możliwe dzięki programowi dla systemu Linux znajdującemu się w tym samym katalogu o nazwie make.

Aby wyświetlić listę obecnych klastrów, użyj programu pg_lsclusters. Możesz również użyć make, aby go uruchomić. Jego działanie zależy od pliku o nazwie Makefile, który musi znajdować się w tym samym katalogu, w którym zostanie uruchomione polecenie.

# 1. The current directory is checked
pwd

# 2. Creates a directory
mkdir ~/Documents/Severalnines/

# 3. Enroute to the chosen directory
cd ~/Documents/Severalnines/

# 4. Create the file Makefile
touch Makefile

# 5. Open the file for editing

Definicja bloku jest pokazana poniżej, mająca jako nazwę ls i pojedynczy program do uruchomienia, pg_lsclusters.

# 1. Block name
ls:
# 2. Program to be executed
pg_lsclusters

Plik Makefile może zawierać wiele bloków, a każdy z nich może uruchamiać tyle programów, ile potrzebujesz, a nawet odbierać parametry. Konieczne jest, aby wiersze należące do bloku wykonania były poprawne, używając tabulacji do wcięć zamiast spacji.

Korzystanie z make do uruchomienia programu pg_lsclusters odbywa się za pomocą polecenia make ls.

# 1. Executes pg_lsclusters
make ls

Wynik uzyskany w ostatniej instalacji PostgreSQL daje pojedynczy klaster o nazwie main, przydzielony na porcie 5432 systemu operacyjnego. Kiedy używany jest program pg_createcluster, nowy port jest przydzielany do nowo utworzonego klastra z wartością 5432 jako punktem początkowym, dopóki nie zostanie znaleziony inny w kolejności rosnącej.

Zapis z wyprzedzeniem (WAL)

Ta procedura replikacji polega na wykonaniu kopii zapasowej działającego klastra, który nadal otrzymuje aktualizacje. Jeśli jednak odbywa się to na tej samej maszynie, wiele korzyści płynących z tej techniki zostanie utraconych.

Skalowanie systemu w poziomie zapewnia większą dostępność usługi, ponieważ w przypadku wystąpienia jakichkolwiek problemów sprzętowych nie miałoby to większego znaczenia, ponieważ istnieją inne maszyny gotowe do podjęcia pracy.

WAL to termin używany do reprezentowania wewnętrznego złożonego algorytmu PostgreSQL, który zapewnia integralność transakcji dokonywanych w systemie. Jednak tylko jeden klaster musi być odpowiedzialny za dostęp do niego z uprawnieniami do zapisu.

Architektura ma teraz trzy różne typy klastrów:

Główny odpowiedzialny za pisanie do WAL;
Replika gotowa do przejęcia głównego stanowiska;
Różne inne repliki z funkcją odczytu WAL.

Operacje zapisu to wszelkie czynności, które mają na celu modyfikację struktury danych, poprzez wprowadzanie nowych elementów lub aktualizowanie i usuwanie istniejących rekordów.

Konfiguracja klastra PostgreSQL

Każdy klaster ma dwa katalogi, jeden zawierający pliki konfiguracyjne, a drugi z dziennikami transakcji. Znajdują się one odpowiednio w /etc/postgresql/11/$(cluster) i /var/lib/postgresql/11/$(cluster) (gdzie $(cluster) to nazwa klastra).

Plik postgresql.conf jest tworzony natychmiast po utworzeniu klastra przez uruchomienie programu pg_createcluster, a właściwości można modyfikować w celu dostosowania klastra.

Bezpośrednia edycja tego pliku nie jest zalecana, ponieważ zawiera prawie wszystkie właściwości. Ich wartości zostały zakomentowane, mają symbol # na początku każdego wiersza, a kilka innych wierszy zostało zakomentowanych, zawierających instrukcje dotyczące zmiany wartości właściwości.

Dodanie kolejnego pliku zawierającego żądane zmiany jest możliwe, wystarczy edytować pojedynczą właściwość o nazwie include, zastępując domyślną wartość #include =‘’ na include =‘postgresql.replication.conf’.

Przed uruchomieniem klastra potrzebna jest obecność pliku postgresql.replication.conf w tym samym katalogu, w którym znajduje się oryginalny plik konfiguracyjny o nazwie postgresql.conf.

# 1. Block name
create:
# 2. Creates the cluster
pg_createcluster 11 $(cluster) -- --data-checksums
# 3. Copies the file to the directory
cp postgresql.replication.conf /etc/postgresql/11/$(cluster)/
# 4. A value is assigned to the property
sed -i "s|^#include = ''|include = 'postgresql.replication.conf'|g" /etc/postgresql/11/$(cluster)/postgresql.conf

Użycie --data-checksums w tworzeniu klastra dodaje wyższy poziom integralności danych, co kosztuje trochę wydajności, ale jest bardzo ważne, aby uniknąć uszkodzenia plików, gdy przeniesione z jednego klastra do drugiego.

Procedury opisane powyżej można ponownie wykorzystać w innych klastrach, po prostu przekazując wartość do $(cluster) jako parametr podczas wykonywania programu make.

# 1. Executes the block 'create' by passing a parameter
sudo make create cluster=primary

Teraz, gdy ustalono krótką automatyzację zadań, pozostaje do zrobienia definicja pliku postgresql.replication.conf zgodnie z potrzebami każdego klastra.

Replikacja w PostgreSQL

Możliwe są dwa sposoby replikacji klastra, z których jeden jest kompletny, drugi obejmujący cały klaster (nazywany replikacją strumieniową), a drugi może być częściowy lub kompletny (nazywany replikacją logiczną).

Ustawienia, które należy określić dla klastra, dzielą się na cztery główne kategorie:

Serwer główny
Serwery w stanie gotowości
Serwery wysyłające
Abonenci

Jak widzieliśmy wcześniej, WAL to plik, który zawiera transakcje dokonywane w klastrze, a replikacja to transmisja tych plików z jednego klastra do drugiego.

Wewnątrz ustawień obecnych w pliku postgresql.conf możemy zobaczyć właściwości, które definiują zachowanie klastra w odniesieniu do plików WAL, takie jak rozmiar tych plików.

# default values
max_wal_size = 1GB
min_wal_size = 80MB

Kolejna ważna właściwość o nazwie max_wal_senders. Przynależność do klastra z charakterystycznymi Serwerami Wysyłającymi to ilość procesów odpowiedzialnych za wysyłanie tych plików do innych klastrów, która zawsze musi mieć wartość większą niż liczba klastrów zależna od ich odbioru.

Pliki WAL mogą być przechowywane w celu przesłania do klastra, który łączy się późno lub miał problemy z ich odebraniem i potrzebuje poprzednich plików w odniesieniu do aktualnego czasu, mając jako specyfikację właściwość wal_keep_segments ile segmentów plików WAL ma być utrzymywanych przez klaster.

Gniazdo replikacji to funkcja, która umożliwia klastrowi przechowywanie plików WAL potrzebnych do udostępnienia innemu klasterowi wszystkich rekordów, mając jako właściwość opcję max_replication_slots.

# default values
max_wal_senders = 10
wal_keep_segments = 0
max_replication_slots = 10

Gdy zamiarem jest zlecenie przechowywania tych plików WAL na zewnątrz, można zastosować inną metodę przetwarzania tych plików, zwaną ciągłą archiwizacją.

Ciągła archiwizacja

Ta koncepcja umożliwia skierowanie plików WAL do określonej lokalizacji za pomocą programu Linux i dwóch zmiennych reprezentujących ścieżkę do pliku i jego nazwę, taką jak %p i %f, odpowiednio.

Ta właściwość jest domyślnie wyłączona, ale jej użycie można łatwo zaimplementować, wycofując odpowiedzialność klastra z przechowywania tak ważnych plików i można ją dodać do pliku postgresql.replication.conf.

# 1. Creates a directory
mkdir ~/Documents/Severalnines/Archiving

# 2. Implementation on postgresql.replication.conf
archive_mode = on
archive_command = 'cp %p ~/Documents/Severalnines/Archiving/%f'

# 3. Starts the cluster
sudo systemctl start [email protected]

Po zainicjowaniu klastra niektóre właściwości mogą wymagać modyfikacji i może być wymagane ponowne uruchomienie klastra. Jednak niektóre właściwości można ponownie załadować, bez konieczności pełnego ponownego uruchomienia klastra.

Informacje na takie tematy można uzyskać za pośrednictwem komentarzy znajdujących się w pliku postgresql.conf, pojawiających się jako # (uwaga:zmiana wymaga ponownego uruchomienia).

Jeśli tak jest, prostym sposobem rozwiązania tego problemu jest użycie programu systemctl dla systemu Linux, używanego wcześniej do uruchomienia klastra, przy czym wystarczy pominąć opcję ponownego uruchomienia.

Gdy pełne ponowne uruchomienie nie jest wymagane, sam klaster może ponownie przypisać swoje właściwości za pomocą zapytania uruchomionego w sobie, jednak jeśli wiele klastrów działa na tej samej maszynie, konieczne będzie przekazanie parametru zawierający wartość portu, który klaster jest przydzielony w systemie operacyjnym.

# Reload without restarting
sudo -H -u postgres psql -c ‘SELECT pg_reload_conf();’ -p 5433

W powyższym przykładzie właściwość archive_mode wymaga ponownego uruchomienia, podczas gdy archive_command nie. Po tym krótkim wprowadzeniu do tego tematu, przyjrzyjmy się, jak klaster replik może wykonać kopię zapasową tych zarchiwizowanych plików WAL przy użyciu funkcji Point In Time Recovery (PITR).

Odzyskiwanie replikacji PostgreSQL do punktu w czasie

Ta sugestywna nazwa umożliwia klastrowi powrót do stanu z określonego okresu. Odbywa się to za pomocą właściwości o nazwie recovery_target_timeline, która oczekuje na otrzymanie wartości w formacie daty, takim jak 2019-08-22 12:05 GMT, lub przypisania najpóźniej, informując o potrzebie odzyskania do ostatniego istniejącego rekordu.

Program pg_basebackup po uruchomieniu tworzy kopię katalogu zawierającego dane z klastra do innej lokalizacji. Ten program ma tendencję do odbierania wielu parametrów, jednym z nich jest -R, który tworzy plik o nazwie recovery.conf w skopiowanym katalogu, który z kolei nie jest taki sam, jak ten, który zawiera inne wcześniej widziane pliki konfiguracyjne, takie jak postgresql.conf .

Plik recovery.conf przechowuje parametry przekazane podczas wykonywania programu pg_basebackup, a jego istnienie ma zasadnicze znaczenie dla implementacji Streaming Replication, ponieważ to w nim można wykonać operację odwrotną do Continuous Archiving być wykonywane.

# 1. Block name
replicate:
# 2. Removes the current data directory
rm -rf /var/lib/postgresql/11/$(replica)
# 3. Connects to primary cluster as user postgres
# 4. Copies the entire data directory
# 5. Creates the file recovery.conf
pg_basebackup -U postgres -d postgresql://localhost:$(primaryPort) -D /var/lib/postgresql/11/$(replica) -P -R
# 6. Inserts the restore_command property and its value
echo "restore_command = 'cp ~/Documents/Severalnines/Archiving/%f %p'" >> /var/lib/postgresql/11/$(replica)/recovery.conf
# 7. The same is done with recovery_target_timeline
echo "recovery_target_timeline = 'latest'" >> /var/lib/postgresql/11/$(replica)/recovery.conf

Ten blok replikacji określony powyżej musi być uruchamiany przez użytkownika postgres systemu operacyjnego, aby uniknąć potencjalnych konfliktów z tym, kto jest właścicielem danych klastra, postgresem lub rootem użytkownika.

Klaster replik nadal stoi, ustawiając go w celu pomyślnego rozpoczęcia replikacji, przy czym proces klastra replik o nazwie pg_walreceiver wchodzi w interakcję z klastrem podstawowym o nazwie pg_walsender przez połączenie TCP.

# 1. Executes the block ‘replicate’ by passing two parameters
sudo -H -u postgres make replicate replica=replica primaryPort=5433
# 2. Starts the cluster replica
sudo systemctl start [email protected]

Weryfikacja kondycji tego modelu replikacji, zwanego replikacją strumieniową, jest wykonywana przez zapytanie uruchamiane w klastrze podstawowym.

# 1. Checks the Streaming Replication created
sudo -H -u postgres psql -x -c ‘select * from pg_stat_replication;’ -p 5433

Wnioski

W tym blogu pokazaliśmy, jak skonfigurować asynchroniczną replikację strumieniową między dwoma klastrami PostgreSQL. Pamiętaj jednak, że w powyższym kodzie istnieją luki, na przykład użycie użytkownika postgres do wykonania takiego zadania nie jest zalecane.

Replikacja klastra zapewnia szereg korzyści, gdy jest używana we właściwy sposób i ma łatwy dostęp do interfejsów API, które wchodzą w interakcję z klastrami.