pg_pool-II — jedno z ciekawszych rozwiązań replikacji (i nie tylko) PostgreSQL

Opublikowany przez

W poniższym artykule przedstawiam streszczenie najważniejszych cech oraz najistotniejszych braków systemu replikacji baz danych PostgreSQL jakim jest pg_pool-II.

Najważniejsze cechy(zalety?) pg_pool-II:

  • replikacja multi-master PostgreSQL
  • replikacje (a)synchroniczna master-slave za pośrednictwem:
    • slony-I (2.*) — asnchroniczna
    • strumieniowanie — synchroniczne — Slave Hot Standby (od PostgreSQL 9.0)
  • równoważenie obciążenia
  • równoległe zapytania (od PostgreSQL 7.4)
  • możliwość partycjonowania tabel na wiele maszyn
  • podtrzymywanie połączeń
  • automatyczne odłączanie od klastra maszyn ktróre są niedostępne (np. awaria sieci) lub zwracająca wyniki niespujne z pozostałymi maszynami w klastrze.
  • częściowo automatyczne podłączenie do klastra maszyn po odzyskaniu z nimi komunikacji
  • przy odpowiendej komunkacji niemal całkowita przezroczystość dla aplikacji klienta
  • z reguly brak koniecznosci zmian w aplikacji klienta i strukturze bazy
  • Licencja BSD

Braki / Wady pg_pool-II:

  • W trybie multi-master konieczność replikacji całego klastra — brak możliwości replikacji tylko wybranych baz, i co za tym idzie brak możliwości replikacji różnych baz na różne hosty
  • Brak sprawdzania spójności danych przed ponownym podłączeniem maszyny do klastra — trzeba o to zadbac samemu
  • Brak synchronizacji baz przed ponownym podłączeniem do klastra — j.w.
  • Brak opcji komunikacji asynchronicznej w trybie multi-mater

Trzeba sobie zdawać sprawe z tego że wykorzystywanie komunikacji synchronicznej multi-master skutkuje tym iż w zależności od konfiguracji sprzętowej i wykonywanych operacji w pesymistycznym wariancie czas trwania pojedyńczej opracji zapisu rośnie liniowo proporcjnalnie do liczby maszyn w klastrze w poronaniu do czasu transakcji zapisu dla pojedynczej maszyny — jest to koszt jaki trzeba zapłacić za niezawodność którą zyskujemy dzięki temu, że w przypdaku awarii jednej z maszyn klaster jako całość nadal funkcjonuje bez przerw.

Oczywiscie wadę tą można niemal całkowiecie zniwelować poprzez odpowidnią konfiguracje sprzętową i/lub partycjonowanie ale znacznie podniesie to koszt sprzętu.

Alternatywnym rozwiązniem które nie posiada tej wady (kosztem innych) jest rozwiązanie asynchroniczne Master-Slave, które pg_pool-II realizuje za pomoca Slony-I

Oczywiście wady tej było by też teoretycznie pozbawione rozwiązanie asynchroniczne multi-master, jednak replikacja asynchroniczna multi-master jest znacznie trudniejsza do implemaentcji — wymaga nietrywialnych algorytmów uzgadniania podczas operacji zapisu i pewnie dlatego jeszcze nie istnieje takie rozwiązanie nadające się do wdrożenia produkcyjnego. Oczywiście gdyby ktoś znał jakieś rozwiązanie produkcyjne asynchronicznego multi-master to proszę o info w komentarzach, przy czym nie mówię tu o aplikacjach eksperymentalnych czy istniejscych głównie na papierze lub nie zgodnych w pełni z PostgreSQL.

Ważna funkcjonalnością jest też możliwość partycjonowania tabel pomiędzy różne maszyny co poprawia skalowalność, pozwalając podnieść wydajność i pojemność baz powyżej pojemności pojedynczych maszyn i tworzyć konfiguracje baz przechowujących dziesiątki terabajtów danych, bez wysoko-specjalizowanego i bardzo kosztownego hardware’u.

Warto też wspomnieć o pgpool-HA — myślę że nazwa jest wystarczająco wymowna.

Istnieje też dość wygodne narzędzie administracyjne z intefejsem web — pgpoolAdmin

Na temat instalacji i konfiguracji nie będe się rozpisywał bo wszystko jest doskonale opisane w oficjalnej dokumentacji pg_pool-II.

Rozwiąznie alternatywne — Postgres-XC / Postgres-XL

Alterantywnym rozwiązniem jest Postgres-XC o którym trochę więcej pisze w poście: Postgres-XC – czyli klaster serwerów PostgreSQL o wysokiej dostępności z równoważeniem obciążenia. Nestety nie jest jasne czy rozwiaznie to bedzie dalej rozwijane. Przez jakiść czas był też rozwijany jako Postgres-XL na mniej liberalnej licencji.