Zarządzanie wysoką dostępnością w PostgreSQL – Część II:Menedżer replikacji

Wdrażasz PostgreSQL w chmurze i chcesz poznać możliwości osiągnięcia wysokiej dostępności? W naszym poprzednim poście na blogu, Zarządzanie wysoką dostępnością w PostgreSQL — część I, omówiliśmy możliwości i działanie PostgreSQL Automatic Failover (PAF) firmy ClusterLabs. W części II przedstawiamy alternatywne narzędzie open source, Menedżer replikacji z drugiego kwadrantu, a następnie w części III zagłębimy się w naszą trzecią alternatywę, Patroni by Zalando.

Zarządzanie wysoką dostępnością w PostgreSQL – Część I:Automatyczne przełączanie awaryjne PostgreSQL
Zarządzanie wysoką dostępnością w PostgreSQL – część III:Patroni

Menedżer replikacji (repmgr)

repmgr to pakiet narzędzi typu open source opracowany przez 2ndQuadrant do zarządzania replikacją i przełączaniem awaryjnym klastrów PostgreSQL. Zapewnia narzędzia do konfigurowania, konfigurowania, zarządzania i monitorowania replikacji PostgreSQL, a także umożliwia wykonywanie zadań ręcznego przełączania i przełączania awaryjnego za pomocą narzędzia repmgr. To bezpłatne narzędzie obsługuje i ulepsza wbudowaną replikację strumieniową PostgreSQL.

Menedżer replikacji zapewnia dwa główne narzędzia do zarządzania replikacją i przełączaniem awaryjnym PostgreSQL.

repmgr

Narzędzie interfejsu wiersza poleceń, które umożliwia wykonywanie różnych zadań administracyjnych.
repmgr umożliwia konfigurowanie serwerów w trybie gotowości, zwiększanie stanu wstrzymania, przełączanie i monitorowanie stanu klastra PostgreSQL.
Zapewnia również opcję uruchamiania na sucho dla prawie wszystkich poleceń administracyjnych.

repmgrd

To demon, który:

Aktywnie monitoruje klastry PostgreSQL i wykonuje niezbędne działania w oparciu o stan klastra.
Wykonuje automatyczne przełączanie awaryjne w przypadku awarii węzła podstawowego, promując najbardziej kwalifikujący się tryb gotowości jako nowy główny.
Zapewnia opcję monitorowania i przechowywania danych związanych z wydajnością replikacji.
Zapewnia powiadomienie przez wywołanie skryptów użytkownika dla zarejestrowanych zdarzeń.

Jak to działa

repmrg nie tylko zarządza replikacją klastrów PostgreSQL, ale ma również możliwość konfigurowania serwerów rezerwowych do replikacji. Po początkowej instalacji musimy wprowadzić zmiany w pliku konfiguracyjnym repmgr (repmgr.conf) z wymaganymi szczegółami na każdym serwerze. Gdy serwer jest skonfigurowany, należy go zarejestrować w repmgr za pomocą polecenia rejestru głównego/w trybie gotowości repmgr. Najpierw konfiguruje się i rejestruje węzeł podstawowy. Następnie serwery rezerwowe są tworzone i konfigurowane za pomocą polecenia repmgr standby clone, które klonuje węzeł gotowości PostgreSQL z innego serwera PostgreSQL.

Menedżer replikacji korzysta z funkcji rozszerzeń PostgreSQL i tworzy własny schemat w bazie danych klastra do przechowywania informacji związanych z klastrem. Instalacja rozszerzenia i tworzenie schematu odbywa się podczas rejestracji serwera głównego za pomocą repmgr. Po zakończeniu instalacji ręczne operacje administracyjne, takie jak promowanie, śledzenie, przełączanie itp., można wykonać za pomocą narzędzia repmgr. Do operacji przełączania wymaga skonfigurowania bezhasłowego SSH między węzłami.

Automatyczne przełączanie awaryjne można skonfigurować za pomocą repmgrd. repmgrd wymaga załadowania biblioteki współdzielonej „repmgr” w momencie uruchamiania serwera PostgreSQL. Nazwa biblioteki powinna być wymieniona w shared_preload_libraries parametr konfiguracyjny w pliku postgresql.conf. Ponadto, aby repmgrd działał, failover=automatic parametr należy ustawić w pliku repmgr.conf. Po ustawieniu wszystkich tych parametrów demon repmgrd zaczyna aktywnie monitorować klaster. Jeśli wystąpi jakakolwiek awaria w węźle podstawowym, będzie próbował ponownie połączyć się kilka razy. Gdy wszystkie próby połączenia się z głównymi nie powiodą się, najbardziej kwalifikujący się tryb gotowości jest wybierany przez wybór jako nowy główny przez repmgrd.

