Wyszukiwanie w witrynie

Jak skonfigurować replikację strumieniową PostgreSQL 12 w CentOS 8

Baza danych PostgreSQL obsługuje kilka rozwiązań replikacji w celu tworzenia aplikacji o wysokiej dostępności, skalowalnych i odpornych na błędy, z których jednym jest Dziennik zapisu z wyprzedzeniem (WAL ) Wysyłka. To rozwiązanie umożliwia wdrożenie serwera rezerwowego przy użyciu przesyłania dzienników opartego na plikach lub replikacji strumieniowej lub, jeśli to możliwe, kombinacji obu podejść.

W przypadku replikacji strumieniowej rezerwowy (podrzędny serwer bazy danych) jest skonfigurowany do łączenia się z serwerem głównym/podstawowym, który przesyła strumieniowo rekordy WAL do rezerwy w miarę ich generowania, bez czekania na WAL plik do wypełnienia.

Domyślnie replikacja strumieniowa jest asynchroniczna i dane są zapisywane na serwerach rezerwowych po zatwierdzeniu transakcji na serwerze głównym. Oznacza to, że pomiędzy zatwierdzeniem transakcji na serwerze głównym a uwidocznieniem zmian na serwerze rezerwowym występuje niewielkie opóźnienie. Wadą tego podejścia jest to, że w przypadku awarii serwera głównego wszelkie niezatwierdzone transakcje mogą nie zostać zreplikowane, co może spowodować utratę danych.

W tym przewodniku pokazano, jak skonfigurować replikację strumieniową Postgresql 12 master-standby w CentOS 8. Wykorzystamy „miejsca replikacji” w trybie gotowości jako rozwiązanie pozwalające uniknąć ponownego wykorzystania przez serwer główny starych segmentów WAL, zanim serwer rezerwowy je otrzyma.

Należy zauważyć, że w porównaniu z innymi metodami, w szczelinach replikacyjnych zachowywana jest tylko taka liczba segmentów, o której wiadomo, że jest potrzebna.

Środowisko testowe:

W tym przewodniku założono, że połączyłeś się z głównym i rezerwowym serwerem bazy danych jako root przez SSH (w razie potrzeby użyj polecenia Sudo, jeśli jesteś podłączony jako zwykły użytkownik z uprawnieniami administracyjnymi):

Postgresql master database server: 		10.20.20.9
Postgresql standby database server:		10.20.20.8

Obydwa serwery baz danych muszą mieć zainstalowany Postgresql 12, w przeciwnym razie zobacz: Jak zainstalować PostgreSQL i pgAdmin w CentOS 8.

Uwaga: PostgreSQL 12 zawiera poważne zmiany w implementacji i konfiguracji replikacji, takie jak zastąpienie plików recovery.conf i konwersja parametrów recovery.conf na normalne parametry konfiguracyjne PostgreSQL, co znacznie ułatwia konfigurację replikacji klastra.

Krok 1: Konfiguracja głównego/podstawowego serwera bazy danych PostgreSQL

1. Na serwerze głównym przejdź do konta systemowego Postgres i skonfiguruj adresy IP, na których serwer główny będzie nasłuchiwał połączeń od klientów.

W tym przypadku użyjemy słowa * oznaczającego wszystko.

su - postgres
psql -c "ALTER SYSTEM SET listen_addresses TO '*';"

Polecenie SQL ALTER SYSTEM SET to potężna funkcja umożliwiająca zmianę parametrów konfiguracyjnych serwera bezpośrednio za pomocą zapytania SQL. Konfiguracje są zapisywane w pliku postgresql.conf.auto znajdującym się w katalogu głównym folderu danych (np. /var/lib/pgsql/12/data/) i czytają dodatek do tych przechowywanych w postgresql.conf. Jednak konfiguracje w pierwszym przypadku mają pierwszeństwo przed konfiguracjami w późniejszych i innych powiązanych plikach.

2. Następnie utwórz rolę replikacji, która będzie używana do połączeń z serwera rezerwowego do serwera głównego, za pomocą programu createuser. W poniższym poleceniu flaga -P monituje o hasło dla nowej roli, a flaga -e odzwierciedla polecenia generowane przez createuser i wysyłane do serwera bazy danych.

su – postgres
createuser --replication -P -e replicator
exit

3. Następnie wprowadź następujący wpis na końcu /var/lib/pgsql/12/data/pg_hba.conf pliku konfiguracyjnego uwierzytelniania klienta z polem bazy danych ustawionym na replikację, jak pokazano na zrzucie ekranu.

host    replication     replicator      10.20.20.8/24     md5

4. Teraz zrestartuj usługę Postgres12, używając następującego polecenia systemctl, aby zastosować zmiany.

systemctl restart postgresql-12.service

5. Następnie, jeśli masz uruchomioną usługę firewalld, musisz dodać usługę Postgresql w konfiguracji firewalla, aby zezwalać na żądania z serwera rezerwowego do głównego.

firewall-cmd --add-service=postgresql --permanent
firewall-cmd --reload

Krok 2: Tworzenie podstawowej kopii zapasowej w celu uruchomienia serwera rezerwowego

6. Następnie musisz wykonać podstawową kopię zapasową serwera głównego z serwera rezerwowego; pomaga to w uruchomieniu serwera rezerwowego. Musisz zatrzymać usługę postgresql 12 na serwerze rezerwowym, przejść na konto użytkownika Postgres, wykonać kopię zapasową katalogu danych (/var/lib/pgsql/12/data/), a następnie usunąć wszystko, co się w nim znajduje jak pokazano, przed wykonaniem podstawowej kopii zapasowej.

