Zarządzanie wysoką dostępnością (HA) w hostingu PostgreSQL to bardzo ważny temat, który zapewnia, że klastry wdrożeniowe bazy danych zachowują wyjątkowy czas pracy bez przestojów i wysoką wydajność operacyjną, dzięki czemu Twoje dane są zawsze dostępne dla Twojej aplikacji. We wcześniejszym poście na blogu przedstawiliśmy konfigurację wysokiej dostępności PostgreSQL za pomocą replikacji strumieniowej, a teraz pokażemy, jak najlepiej zarządzać wysoką dostępnością po stronie klienta.
Dostępnych jest wiele narzędzi do zarządzania wysoką dostępnością (HA) klastrów wdrożeniowych PostgreSQL przy użyciu replikacji strumieniowej. Rozwiązania te oferują automatyczne przełączanie awaryjne, monitorowanie dostępności i stanu systemu, replikację, zarządzanie użytkownikami i inne przydatne zadania administracyjne w przypadkach użycia baz danych Postgres. Niektóre z wyróżniających się rozwiązań typu open source to:
-
Automatyczne przełączanie awaryjne PostgreSQL przez ClusterLabs
-
Menedżer replikacji dla klastrów PostgreSQL autorstwa repmgr (2ndQuadrant)
-
Patroni autorstwa Zalando
Każde narzędzie zapewnia własny sposób zarządzania klastrami PostgreSQL o wysokiej dostępności. W naszej trzyczęściowej serii postów na temat HA dla PostgreSQL podzielimy się przeglądem, wymaganiami wstępnymi oraz wynikami pracy i testów dla każdego z tych trzech narzędzi. W części 1 zagłębimy się w rozwiązanie PAF firmy ClusterLabs.
- Zarządzanie wysoką dostępnością w PostgreSQL – Część II:Menedżer replikacji
- Zarządzanie wysoką dostępnością w PostgreSQL – część III:Patroni
Jak zarządzać wysoką dostępnością bazy danych PostgreSQL?
PostgreSQL Automatic Failover (PAF) to rozwiązanie do zarządzania wysoką dostępnością PostgreSQL firmy ClusterLabs. Wykorzystuje replikację synchroniczną Postgres, aby zagwarantować, że żadne dane nie zostaną utracone w czasie operacji przełączania awaryjnego. Korzysta z popularnego, standardowego w branży pakietu Pacemaker i Corosync. Dzięki połączonym aplikacjom Pacemaker i Corosync będziesz w stanie wykryć w systemie awarie bazy danych PostgreSQL i podjąć odpowiednie działania.
Pacemaker to usługa umożliwiająca zarządzanie wieloma zasobami i robi to z pomocą agentów ds. zasobów. Następnie agenci ds. zasobów są odpowiedzialni za obsługę określonego zasobu, jak powinni się zachowywać i informowanie Pacemaker o swoich wynikach.
Implementacja agenta zasobów musi być zgodna ze specyfikacją Open Cluster Framework (OCF). Ta specyfikacja definiuje zachowanie agentów zasobów i implementację metod, takich jak zatrzymanie, uruchomienie, promocja, degradacja i interakcja z Pacemakerem.
PAF to agent zasobów OCF dla Postgresa napisany w Perlu. Po zbudowaniu klastra bazy danych przy użyciu wewnętrznej replikacji strumieniowej, PAF może ujawnić Pacemakerowi aktualny stan instancji PostgreSQL na każdym z węzłów bazy danych:master, slave, zatrzymany, nadrabiający zaległości, load balancer itp.
Jak działa automatyczne przełączanie awaryjne Postgresa
PAF komunikuje się z Pacemakerem w sprawie stanu klastra i monitoruje działanie bazy danych PostgreSQL. W przypadku awarii informuje Pacemaker, a jeśli nie ma szans na odzyskanie aktualnego serwera głównego, uruchamia wybór między jednym z aktualnie rezerwowych serwerów baz danych. Po wdrożeniu solidnego Pacemakera Postgres Automatic Failover wykona czynności zarządzania, takie jak uruchamianie, zatrzymywanie, monitorowanie i przełączanie awaryjne we wszystkich węzłach baz danych Postgres.
Zarządzanie wysoką dostępnością w PostgreSQL - Część I:Automatyczne przełączanie awaryjne przez ClusterLabsKliknij, aby tweetować
Automatyczne przełączanie awaryjne PostgreSQL dla konfiguracji wysokiej dostępności (HA)
- PAF obsługuje PostgreSQL w wersji 9.3 i nowszej.
- PAF nie ponosi odpowiedzialności za tworzenie mastera/wstrzymania PostgreSQL ani jego konfigurację — przed użyciem PAF należy utworzyć i skonfigurować replikację strumieniową.
- PAF nie edytuje żadnych wymagań konfiguracyjnych ani instalacyjnych PostgreSQL. Wymaga to jednak od użytkowników bazy danych spełnienia kilku wymagań wstępnych, takich jak:
- Slave musi być skonfigurowany w trybie gorącej gotowości. Węzły podrzędne w trybie gotowości mogą być odpytywane jako bazy danych tylko do odczytu.
- Plik szablonu odzyskiwania (domyślnie:
/recovery.conf.pcmk) musi być dostarczony z poniższymi parametrami: - tryb_gotowości =wł.
- recovery_target_timeline =„najnowsze”
- primary_conninfo musi mieć zdefiniowany parametr nazwa_aplikacji i ustawiony na nazwę lokalnego węzła, jak w Pacemaker.
- PAF udostępnia wiele parametrów związanych z zarządzaniem zasobem Postgres. Można to skonfigurować zgodnie z własnymi wymaganiami. Poniżej znajdują się parametry:
- bindir: lokalizacja plików binarnych PostgreSQL (domyślnie:/usr/bin)
- pgdane: lokalizacja PGDATA twojej instancji (domyślnie:/var/lib/pgsql/data)
- katalog danych: ścieżka do katalogu ustawionego w data_directory z pliku postgresql.conf
- pghost: katalog gniazda lub adres IP używany do łączenia się z lokalną instancją (domyślnie:/tmp)
- pgport: port do połączenia z lokalną instancją (domyślnie:5432)
- recovery_template: szablon lokalny, który zostanie skopiowany jako plik PGDATA/recovery.conf. Ten plik szablonu musi istnieć we wszystkich węzłach (domyślnie:$PGDATA/recovery.conf.pcmk)
- start_opts: Dodatkowe argumenty podawane procesowi Postgres podczas uruchamiania. Zobacz „postgres –help”, aby poznać dostępne opcje. Przydatne, gdy plik postgresql.conf nie znajduje się w katalogu danych (PGDATA), np.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
- użytkownik_systemowy: właściciel systemu procesu Twojej instancji (domyślnie:postgres)
- maxlag: maksymalne opóźnienie dozwolone w trybie gotowości, zanim ustawimy na nim ujemny wynik główny
Profesjonalne automatyczne przełączanie awaryjne Postgres
- PAF zapewnia użytkownikowi bezpłatną, praktyczną konfigurację i konfigurację PostgreSQL.
- PAF może obsłużyć awarię węzła i wywołać wybory, gdy master ulegnie awarii.
- W PAF można wymusić zachowanie kworum.
- Dostarczy kompletne rozwiązanie do zarządzania bazami danych o wysokiej dostępności (HA) dla zasobu, w tym uruchamianie, zatrzymywanie i monitorowanie oraz obsługę scenariuszy izolacji sieci.
- Jest to rozwiązanie rozproszone, które umożliwia zarządzanie dowolnym węzłem z innego węzła.
Wady automatycznego przełączania awaryjnego Postgres
- PAF nie wykrywa, czy węzeł rezerwowy jest nieprawidłowo skonfigurowany z nieznanym lub nieistniejącym węzłem w konfiguracji odzyskiwania. Węzeł będzie pokazany jako podrzędny, nawet jeśli tryb gotowości działa bez połączenia z węzłem głównym/kaskadowym węzłem gotowości.
- Wymaga otwarcia dodatkowego portu (domyślnie 5405) do komunikacji między komponentami Pacemaker i Corosync za pomocą UDP.
- Nie obsługuje konfiguracji opartej na NAT.
- Brak obsługi pg_rewind.
Wysoka dostępność scenariuszy testowych PostgreSQL
Przeprowadziliśmy kilka testów w celu określenia możliwości zarządzania wysoką dostępnością (ha) PostgreSQL przy użyciu PAF w niektórych przypadkach użycia. 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 funkcji przełączania awaryjnego połączenia.
Testy serwera w trybie gotowości
| Sl. Nie | Scenariusz testowy | Obserwacja |
|---|---|---|
| 1 | Zabij proces PostgreSQL | Pacemaker przywrócił proces PostgreSQL do stanu działania. Nie było żadnych przerw w działaniu programu piszącego. |
| 2 | Zatrzymaj proces PostgreSQL | Pacemaker przywrócił proces PostgreSQL do stanu działania. Nie było żadnych przerw w działaniu programu piszącego. |
| 3 | Uruchom ponownie serwer | Węzeł serwera bazy danych w stanie gotowości był początkowo oznaczony jako offline. Po uruchomieniu serwera po restarcie baza danych PostgreSQL została uruchomiona przez Pacemakera i serwer został oznaczony jako online. Gdyby ogrodzenie było włączone, węzeł nie zostałby automatycznie dodany do klastra. Nie było żadnych przerw w działaniu programu piszącego. |
| 4 | Zatrzymaj proces Pacemaker | Zatrzyma również proces PostgreSQL, a węzeł serwera zostanie oznaczony jako offline. 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 | Pacemaker przywrócił proces PostgreSQL do stanu działania. Pierwotny został odzyskany w wyznaczonym czasie, a zatem wybory nie zostały uruchomione. Aplikacja pisząca nie działała przez około 26 sekund. |
| 2 | Zatrzymaj proces PostgreSQL | Pacemaker przywrócił proces PostgreSQL do stanu działania. Pierwotny został odzyskany w wyznaczonym czasie, a zatem wybory nie zostały uruchomione. Nastąpiła przerwa w aplikacji piszącej przez około 26 sekund. |
| 3 | Uruchom ponownie serwer | Wybór został wywołany przez Pacemaker po progowym czasie, dla którego master nie był dostępny. Najbardziej kwalifikujący się serwer rezerwowy został promowany jako nowy główny. Gdy stary system główny pojawił się po ponownym uruchomieniu, został ponownie dodany do klastra bazy danych jako rezerwa. Gdyby ogrodzenie było włączone, węzeł nie zostałby automatycznie dodany do klastra. Usługa aplikacji pisarza nie działała przez około 26 sekund. |
| 4 | Zatrzymaj proces Pacemaker | Zatrzyma również proces PostgreSQL, a serwer zostanie oznaczony jako offline. Rozpoczą się wybory i wybrany zostanie nowy mistrz. Wystąpiła awaria aplikacji piszącej. |
Testy izolacji sieci
| Sl. Nie | Scenariusz testowy | Obserwacja |
| 1 | Sieć izoluje serwer rezerwowy od innych serwerów | Ruch Corosync został zablokowany na serwerze rezerwowym. Serwer został oznaczony jako offline, a usługa PostgreSQL została wyłączona ze względu na zasady kworum. Nie było żadnych zakłóceń w aplikacji pisarza. |
| 2 | Sieć izoluje serwer główny od innych serwerów (scenariusz podziału mózgu) | Ruch Corosync został zablokowany na serwerze głównym. Usługa PostgreSQL została wyłączona, a serwer główny został oznaczony jako offline ze względu na zasady kworum. W zaborze większościowym wybrano nowego mistrza. Wystąpiła awaria aplikacji piszącej. |
Różne testy
| Sl. Nie | Scenariusz testowy | Obserwacja |
| 1 | Zdegraduj klaster, wyłączając wszystkie serwery w trybie gotowości. | Kiedy wszystkie serwery oczekujące uległy awarii, usługa PostgreSQL na serwerze głównym została zatrzymana z powodu polityki kworum. Po tym teście, gdy wszystkie serwery rezerwowe zostały włączone, wybrano nowego mastera. Wystąpiła awaria aplikacji piszącej. |
| 2 | Losowo wyłącz wszystkie serwery jeden po drugim, zaczynając od mastera, i przywróć je wszystkie w tym samym czasie | Wszystkie serwery pojawiły się i dołączyły do klastra. Wybrano nowego mistrza. Wystąpiła awaria aplikacji piszącej. |
Czy PAF jest rozwiązaniem dla wysokiej dostępności PostgreSQL?
Automatyczne przełączanie awaryjne Postgres zapewnia kilka korzyści w obsłudze wysokiej dostępności (HA) PostgreSQL w wielu przypadkach użycia. PAF korzysta z funkcji przełączania awaryjnego adresu IP zamiast ponownego uruchamiania trybu gotowości, aby połączyć się z nowym urządzeniem głównym podczas zdarzenia przełączania awaryjnego. Jest to korzystne w scenariuszach, w których użytkownik nie chce restartować węzłów rezerwowych. PAF wymaga również bardzo niewielkiej interwencji ręcznej i zarządza ogólnym stanem wszystkich zasobów baz danych Postgres. Jedynym przypadkiem, w którym wymagana jest ręczna interwencja, jest rozbieżność danych na osi czasu, w której użytkownik może wybrać opcję pg_rewind.
W części 1 omówiliśmy możliwości i działanie PostgreSQL Automatic Failover (PAF) przez ClusterLabs, a w części 2 omówimy te same aspekty wysokiej dostępności przy użyciu Menedżera replikacji dla klastrów PostgreSQL (repmgr) firmy 2ndQuadrant. Koniecznie zajrzyj do Części 3, w której omówimy również Patroni firmy Zalando i porównamy wszystkie trzy rozwiązania open source, aby pomóc Ci określić, które rozwiązanie najlepiej pasuje do Twojej aplikacji.
W części 1 bloga omówiliśmy możliwości, najlepsze praktyki i działanie PAF w ClusterLabs, a w części 2 blogu omówimy omówić ten sam temat aspektów wysokiej dostępności za pomocą Menedżera replikacji dla klastrów Postgresql (repmgr) przez 2ndQuadrant. Koniecznie zajrzyj do naszego wpisu na blogu w części 3, w którym omówimy również Patroni od Zalando i porównamy wszystkie trzy rozwiązania typu open source, aby pomóc Ci określić najlepsze praktyki i idealne dopasowanie do Twoich aplikacji biznesowych.