repmgr obsługuje również powiadomienia o zdarzeniach. Ma zestaw predefiniowanych zdarzeń i przechowuje każde wystąpienie tych zdarzeń w tabeli repmgr.events. repmgr umożliwia przekazywanie powiadomień o zdarzeniach do zdefiniowanego przez użytkownika programu lub skryptu, który może podjąć dalsze działania, takie jak wysłanie wiadomości e-mail lub wywołanie dowolnego alertu. Odbywa się to poprzez ustawienie event_notification_command parametr w repmgr.conf.

Jak sobie radzi ze scenariuszem Split Brain?

repmgr rozwiązuje scenariusze podziału mózgu przy użyciu lokalizacji parametr, gdzie każdy węzeł powinien określać parametr lokalizacji na podstawie centrum danych, w którym jest umieszczony. W przypadku jakiegokolwiek podziału sieci repmgr zapewni promocję węzła, który znajduje się w tej samej lokalizacji co główny. Jeśli nie znajdzie żadnego węzła w tej lokalizacji, nie będzie promować żadnego węzła w żadnej lokalizacji.

Obsługuje również izolację sieci w przypadku parzystej liczby serwerów w klastrze. Odbywa się to za pomocą dodatkowego węzła zwanego serwerem-świadkiem. Serwer-świadek jest węzłem, który jest brany pod uwagę tylko przy zliczaniu większości głosów. Na tym serwerze nie będzie instalacji PostgreSQL, a co za tym idzie, nie będzie żadnej roli w replikacji.

Czy są jakieś wymagania dotyczące konfiguracji?

repmgr będzie wymagał dedykowanej bazy danych i użytkownika z uprawnieniami superużytkownika. Istnieje jednak również możliwość zapewnienia superużytkownika, jeśli nie chcesz dać superużytkownikowi dostępu do użytkownika repmgr.
Jeśli chcesz, aby repmgr kopiował pliki konfiguracyjne znajdujące się poza katalogiem danych PostgreSQL i/lub testował funkcjonalność przełączania, będziesz również potrzebował połączeń SSH bez hasła między obydwoma serwerami, oraz rsync powinien być zainstalowany.
Jeśli zamierzasz używać poleceń opartych na usługach innych niż pg_ctl (który jest domyślnie używany przez repmgr) do uruchamiania, zatrzymywania, przeładowywania i restartowania, możesz określić je w repmgr plik konfiguracyjny (repmgr.conf).

Podstawowe parametry konfiguracyjne wymagane w pliku konfiguracyjnym repmgr są następujące:

node_id (int) – Unikalna liczba całkowita większa od zera, która identyfikuje węzeł.nazwa_węzła (ciąg) – Aby uniknąć nieporozumień, zaleca się arbitralny (ale unikalny) ciąg znaków wykorzystujący nazwę hosta serwera lub inny identyfikator jednoznacznie powiązany z serwerem.

conninfo (ciąg) – Informacje o połączeniu z bazą danych w postaci ciągu conninfo. Wszystkie serwery w klastrze muszą mieć możliwość połączenia się z węzłem lokalnym za pomocą tego ciągu.

katalog_danych (ciąg) – Katalog danych węzła. Jest to potrzebne repmgr do wykonywania operacji, gdy instancja PostgreSQL nie jest uruchomiona i nie ma innego sposobu określenia katalogu danych.

repmgr Plusy

Repmgr zapewnia narzędzia, które pomagają w konfiguracji węzłów podstawowych i rezerwowych oraz konfiguracji replikacji.
Nie używa żadnych dodatkowych portów do komunikacji. Jeśli chcesz dokonać przełączenia, tylko wtedy będzie wymagało skonfigurowania bezhasłowego SSH.
Zapewnia powiadomienie przez wywołanie skryptów użytkownika dla zarejestrowanych zdarzeń.
Wykonuje automatyczne przełączanie awaryjne w przypadku awarii głównego serwera.

repmgr Minusy

