Pgpool-II to zaawansowane oprogramowanie open source, które działa jako warstwa pośrednicząca między użytkownikami lub aplikacjami a bazą danych. Jego głównym celem jest zapewnienie funkcjonalności, których PostgreSQL nie gwarantuje w odpowiednim stopniu bądź nie posiada wcale. Działanie Pgpool-II można porównać do proxy – w wielu przypadkach jego obecność jest niemal niezauważalna dla aplikacji, ponieważ nie wymaga zmian w jej kodzie.
Większość firm i przedsiębiorstw do funkcjonowania potrzebuje ciągłego dostępu do danych. Niejednokrotnie ich brak uniemożliwia pracownikom wykonywanie obowiązków. W infrastrukturach krytycznych brak dostępu często oznacza zatrzymanie działalności, np. banki tracą zdolność przeprowadzania transakcji, lotnisko na skutek długotrwałej niedostępności aplikacji może nie przyjmować samolotów, a sklepy przestają robić to, co powinny – czyli sprzedawać.
We wszystkich tych przypadkach występuje konieczność zagwarantowania wysokiej dostępności (ang. High availability, HA). Pgpool-II oferuje mechanizmy umożliwiające nie tylko redukcję przerw w dostępie do danych w przypadku awarii, ale także optymalne zarządzanie zasobami oraz połączeniami do bazy.
W zależności od potrzeb użytkownika, priorytety dotyczące Pgpool-II mogą się różnić. Dla jednych kluczowe będzie zapewnienie ciągłej dostępności klastra w taki sposób, aby w razie awarii ruch automatycznie przełączył się na inny serwer. Dla innych natomiast priorytetem może być obsłużenie każdego połączenia tak, aby żadne nie zostało odrzucone z błędem informującym o wyczerpanym limicie. Ostatecznie to, które funkcjonalności Pgpool-II są najistotniejsze, zależy od konkretnych wymagań i priorytetów danego środowiska.
Replikacja
Pgpool-II oferuje różne metody replikacji (clustering mode), które pozwalają na zwiększenie niezawodności oraz skalowalności systemu bazodanowego. Może korzystać zarówno z natywnego mechanizmu PostgreSQL, jak i własnych metod replikacji z maksymalnie 127 węzłami standby.
Metody replikacji (parametr backend_clustering_mode) w Pgpool-II:
- Streaming replication – natywna replikacja PostgreSQL (streaming replication), która umożliwia aktualizowanie serwerów standby w czasie rzeczywistym, przez co mogą one przejąć rolę serwera głównego w razie awarii. Według dokumentacji Pgpool jest to najpopularniejsza oraz zalecana metoda.
- Native replication – w tym trybie Pgpool jest odpowiedzialny za replikację danych między serwerami, co realizowane jest poprzez przesyłanie zapytań typu DDL i DML do każdego z nich.
- Snapshot isolation – rozszerzenie metody Native replication, zapewniające większą spójność widoczności danych między węzłami. Metoda oprócz włączenia w pgpool.conf, wymaga również ustawienia parametru default_transaction_isolation = ‘repetable read’.
- Slony – dane są replikowane przy użyciu narzędzia Slony-I.
- Raw – użytkownik musi samodzielnie zadbać o synchronizację danych między węzłami, a użycie funkcji load balancing jest niemożliwe.
- Logical replication – PostgreSQL odpowiada za replikację obiektów danych między serwerami PostgreSQL. Minusem tej metody jest brak replikacji DDL.
Każdy z powyższych trybów ma swoje specyficzne zastosowania. Wybór odpowiedniej metody zależy od wymagań dotyczących spójności danych, wydajności oraz architektury systemu.
Monitorowanie
Monitorowanie wbudowanymi narzędziami PCP w Pgpool-II umożliwia kompleksowy wgląd w stan i wydajność klastra PostgreSQL. System pozwala na śledzenie kluczowych metryk związanych z aktywnością połączeń, obciążeniem węzłów oraz kondycją replikacji. Narzędzia te umożliwiają m.in. weryfikację statusu poszczególnych serwerów w klastrze (w tym ich rolę jako primary/standby), wykrywanie opóźnień replikacji oraz monitorowanie statystyk wykorzystania puli połączeń.
Wynik komendy pcp_node_info pokazuje szczegółowe informacje o poszczególnych węzłach: adres IP, port, rolę w klastrze oraz status (up/down). Z kolei pcp_watchdog_info dostarcza danych o działaniu Pgpool – pokazuje listę wszystkich nodów w klastrze oraz ich aktualną rolę.
Pgpool-II można również zarządzać przez interfejs graficzny pgpoolAdmin. Umożliwia on konfigurację parametrów, podgląd statystyk oraz wykonywanie podstawowych operacji administracyjnych bez konieczności użycia wiersza poleceń. Ten dodatkowy komponent trzeba jednak zainstalować i skonfigurować.
Load Balancing
Pgpool-II oferuje mechanizm równoważenia obciążenia (load balancing), który optymalizuje wykorzystanie zasobów bazodanowych i zwiększa wydajność systemu. Mechanizm działa w oparciu o konfigurację replikacji, w której dostępne są serwery replikowane (standby). Zapytania typu SELECT są automatycznie kierowane do węzłów standby, a zapytania modyfikujące dane (INSERT, UPDATE, DELETE) trafiają wyłącznie do serwera głównego. Dzięki temu zmniejsza się obciążenie węzła primary, a operacje odczytu są realizowane szybciej, co ma szczególne znaczenie w systemach o dużej liczbie równoczesnych zapytań.
Działanie równoważenia obciążenia można dostosować za pomocą parametrów konfiguracyjnych, np. load_balance_mode, który określa, czy funkcja load balancing jest aktywna. Parametr statement_level_load_balance pozwala na bardziej precyzyjne sterowanie rozkładem zapytań, umożliwiając balansowanie na poziomie poszczególnych zapytań SQL. Dodatkowo waga danych serwerów standby może być modyfikowana poprzez backend_weight, co umożliwia proporcjonalne rozłożenie ruchu między konkretne węzły. Widok pool_backend_stats doskonale prezentuje efekt wprowadzonej konfiguracji.
Failover
Failover w Pgpool-II opiera się na monitorowaniu dostępności serwerów backendowych w klastrze PostgreSQL. W przypadku wykrycia awarii serwera głównego Pgpool-II automatycznie promuje jeden z serwerów zapasowych (standby) do roli nowego primary, tym samym kontynuując dystrybucję zapytań w zależności od roli, jaką sprawują. Jest to kluczowa funkcjonalność dla zapewnienia wysokiej dostępności (HA) systemu bazodanowego. Umożliwia bowiem utrzymanie ciągłości działania aplikacji nawet w sytuacji wystąpienia awarii sprzętowej lub sieciowej. Proces ten jest realizowany bez ingerencji użytkownika.
Kluczowe funkcje failover w Pgpool-II:
- detekcja awarii – Pgpool-II stale monitoruje stan serwerów PostgreSQL w klastrze i wykrywa ich niedostępność;
- promocja standby do roli primary – jeżeli dotychczasowy serwer główny przestanie odpowiadać, Pgpool-II promuje jeden z serwerów standby do nowej roli primary;
- rekonfiguracja routingu zapytań – po awarii Pgpool-II aktualizuje swoją konfigurację, aby nowy serwer primary przejął obsługę zapytań zapisujących, a pozostałe węzły replikowane działały jako serwery standby;
- obsługa zewnętrznych skryptów failover – administratorzy mogą zdefiniować własne skrypty failover, np. do powiadamiania zespołu operacyjnego o zmianach w klastrze;
- integracja z narzędziami HA – Pgpool-II może współpracować z innymi mechanizmami wysokiej dostępności, np. EDB Failover Manager (EFM), Patroni lub repmgr, zapewniając bardziej zaawansowane zarządzanie awariami.
Connection pooling
Pgpool-II zarządza pulą połączeń do bazy danych, co znacząco zmniejsza narzut związany z nawiązywaniem nowych połączeń do PostgreSQL. Ponieważ może to być zasobożerne, Pgpool-II utrzymuje istniejące połączenia (zgodnie z konfiguracją), zwiększając efektywność obsługi zapytań. Pozwala to na zmniejszenie obciążenia serwerów bazy danych, szczególnie w środowiskach o dużej liczbie krótkotrwałych połączeń.
Przykładowe architektury
Pgpool-II może zostać zainstalowany na kilka sposobów. Bardzo popularnym i używanym rozwiązaniem jest jego instalowanie wspólnie z PostgreSQL na jednym serwerze lub na wirtualnej maszynie. Poniżej schemat takiej architektury.
Możliwa jest także instalacja komponentów na oddzielnych serwerach. Dzięki temu odporność rozwiązania na awarie wzrasta. Ewentualne uszkodzenie jednego serwera wpływa bowiem wyłącznie na jeden komponent, a nie na wszystkie jednocześnie.
Pgpool-II, PostgreSQL i EDB Failover Manager
Bardzo dobrze sprawdza się rozwiązanie HA oparte na trzech komponentach: Pgpool-II, PostgreSQL i EDB Failover Manager. Ostatni z nich, czyli EFM, wprowadza co prawda dodatkową warstwę do konfiguracji, jednak jego zalety (monitoring oraz zarządzanie klastrem) w pełni to rekompensują. Wymagany jest również dodatkowy serwer z Witness pełniący ważną rolę w momencie promowania nowego primary.
Warto zaznaczyć, że narzędzia oferowane przez EDB (EnterpriseDB) są dostępne w ramach płatnej subskrypcji. Subskrypcja ta obejmuje nie tylko samo oprogramowanie, ale również profesjonalne wsparcie techniczne oraz dostęp do dodatkowych funkcjonalności. W typowej konfiguracji wysokiej dostępności EDB Failover Manager (EFM) oraz PostgreSQL są instalowane na tym samym serwerze fizycznym lub wirtualnym. Jest to oddzielny serwer od tego, na którym działa Pgpool-II. Takie rozwiązanie pozwala na lepsze zarządzanie zasobami i zwiększa niezawodność systemu.
Podsumowanie
Pgpool-II to wszechstronne narzędzie, które odgrywa kluczową rolę w zapewnieniu wysokiej dostępności (HA) w środowisku PostgreSQL. Dzięki mechanizmom, takim jak replikacja, monitorowanie, load balancing, failover oraz connection pooling, pozwala na optymalizację pracy bazy danych i minimalizację przestojów.
Elastyczność konfiguracji sprawia, że Pgpool-II można dostosować do różnych wymagań – od zapewnienia nieprzerwanego (prawie) dostępu do danych po efektywne zarządzanie połączeniami i równoważenie obciążenia. Dobór odpowiedniego modelu wdrożenia zależy od specyfiki środowiska i priorytetów użytkownika. Niezależnie od konfiguracji, Pgpool-II znacząco poprawia stabilność i wydajność systemów bazodanowych.
