W tym poście na blogu zagłębiamy się w szczegóły konfiguracji replikacji strumieniowej (SR) w PostgreSQL. Replikacja strumieniowa jest podstawowym elementem konstrukcyjnym umożliwiającym osiągnięcie wysokiej dostępności w hostingu PostgreSQL i jest tworzona przez uruchomienie konfiguracji master-slave.

Terminologia master-slave

Serwer główny/główny

• Serwer, który może przyjmować zapisy.
• Nazywany również serwerem odczytu/zapisu.

Serwer podrzędny/w trybie gotowości

• Serwer, na którym dane są stale synchronizowane z masterem.
• Nazywany również serwerem zapasowym lub repliką.
• Serwer ciepłej rezerwy to taki, z którym nie można się połączyć, dopóki nie zostanie awansowany na serwer główny.
• W przeciwieństwie do tego, serwer w trybie gorącej rezerwy może akceptować połączenia i obsługiwać zapytania tylko do odczytu. Do końca tej dyskusji skupimy się tylko na serwerach w trybie gotowości.

Dane są zapisywane na serwerze głównym i propagowane do serwerów podrzędnych. W przypadku problemów z istniejącym serwerem głównym, jeden z serwerów podrzędnych przejmie i będzie kontynuował zapisy, zapewniając dostępność systemu.

Replikacja WAL oparta na wysyłce

Co to jest WAL?

• WAL oznacza rejestrowanie z wyprzedzeniem.
• Jest to plik dziennika, w którym wszystkie modyfikacje bazy danych są zapisywane przed ich zastosowaniem/zapisaniem w plikach danych.
• WAL służy do odzyskiwania po awarii bazy danych, zapewniając integralność danych.
• WAL jest używany w systemach baz danych w celu osiągnięcia niepodzielności i trwałości.

W jaki sposób WAL jest używany do replikacji?

Rekordy dziennika zapisu z wyprzedzeniem służą do utrzymywania synchronizacji danych między serwerami bazy danych. Można to osiągnąć na dwa sposoby:

Wysyłka dziennika oparta na plikach

• Pliki dziennika WAL są wysyłane z serwera głównego do serwerów rezerwowych, aby zapewnić synchronizację danych.
• Master może bezpośrednio kopiować logi do pamięci masowej serwera rezerwowego lub może współdzielić pamięć z serwerami rezerwowymi.
• Jeden plik dziennika WAL może zawierać do 16 MB danych.
• Plik WAL jest wysyłany dopiero po osiągnięciu tego progu.
• Spowoduje to opóźnienie w replikacji, a także zwiększy ryzyko utraty danych, jeśli główne awarie i logi nie zostaną zarchiwizowane

Przesyłanie strumieniowe rekordów WAL

• Części rekordów WAL są przesyłane strumieniowo przez serwery baz danych, aby zachować synchronizację danych.
• Serwer rezerwowy łączy się z masterem, aby otrzymywać porcje WAL.
• Rekordy WAL są przesyłane strumieniowo podczas ich generowania.
• Przesyłanie strumieniowe rekordów WAL nie musi czekać na wypełnienie pliku WAL.
• Dzięki temu serwer rezerwowy może być bardziej aktualny niż jest to możliwe w przypadku przesyłania dziennika opartego na plikach.
• Domyślnie replikacja strumieniowa jest asynchroniczna, mimo że obsługuje również replikację synchroniczną.

Obie metody mają swoje wady i zalety. Korzystanie z wysyłki opartej na plikach umożliwia odzyskiwanie do określonego momentu i ciągłą archiwizację, a przesyłanie strumieniowe zapewnia natychmiastową dostępność danych na serwerach rezerwowych. Możesz jednak skonfigurować PostgreSQL tak, aby używał obu metod jednocześnie i czerpał z tego korzyści. W tym blogu koncentrujemy się głównie na replikacji strumieniowej, aby osiągnąć wysoką dostępność PostgreSQL.