systemctl stop postgresql-12.service
su - postgres
cp -R /var/lib/pgsql/12/data /var/lib/pgsql/12/data_orig
rm -rf /var/lib/pgsql/12/data/*

7. Następnie użyj narzędzia pg_basebackup, aby wykonać podstawową kopię zapasową z prawem własności (użytkownik systemu bazy danych, tj. Postgres, w konto użytkownika Postgres) i z odpowiednimi uprawnieniami.

W poniższym poleceniu opcja:

  • -h – określa host będący serwerem głównym.
  • -D – określa katalog danych.
  • -U – określa użytkownika połączenia.
  • -P – umożliwia raportowanie postępu.
  • -v – włącza tryb szczegółowy.
  • -R – umożliwia utworzenie konfiguracji odzyskiwania: Tworzy plik standby.signal i dołącza ustawienia połączenia do postgresql.auto.conf pod danymi informator.
  • -X – umożliwia dołączenie do kopii zapasowej wymaganych plików dziennika zapisu z wyprzedzeniem (plików WAL). Wartość stream oznacza przesyłanie strumieniowe WAL podczas tworzenia kopii zapasowej.
  • -C – umożliwia utworzenie szczeliny replikacyjnej nazwanej opcją -S przed rozpoczęciem tworzenia kopii zapasowej.
  • -S – określa nazwę slotu replikacji.
pg_basebackup -h 10.20.20.9 -D /var/lib/pgsql/12/data -U replicator -P -v  -R -X stream -C -S pgstandby1
exit

8. Po zakończeniu procesu tworzenia kopii zapasowej nowy katalog danych na serwerze rezerwowym powinien wyglądać tak, jak na zrzucie ekranu. Tworzony jest sygnał gotowości, a ustawienia połączenia są dołączane do pliku postgresql.auto.conf. Możesz wyświetlić jego zawartość za pomocą polecenia ls.

ls -l /var/lib/pgsql/12/data/

Urządzenie podrzędne replikacji będzie działać w trybie „Hot Standby”, jeśli parametr hot_standby jest ustawiony na włączony (wartość domyślna) w pliku postgresql.conf i w katalogu danych znajduje się plik standby.signal.

9. Teraz z powrotem na serwerze głównym, po otwarciu widoku pg_replication_slots powinieneś zobaczyć miejsce replikacji o nazwie pgstandby1 w następujący sposób.

su - postgres
psql -c "SELECT * FROM pg_replication_slots;"
exit

10. Aby wyświetlić ustawienia połączenia dołączone w pliku postgresql.auto.conf, użyj polecenia cat.

cat /var/lib/pgsql/12/data/postgresql.auto.conf

11. Teraz rozpocznij normalne operacje na bazie danych na serwerze rezerwowym, uruchamiając usługę PostgreSQL w następujący sposób.

systemctl start postgresql-12

Krok 3: Testowanie replikacji strumieniowej PostgreSQL

12. Po pomyślnym nawiązaniu połączenia między urządzeniem głównym a serwerem rezerwowym zobaczysz proces odbiornika WAL na serwerze rezerwowym ze statusem przesyłania strumieniowego. Możesz to sprawdzić korzystając z widoku pg_stat_wal_receiver.

psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"

i odpowiadający mu proces nadawcy WAL na serwerze głównym/podstawowym ze stanem przesyłania strumieniowego i stanem sync_state async, możesz sprawdzić ten widok pg_stat_replication pg_stat_replication.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Z powyższego zrzutu ekranu wynika, że replikacja strumieniowa jest asynchroniczna. W następnej sekcji pokażemy, jak opcjonalnie włączyć replikację synchroniczną.

13. Teraz przetestuj, czy replikacja działa prawidłowo, tworząc testową bazę danych na serwerze głównym i sprawdź, czy istnieje ona na serwerze rezerwowym.
[master]postgres=# UTWÓRZ BAZĘ DANYCH tecmint;
[czuwanie]postgres=# \l

Opcjonalnie: Włączanie replikacji synchronicznej

14. Replikacja synchroniczna oferuje możliwość jednoczesnego zatwierdzenia transakcji (lub zapisu danych) do podstawowej bazy danych i rezerwowej/repliki. Potwierdza to tylko, że transakcja zakończyła się sukcesem, gdy wszystkie zmiany dokonane w ramach transakcji zostały przesłane do jednego lub większej liczby synchronicznych serwerów rezerwowych.

Aby włączyć replikację synchroniczną, parametr synchronous_commit musi być również włączony (jest to wartość domyślna, zatem nie ma potrzeby wprowadzania żadnych zmian) oraz należy ustawić parametr synchronous_standby_names do niepustej wartości. W tym przewodniku ustawimy to na wszystkich.

psql -c "ALTER SYSTEM SET synchronous_standby_names TO  '*';"

15. Następnie załaduj ponownie usługę PostgreSQL 12, aby zastosować nowe zmiany.

systemctl reload postgresql-12.service

16. Teraz, gdy ponownie odpytasz proces nadawcy WAL na serwerze głównym, powinien on pokazać stan przesyłania strumieniowego i stan_synchronizacji wynoszący 16.synchronizuj.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Dotarliśmy do końca tego przewodnika. Pokazaliśmy, jak skonfigurować replikację strumieniową bazy danych PostgreSQL 12 w trybie gotowości głównej w CentOS 8. Omówiliśmy także, jak włączyć replikację synchroniczną w klastrze bazy danych PostgreSQL.

Istnieje wiele zastosowań replikacji i zawsze możesz wybrać rozwiązanie, które spełnia Twoje wymagania dotyczące środowiska IT i/lub aplikacji. Aby uzyskać więcej informacji, przejdź do sekcji Serwery rezerwowe wysyłania dzienników w dokumentacji PostgreSQL 12.