Pule połączeń PostgreSQL:część 3 – Pgpool-II

W naszych poprzednich postach z tej serii omówiliśmy przypadek puli połączeń i wprowadziliśmy PgBouncer. W tym poście omówimy jego najpopularniejszą alternatywę – Pgpool-II.

Pgpool-II to szwajcarski scyzoryk w oprogramowaniu pośredniczącym PostgreSQL. Obsługuje wysoką dostępność, zapewnia automatyczne równoważenie obciążenia i ma inteligencję do równoważenia obciążenia między urządzeniami nadrzędnymi i podrzędnymi, dzięki czemu obciążenia zapisu są zawsze kierowane do urządzeń nadrzędnych, a obciążenia do odczytu są kierowane do urządzeń podrzędnych. Pgpool-II zapewnia również replikację logiczną. Chociaż jego użycie i znaczenie spadły, ponieważ wbudowane opcje replikacji poprawiły się po stronie serwera PostgreSQL, nadal pozostaje cenną opcją dla starszych wersji PostgreSQL. Oprócz tego zapewnia również łączenie połączeń!

W skrócie

Konfiguracja Pgpool-II Wykonaj poniższe czynności, aby skonfigurować Pgpool-II, włączyć potrzebne usługi puli połączeń i połączyć się z serwerem PostgreSQL. Przeczytaj teraz Jak to działa Sprawdź architekturę Pgpool-II, która obsługuje wszystkie jej funkcje, i dowiedz się, jak działa pooler połączeń. Przeczytaj teraz Czego nie robi Pgpool-II? Zapoznaj się z ograniczeniami Pgpool-II, aby sprawdzić, czy jest to odpowiedni pooler połączeń dla Twojej aplikacji. Przeczytaj teraz

Konfigurowanie Pgpool-II

Pliki binarne Pgpool-II są dystrybuowane za pośrednictwem repozytoriów Pgpool-II – możesz przeczytać więcej o instalacji w tym dokumencie pomocy. Po zainstalowaniu musimy skonfigurować Pgpool-II, aby włączyć żądane usługi i połączyć się z serwerem PostgreSQL. Więcej na ten temat możesz przeczytać tutaj.

Aby uzyskać minimalną konfigurację łączenia, musisz podać następujące informacje:

• Nazwa użytkownika i zaszyfrowane hasło md5 użytkowników, którzy będą łączyć się z Pgpool-II – muszą być zdefiniowane w osobnym pliku, który można łatwo wygenerować za pomocą narzędzia pg_md5.
• Interfejsy/adresy IP i numer portu do nasłuchiwania połączeń przychodzących – musi to być zdefiniowane w pliku konfiguracyjnym.
• Nazwa hosta serwerów backendu [Więcej niż jeden serwer jest określony tylko wtedy, gdy chcemy użyć replikacji i/lub równoważenia obciążenia].
• Usługi, które chcesz włączyć. Domyślnie pula połączeń jest włączona, a inne usługi są wyłączone w pliku konfiguracyjnym zainstalowanym z plikami binarnymi.

I to wszystko – jesteśmy gotowi! Podczas gdy konfiguracje dostępne z Pgpool-II mogą być bardziej zniechęcające na pierwszy rzut oka, ludzie stojący za Pgpool-II naprawdę nam to ułatwili!

Jak to działa

Pgpool-II ma bardziej zaangażowaną architekturę niż PgBouncer, aby obsługiwać wszystkie funkcje, które robi. Jednak w tej sekcji ograniczymy się do opisania sposobu działania puli połączeń.

Proces nadrzędny Pgpool-II domyślnie rozgałęzia 32 procesy potomne — są one dostępne do połączenia. Architektura jest podobna do serwera PostgreSQL:jeden proces =jedno połączenie. Rozwidla również „proces pcp”, który jest używany do zadań administracyjnych i wykracza poza zakres tego postu. 32 dzieci są teraz gotowe do przyjmowania połączeń. Podobnie jak PgBouncer, emulują one również serwer PostgreSQL – klienci mogą łączyć się z dokładnie tym samym ciągiem połączenia, co z normalnym serwerem PostgreSQL.

Jądro kieruje połączenia przychodzące do jednego z procesów potomnych, które zostały zarejestrowane jako detektory. Ani główny proces Pgpool-II, ani użytkownicy końcowi nie mają żadnej kontroli nad tym, który proces potomny odpowiada na przychodzące żądanie. Każde bezczynne dziecko może odebrać prośbę. Jeśli nie zostaną znalezione żadne bezczynne dzieci, żądanie połączenia zostanie umieszczone w kolejce po stronie jądra – może to spowodować zawieszenie się aplikacji takich jak pgbench, czekając na połączenia klientów.

Gdy bezczynne dziecko Pgpool-II otrzyma żądanie połączenia, to:

1. Sprawdza nazwę użytkownika w swoim pliku haseł. Jeśli nie zostanie znaleziony, odrzuca połączenie.
2. Jeśli nazwa użytkownika zostanie znaleziona, sprawdza podane hasło z hashem md5 zapisanym w tym pliku.
3. Gdy uwierzytelnianie się powiedzie, sprawdza, czy ma już buforowane połączenie dla tej kombinacji baza danych + użytkownik.
4. Jeśli tak, zwraca połączenie do klienta. Jeśli tak się nie stanie, otwiera nowe połączenie.
5. Wszystkie żądania i odpowiedzi przechodzą przez Pgpool-II podczas oczekiwania na rozłączenie klienta.
6. Gdy klient się rozłączy, Pgpool-II musi zdecydować, czy buforować połączenie:
   • Jeśli ma puste miejsce, przechowuje je w pamięci podręcznej.
   • Jeśli nie ma pustego slotu (to znaczy, że buforowanie tego połączenia przekroczyłoby dozwolony max_pool_size), podejmie decyzję na podstawie wewnętrznego algorytmu.
7. Jeśli zdecyduje się buforować połączenie, uruchomi wstępnie skonfigurowane zapytanie resetujące, aby wyczyścić wszystkie szczegóły sesji i zabezpieczyć je przed ponownym użyciem przez innego klienta.
8. Teraz proces potomny może pobrać więcej połączeń.

Czego nie robi Pgpool-II?

Niestety, dla tych, którzy skupiają się tylko na tworzeniu puli połączeń, Pgpool-II nie radzi sobie zbyt dobrze, to pule połączeń, szczególnie dla niewielkiej liczby klientów. Ponieważ każdy proces potomny ma własną pulę i nie ma możliwości kontrolowania, który klient łączy się z którym procesem potomnym, zbyt wiele szczęścia pozostawia się, jeśli chodzi o ponowne wykorzystanie połączeń.

Jak widać, Pgpool i PgBouncer mają raczej różne mocne strony – w naszym ostatnim poście z serii przeprowadzimy bezpośrednie testy i porównanie funkcji! Bądź na bieżąco!