PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Zarządzanie wysoką dostępnością w PostgreSQL – Część III:Patroni

W naszych poprzednich wpisach na blogu omawialiśmy możliwości i działanie PostgreSQL Automatic Failover (PAF) przez Cluster Labs i Replication Manager (repmgr) przez 2ndQuadrant. W ostatnim poście z tej serii przyjrzymy się ostatniemu rozwiązaniu, Patroni firmy Zalando, i porównamy wszystkie trzy na końcu, abyś mógł określić, który framework wysokiej dostępności jest najlepszy dla twojego wdrożenia hostingu PostgreSQL.

  • Zarządzanie wysoką dostępnością w PostgreSQL – Część I:Automatyczne przełączanie awaryjne PostgreSQL
  • Zarządzanie wysoką dostępnością w PostgreSQL – Część II:Menedżer replikacji

Patroni dla PostgreSQL

Patroni powstał jako rozwidlenie Governor, projektu Compose. Jest to pakiet narzędzi typu open source, napisany w Pythonie, do zarządzania wysoką dostępnością klastrów PostgreSQL. Zamiast budować własny protokół spójności, Patroni inteligentnie wykorzystuje model spójności dostarczany przez rozproszony magazyn konfiguracji (DCS). Obsługuje również inne rozwiązania DCS, takie jak Zookeeper, etcd, Consul i Kubernetes.

Patroni zapewnia kompleksową konfigurację klastrów PostgreSQL HA, w tym replikację strumieniową. Obsługuje różne sposoby tworzenia węzła gotowości i działa jak szablon, który można dostosować do własnych potrzeb.

To bogate w funkcje narzędzie udostępnia swoją funkcjonalność za pośrednictwem interfejsów API REST, a także narzędzia wiersza poleceń o nazwie patronictl. Obsługuje integrację z HAProxy, wykorzystując interfejsy API kontroli stanu do obsługi równoważenia obciążenia.

Patroni obsługuje również powiadomienia o zdarzeniach za pomocą wywołań zwrotnych, które są skryptami uruchamianymi przez określone działania. Umożliwia użytkownikom wykonywanie wszelkich czynności konserwacyjnych poprzez zapewnienie funkcji wstrzymania/wznawiania. Funkcja wsparcia Watchdog sprawia, że ​​platforma jest jeszcze bardziej niezawodna.

Jak to działa

Na początku należy zainstalować binaria PostgreSQL i Patroni. Gdy to zrobisz, będziesz musiał również skonfigurować konfigurację HA DCS. Wszystkie niezbędne konfiguracje do ładowania klastra muszą być określone w pliku konfiguracyjnym yaml, a Patroni użyje tego pliku do inicjalizacji. Na pierwszym węźle Patroni inicjalizuje bazę danych, uzyskuje blokadę lidera z DCS i upewnia się, że węzeł jest uruchamiany jako główny.

Kolejnym krokiem jest dodanie węzłów gotowości, dla których Patroni oferuje wiele opcji. Domyślnie Patroni używa pg_basebackup do tworzenia węzła gotowości, a także obsługuje niestandardowe metody, takie jak WAL-E, pgBackRest, Barman i inne do tworzenia węzła gotowości. Patroni bardzo ułatwia dodawanie węzła rezerwowego i obsługuje wszystkie zadania ładowania początkowego i konfigurację replikacji strumieniowej.

Zarządzanie wysoką dostępnością w #PostgreSQL – Część III:Patroni vs. PAF vs. repmgrKliknij, aby tweetować

Po zakończeniu konfiguracji klastra Patroni będzie aktywnie monitorować klaster i upewniać się, że jest w dobrym stanie. Węzeł główny odnawia blokadę lidera co ttl sekund (domyślnie:30 sekund). Kiedy węzeł główny nie odnowi blokady lidera, Patroni uruchamia wybory, a węzeł, który otrzyma blokadę lidera, zostanie wybrany jako nowy główny.

Jak radzi sobie ze scenariuszem Split Brain?

W systemie rozproszonym konsensus odgrywa ważną rolę w określaniu spójności, a Patroni używa DCS do osiągnięcia konsensusu. Tylko węzeł, który posiada blokadę lidera może być nadrzędnym, a blokadę lidera uzyskuje się przez DCS. Jeśli węzeł główny nie utrzymuje blokady lidera, Patroni natychmiast go zdegraduje i będzie działał jako rezerwowy. W ten sposób w dowolnym momencie w systemie może być uruchomiony tylko jeden master.