Jak skonfigurować replikację strumieniową?

Konfigurowanie replikacji strumieniowej w PostgreSQL jest bardzo proste. Zakładając, że PostgreSQL jest już zainstalowany na wszystkich serwerach, możesz wykonać następujące kroki, aby rozpocząć:

Konfiguracja na węźle głównym

• Zainicjuj bazę danych w węźle głównym za pomocą narzędzia initdb.
• Utwórz rolę/użytkownika z uprawnieniami do replikacji, uruchamiając poniższe polecenie. Po uruchomieniu polecenia możesz je zweryfikować, uruchamiając \du, aby wyświetlić je na psql.
  •   UTWÓRZ UŻYTKOWNIKA REPLIKACJA LOGOWANIA ZASZYFROWANE HASŁO „”;
• Skonfiguruj właściwości związane z replikacją strumieniową w głównym pliku konfiguracyjnym PostgreSQL (postgresql.conf):
  

  # Możliwe wartości to replika|minimalna|logiczna wal_level =Replika# wymagana do funkcji pg_rewind, gdy tryb gotowości nie jest zsynchronizowany z urządzeniem głównym wal_log_hints =on# ustawia maksymalną liczbę jednoczesnych połączeń z serwerów w trybie gotowości. max_wal_senders =3 # Poniższy parametr służy do poinformowania jednostki głównej, aby zachował minimalną liczbę # segmentów dzienników WAL, aby nie zostały one usunięte przed ich wykorzystaniem w trybie gotowości. # każdy segment jest 16 MB wal_keep_segments =8 # Poniższy parametr włącza połączenie tylko do odczytu na węźle, gdy jest on w # roli gotowości. Jest to ignorowane, gdy serwer działa jako master. hot_standby =wł.

• Dodaj wpis replikacji w pliku pg_hba.conf, aby zezwolić na połączenia replikacji między serwerami:
  

  # Zezwalaj na połączenia replikacji z hosta lokalnego, # przez użytkownika z uprawnieniami do replikacji. # TYPE    DATABASE    USER    ADDRESS    METHOD host    replikacja    repl_user    IPaddress(CIDR)    md5

• Uruchom ponownie usługę PostgreSQL na węźle głównym, aby zmiany zaczęły obowiązywać.

Konfiguracja na węźle (węzłach) gotowości

• Utwórz podstawową kopię zapasową węzła głównego za pomocą narzędzia pg_basebackup i użyj jej jako punktu wyjścia do stanu gotowości.
  

  # Wyjaśnienie kilku opcji używanych w narzędziu pg_basebackup # -X opcja jest używana do dołączenia wymaganych plików dziennika transakcji (plików WAL) do kopii zapasowej #. Po określeniu strumienia otworzy to drugie połączenie z serwerem # i rozpocznie przesyłanie strumieniowe dziennika transakcji w tym samym czasie, co tworzenie kopii zapasowej. # -c jest opcją punktu kontrolnego. Ustawienie go na szybkie wymusi wkrótce # utworzenie punktu kontrolnego. # -W zmusza pg_basebackup do pytania o hasło przed połączeniem # z bazą danych. pg_basebackup -D  -h -X strumień -c szybki -U użytkownik_repl -W

• Utwórz plik konfiguracji replikacji, jeśli nie istnieje (jest tworzony automatycznie, jeśli w pg_basebackup podano opcję -R):
  

  # Określa, czy uruchomić serwer jako czuwanie. W replikacji strumieniowej # ten parametr musi być włączony. tryb_gotowości =„on”# Określa ciąg połączenia, który jest używany przez serwer rezerwowy do połączenia # z podstawowym/głównym. primary_conninfo =‘host= port= user= hasło= nazwa_aplikacji=”nazwa_hosta”’# Określa odzyskiwanie do określonej osi czasu. Domyślnym ustawieniem jest odzyskiwanie według # tej samej osi czasu, która była aktualna podczas wykonywania podstawowej kopii zapasowej. # Ustawienie tego na najnowsze odzyskiwanie do ostatniej znalezionej osi czasu # w archiwum, które jest przydatne na serwerze rezerwowym. recovery_target_timeline =„najnowszy”