repmgr nie wykrywa, czy stan gotowości jest źle skonfigurowany z nieznanym lub nieistniejącym węzłem w konfiguracji odzyskiwania. Węzeł będzie wyświetlany jako rezerwowy, nawet jeśli będzie działał bez połączenia z głównym/kaskadowym węzłem rezerwowym.
Nie można pobrać statusu innego węzła z węzła, w którym usługa PostgreSQL nie działa. Dlatego nie zapewnia rozwiązania kontroli rozproszonej.
Nie obsługuje przywracania zdrowia poszczególnych węzłów.

Zarządzanie wysoką dostępnością w #PostgreSQL – Część II:Narzędzie Open Source repmgr Kliknij, aby tweetować

Scenariusze testów wysokiej dostępności

Przeprowadziliśmy kilka testów zarządzania wysoką dostępnością PostgreSQL przy użyciu repmgr. Wszystkie te testy zostały przeprowadzone podczas działania aplikacji i wstawiania danych do bazy danych PostgreSQL. Aplikacja została napisana przy użyciu sterownika PostgreSQL Java JDBC z wykorzystaniem możliwości przełączania awaryjnego połączenia.

Testy serwera w trybie gotowości

Sl. Nie	Scenariusz testowy	Obserwacja
1	Zabij proces PostgreSQL	Serwer w trybie gotowości został oznaczony jako uszkodzony. Nie było żadnych przerw w działaniu programu piszącego. Aby ponownie uruchomić proces PostgreSQL, wymagana była ręczna interwencja.
2	Zatrzymaj proces PostgreSQL	Serwer w trybie gotowości został oznaczony jako uszkodzony. Nie było żadnych przerw w działaniu programu piszącego. Aby ponownie uruchomić proces PostgreSQL, wymagana była ręczna interwencja.
3	Uruchom ponownie serwer	Serwer w trybie gotowości został oznaczony jako uszkodzony. Gdy serwer wystartował po restarcie, PostgreSQL został uruchomiony ręcznie i serwer został oznaczony jako uruchomiony. Nie było żadnych przerw w działaniu programu piszącego.
4	Zatrzymaj proces repmgrd	Serwer rezerwowy nie będzie częścią sytuacji automatycznego przełączania awaryjnego. Stwierdzono, że usługa PostgreSQL jest uruchomiona. Nie było żadnych przerw w działaniu programu piszącego.

Testy serwera głównego/podstawowego

Sl. Nie	Scenariusz testowy	Obserwacja
1	Zabij proces PostgreSQL	repmgrd rozpoczął sprawdzanie stanu połączenia z serwerem podstawowym na wszystkich serwerach oczekujących na ustalony interwał. Kiedy wszystkie próby się nie powiodły, na wszystkich serwerach oczekujących uruchomione zostały wybory. W wyniku wyborów awansowano stan gotowości, który otrzymał ostatnio odebraną LSN. Serwery rezerwowe, które przegrały wybory, będą czekać na powiadomienie od nowego węzła głównego i podążać za nim po otrzymaniu powiadomienia. Wystąpiła awaria aplikacji piszącej. Aby ponownie uruchomić proces PostgreSQL, wymagana była ręczna interwencja.
2	Stop the PostgreSQL process and bring it back immediately after health check expiry	repmgrd started the health check for the primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back. Cluster was left in an indeterminate state and manual intervention was required.
3	Reboot the server	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was ran to add the server back to the cluster. There was downtime in the writer application.
4	Stop the repmgr process	The primary server will not be a part of the automated failover situation. PostgreSQL service was found to be running. There was no disruption in the writer application.

Network Isolation Tests

Sl. No	Test Scenario	Observation
1	Network isolate the primary server from other servers (all have same value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted, but the PostgreSQL process was still running on the old master node. There were two nodes running as master. Manual intervention was required after the network isolation was corrected.
2	Network isolate the primary server from other servers (the standby servers has same value for location but primary had a different value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. But, there was no new master elected since the standby servers had a location different from that of the primary. repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.

Inference

repmgr provides several commands to setup and monitor PostgreSQL replication. It is feature-rich and also eases the job of the database administrator (DBA). However, it’s not a full fledged high availability management tool since it will not manage the resources. Manual intervention is required to ensure the resource is in proper state.

So, in this post, we’ve discussed the capabilities and workings of Replication Manager by 2ndQuadrant. In our next post, we’ll discuss the same high availability aspects using Patroni by Zalando. For users looking to automate their high availability in the cloud, check out our PostgreSQL on Azure and PostgreSQL on AWS fully managed solutions.