Czy są jakieś wymagania dotyczące konfiguracji?

  • Patroni potrzebuje Pythona 2.7 lub nowszego.
  • Należy zainstalować DCS i jego konkretny moduł Pythona. Do celów testowych DCS można zainstalować na tych samych węzłach, na których działa PostgreSQL. Jednak w środowisku produkcyjnym DCS musi być zainstalowany w osobnych węzłach.
  • Plik konfiguracyjny yaml musi być obecny przy użyciu tych ustawień konfiguracji wysokiego poziomu:

    Globalny/uniwersalny
    Obejmuje to konfigurację taką jak nazwa hosta (nazwa), która musi być unikalna dla klastra, nazwa klastra (zakres) i ścieżka do przechowywania konfiguracji w DCS (przestrzeń nazw).

    Dziennik
    Ustawienia dziennika specyficzne dla Patroni, w tym poziom, format, numer_pliku, rozmiar_pliku itp.

    Konfiguracja Bootstrap
    To jest globalna konfiguracja klastra, która zostanie zapisana w DCS. Te parametry konfiguracyjne można zmienić za pomocą interfejsów API Patroni lub bezpośrednio w DCS. Konfiguracja ładowania początkowego obejmuje metody tworzenia trybu gotowości, parametry initdb, skrypt po inicjalizacji itp. Zawiera również konfigurację limitów czasu, parametry decydujące o użyciu funkcji PostgreSQL, takich jak gniazda replikacji , tryb synchroniczny itp. Ta sekcja zostanie zapisana w ///config danego magazynu konfiguracji po zainicjowaniu nowego klastra.

    PostgreSQL
    Ta sekcja zawiera parametry specyficzne dla PostgreSQL, takie jak uwierzytelnianie, ścieżki katalogów dla danych, pliki binarne i konfiguracyjne, adres IP nasłuchu itp.

    REST API
    Ta sekcja zawiera konfigurację specyficzną dla Patroni związaną z REST API, taką jak adres nasłuchiwania, uwierzytelnianie, SSL itp.

    Konsul
    Ustawienia specyficzne dla Consul DCS.

    Itd.
    Ustawienia specyficzne dla Etcd DCS.

    Wystawca
    Ustawienia specyficzne dla DCS wystawcy.

    Kubernetes
    Ustawienia specyficzne dla Kubernetes DCS.

    ZooKeeper
    Ustawienia specyficzne dla ZooKeeper DCS.

    Watchdog
    Ustawienia specyficzne dla Watchdoga.

Profesjonaliści Patroni

  • Patroni umożliwia kompletną konfigurację klastra.
  • Obsługuje REST API i integrację HAproxy.
  • Obsługuje powiadomienia o zdarzeniach za pośrednictwem skryptów wywołań zwrotnych wyzwalanych przez określone działania.
  • Wykorzystuje DCS do konsensusu.

Wady Patronów

  • Patroni nie wykryje błędnej konfiguracji stanu gotowości z nieznanym lub nieistniejącym węzłem w konfiguracji odzyskiwania. Węzeł będzie wyświetlany 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.
  • Użytkownik musi zająć się konfiguracją, zarządzaniem i aktualizacją oprogramowania DCS.
  • Wymaga otwarcia wielu portów do komunikacji komponentów:
    • Port REST API dla Patroni
    • Minimum 2 porty dla DCS

Scenariusze testów wysokiej dostępności

Przeprowadziliśmy kilka testów zarządzania HA PostgreSQL przy użyciu Patroni. Wszystkie te testy zostały przeprowadzone, gdy aplikacja była uruchomiona i wstawiała dane 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 Patroni przywrócił proces PostgreSQL do stanu działania.

  • Nie było żadnych przerw w działaniu aplikacji pisarza.
2 Zatrzymaj proces PostgreSQL Patroni przywrócił proces PostgreSQL do stanu działania.

  • Nie było żadnych przerw w działaniu aplikacji pisarza.
3 Uruchom ponownie serwer Patroni należy uruchomić po ponownym uruchomieniu, chyba że skonfigurowano tak, aby nie uruchamiał się po ponownym uruchomieniu. Po uruchomieniu Patroni rozpoczął proces PostgreSQL i skonfigurował konfigurację trybu gotowości.

  • Nie było żadnych przerw w działaniu aplikacji pisarza.
4 Zatrzymaj proces Patroniego
  • Nie zatrzymało to procesu PostgreSQL.
  • lista opiekuńcza nie wyświetlił tego serwera.
  • Nie było żadnych przerw w działaniu aplikacji pisarza.

Zasadniczo musisz więc monitorować stan procesu Patroniego – w przeciwnym razie doprowadzi to do problemów w dalszej kolejności.

Testy serwera głównego/podstawowego

Sl. Nie Scenariusz testowy Obserwacja
1 Zabij proces PostgreSQL Patroni przywrócił proces PostgreSQL do stanu działania. Patroni działający na tym węźle miał podstawową blokadę, więc wybory nie zostały uruchomione.

  • Wystąpiła awaria aplikacji piszącej.