• Włącz stan czuwania.

Konfiguracja w trybie gotowości musi być wykonana na wszystkich serwerach w trybie gotowości. Po zakończeniu konfiguracji i uruchomieniu trybu gotowości połączy się z urządzeniem głównym i rozpocznie przesyłanie strumieniowe dzienników. Spowoduje to skonfigurowanie replikacji i można ją zweryfikować, uruchamiając instrukcję SQL „SELECT * FROM pg_stat_replication; “.

Domyślnie replikacja strumieniowa jest asynchroniczna. Jeśli chcesz, aby był synchroniczny, możesz go skonfigurować za pomocą następujących parametrów:

Synchronous_commit musi być włączony dla replikacji synchronicznej i jest to ustawienie domyślne. PostgreSQL zapewnia bardzo elastyczne opcje zatwierdzania synchronicznego i może być konfigurowany na poziomie użytkownika/bazy danych. Prawidłowe wartości są następujące:

• Wyłączone – Zatwierdzenie transakcji jest potwierdzane klientowi, nawet zanim ten rekord transakcji zostanie faktycznie opróżniony do pliku dziennika WAL na tym węźle.
• Lokalne –  Zatwierdzenie transakcji jest potwierdzane klientowi dopiero po opróżnieniu rekordu transakcji do pliku dziennika WAL na tym węźle.
• Remote_write – Zatwierdzenie transakcji jest potwierdzane klientowi dopiero po tym, jak serwer(y) określone przez synchronous_standby_names potwierdzi, że rekord transakcji został zapisany w pamięci podręcznej dysku, ale niekoniecznie po opróżnieniu do pliku dziennika WAL.
• Włączone – Zatwierdzenie transakcji jest potwierdzane klientowi dopiero po tym, jak serwer(y) określone przez synchronous_standby_names potwierdzi, że rekord transakcji jest opróżniany do pliku dziennika WAL.
• Remote_apply – Zatwierdzenie transakcji jest potwierdzane klientowi dopiero po tym, jak serwer(y) określone przez synchronous_standby_names potwierdzi, że rekord transakcji został opróżniony do pliku dziennika WAL i zastosowany do bazy danych.

Ustawienie synchronous_commit na off lub local w trybie replikacji synchronicznej sprawi, że będzie działać jak asynchroniczne i może pomóc w osiągnięciu lepszej wydajności zapisu. Będzie to jednak wiązało się z większym ryzykiem utraty danych i opóźnień odczytu na serwerach w trybie gotowości. Jeśli jest ustawiony na remote_apply, zapewni natychmiastową dostępność danych na serwerach rezerwowych, ale wydajność zapisu może ulec pogorszeniu, ponieważ powinna być stosowana na wszystkich/wspomnianych serwerach rezerwowych.

Możesz włączyć tryb archiwizacji, jeśli planujesz korzystać z ciągłej archiwizacji i odzyskiwania do określonego momentu. Chociaż nie jest to obowiązkowe w przypadku replikacji strumieniowej, włączenie trybu archiwum ma dodatkowe korzyści. Jeśli tryb archiwizacji nie jest włączony, musimy użyć miejsc replikacji funkcja lub upewnij się, że wal_keep_segments wartość jest wystarczająco wysoka w zależności od obciążenia.

Odnieś się do tej doskonałej prezentacji, aby poznać więcej szczegółów na temat wysokiej dostępności w PostgreSQL. W naszym następnym poście na blogu wprowadzimy Cię w świat narzędzi używanych do zarządzania wysoką dostępnością PostgreSQL przy użyciu replikacji strumieniowej.