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.