2 Zatrzymaj proces PostgreSQL i przywróć go natychmiast po wygaśnięciu kontroli stanu Patroni przywrócił proces PostgreSQL do stanu działania. Patroni działający na tym węźle miał podstawową blokadę, więc wybory nie zostały uruchomione.

  • Wystąpiła awaria aplikacji piszącej.
3 Uruchom ponownie serwer Nastąpiło przełączenie awaryjne i jeden z serwerów rezerwowych został wybrany jako nowy główny po uzyskaniu blokady. Kiedy Patroni został uruchomiony na starym wzorcu, przywrócił starego wzorca i wykonał pg_rewind i zaczął podążać za nowym wzorcem.T

  • Wystąpiła awaria aplikacji piszącej.
4 Zatrzymaj/zabij proces Patroniego
  • Jeden z serwerów rezerwowych nabył blokadę DCS i stał się mistrzem, promując się.
  • Stary mistrz nadal działał, co doprowadziło do scenariusza z wieloma mistrzami. Aplikacja wciąż pisała do starego mistrza.
  • Gdy Patroni został uruchomiony na starym wzorcu, przewinął starego wzorca (use_pg_rewind została ustawiona na true) na nową główną oś czasu i lsn i zaczęła podążać za nowym wzorcem.

Jak widać powyżej, bardzo ważne jest monitorowanie stanu procesu Patroniego na mistrzu. Niezastosowanie się do tego może prowadzić do scenariusza z wieloma wzorcami i potencjalnej utraty danych.

Testy izolacji sieci

Sl. Nie Scenariusz testowy Obserwacja
1 Izolacja sieciowa serwera głównego od innych serwerów Komunikacja DCS została zablokowana dla węzła głównego.

  • PostgreSQL został zdegradowany na serwerze głównym.
  • W większościowej partycji wybrano nowego mistrza.
  • Wystąpiła awaria aplikacji piszącej.
2 Odizoluj sieciowy serwer rezerwowy od innych serwerów Komunikacja DCS została zablokowana dla węzła gotowości.

  • Usługa PostgreSQL była uruchomiona, jednak węzeł nie był brany pod uwagę w wyborach.
  • Nie było żadnych przerw w działaniu aplikacji pisarza.

Jaki jest najlepszy framework HA PostgreSQL?

Patroni jest cennym narzędziem dla administratorów baz danych PostgreSQL (DBA), ponieważ wykonuje kompleksową konfigurację i monitorowanie klastra PostgreSQL. Elastyczność wyboru DCS i tworzenia trybu gotowości jest zaletą dla użytkownika końcowego, ponieważ może on wybrać metodę, z którą jest wygodny.

Interfejsy API REST, integracja z HaProxy, obsługa Watchdog, wywołania zwrotne i bogate w funkcje zarządzanie sprawiają, że Patroni jest najlepszym rozwiązaniem do zarządzania HA PostgreSQL.

Testy PostgreSQL HA Framework:PAF vs. repmgr vs. Patroni

Poniżej znajduje się wyczerpująca tabela zawierająca szczegółowe wyniki wszystkich testów, które przeprowadziliśmy na wszystkich trzech platformach — PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) i Patroni.

Testy serwera w trybie gotowości

Scenariusz testowy Automatyczne przełączanie awaryjne PostgreSQL (PAF) Menedżer replikacji (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
 Standby server was marked as failed. Manual intervention was required to start the PostgreSQL process again.

  • There was no disruption of the writer application.
 Patroni brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
Stop the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
 Standby server was marked as failed. Manual intervention was required to start the PostgreSQL process again.

  • There was no disruption of the writer application.
 Patroni brought the PostgreSQL process back to running state.

  • There was no disruption of the writer application.
Reboot the server Standby server was marked offline initially. Once the server came up after reboot, PostgreSQL was started by Pacemaker and the server was marked as online. If fencing was enabled then node wouldn’t have been added automatically to cluster.

  • There was no disruption of the writer application.
 Standby server was marked as failed. Once the server came up after reboot, PostgreSQL was started manually and server was marked as running.

  • There was no disruption of the writer application.
 Patroni needs to be started after reboot, unless configured to not start on reboot. Once Patroni was started, it started the PostgreSQL process and setup the standby configuration.

  • There was no disruption of the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and was marked offline.
  • There was no disruption of the writer application.
 Agent:repmgrd

  • The standby server will not be part of automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption of the writer application.
 Agent:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

Master/Primary Server Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the 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.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. The most eligible standby server was promoted as the new master. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started 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 run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Network Isolation Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started 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.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had 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.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. PostgreSql :tablica Json do wierszy przy użyciu łączenia bocznego

  2. Błąd intarray Postgresql:niezdefiniowany symbol:pfree

  3. Klauzula SQL Between z kolumnami stringów

  4. PostgreSQL działa wolno na dużym stole z tablicami i mnóstwem aktualizacji

  5. Lista Pythona do tablicy PostgreSQL