PgBouncer to lekki pooler połączeń dla PostgreSQL. PgBouncer 1.7 został ogłoszony 18 grudnia 2015 r. W tym poście na blogu omówimy główne nowe ulepszenia w PgBouncer.

Najbardziej kolorowe funkcje

• PgBouncer 1.7 obsługuje połączenia TLS i myślę, że to największe ulepszenie nowego wydania. Wykorzystali biblioteki OpenSSL/LibreSSL jako backendową implementację tej funkcji.

• PgBouncer obsługuje teraz uwierzytelnianie przez certyfikat klienta TLS .

Zagłębmy się w szczegóły ustawień TLS PgBouncera. Istnieje 14 parametrów konfiguracyjnych związanych z konfiguracją TLS (ustawienia po stronie klienta + ustawienia po stronie serwera).

Aby przypisać tryb TLS do użycia dla połączeń od klientów, powinniśmy ustawić client_tls_sslmode parametr. Połączenia TLS są domyślnie wyłączone. Po włączeniu client_tls_key_file i client_tls_cert_file musi być również skonfigurowany, aby skonfigurować klucz i certyfikat używany przez PgBouncer do akceptowania połączeń klientów.

Możemy przypisać certyfikat główny do weryfikacji certyfikatów klienta, ustawiając client_tls_ca_file parametr, domyślnie nie jest ustawiony.

Możemy określić, które wersje protokołu TLS są dozwolone, ustawiając client_tls_protocols parametr, domyślny to wszystko.

Aby uzyskać bardziej szczegółowe ustawienia po stronie klienta, możesz sprawdzić client_tls_ciphers , client_tls_ecdhcurve i client_tls_dheparams parametry.

Porozmawiajmy teraz o parametrach konfiguracyjnych po stronie serwera TLS. Najpierw musimy zadeklarować tryb TLS, który będzie używany do połączeń z serwerami PostgreSQL z server_tls_sslmode parametr. Połączenia TLS są domyślnie wyłączone. Możemy przypisać serwer CA za pomocą server_tls_ca_file parametr. Jeśli chcielibyśmy przypisać klucz prywatny dla PgBouncera do uwierzytelnienia na serwerze PostgreSQL, możemy użyć server_tls_key_file parametr, możemy nawet przypisać certyfikat dla klucza prywatnego, który serwer PostgreSQL może zweryfikować za pomocą server_tls_cert_file parametr. Podobnie jak w przypadku ustawień połączenia TLS po stronie klienta, możemy zadeklarować, które wersje protokołu TLS są dozwolone za pomocą server_tls_protocols parametr.

• Po obsłudze TLS inną istotną nową funkcją jest obsługa uwierzytelniania „peer” na gniazdach uniksowych.

• Jako ostatnią ważną funkcję tej wersji chciałbym wspomnieć o obsłudze pliku kontroli dostępu opartego na hostach, takiego jak pg_hba.conf w Postgresie. Pozwala to skonfigurować TLS do połączeń sieciowych i uwierzytelniania „peer” dla połączeń lokalnych.

Możemy skonfigurować sposób uwierzytelniania użytkowników za pomocą auth_type parametr PgBouncera. Wszystkie parametry konfiguracyjne są zdefiniowane w pliku konfiguracyjnym pgbouncer.ini. Przyjrzyjmy się szczegółom auth_type parametr.

auth_type parametrowi można przypisać jedną z 6 wartości wymienionych poniżej. Zobaczmy wyjaśnienia i zastosowanie tych wartości.

• hba: Jeśli ustawimy parametr auth_type na wartość hba , powinniśmy ustawić auth_hba_file parametr również do pokazywania, który pg_hba.conf plik zostanie użyty jako konfiguracja. W ten sposób pozwalamy na załadowanie rzeczywistego typu uwierzytelniania z pliku auth_hba_file. Oznacza to, że możemy używać różnych metod uwierzytelniania dla różnych ścieżek dostępu. Na przykład w wersji 1.7 połączenie przez gniazdo Unix wykorzystuje metodę uwierzytelniania peer, w tym samym czasie połączenie przez TCP musi korzystać z TLS. Jak dotąd format pliku HBA nie obsługuje wszystkich metod uwierzytelniania pg_hba.conf. Obsługiwane metody to:zaufaj, odrzuć, md5, hasło, peer i cert.
• certyfikat: Klient musi łączyć się przez TLS połączenie z ważnym certyfikatem klienta. Nazwa użytkownika jest następnie pobierana z CommonName pole z certyfikatu.
• md5: Użyj sprawdzania hasła opartego na MD5. auth_file (nazwa pliku, z którego mają być wczytane nazwy użytkowników i hasła ) może zawierać zarówno hasła zaszyfrowane MD5, jak i hasła w postaci zwykłego tekstu. To jest domyślna metoda uwierzytelniania.
• zwykły: Hasło w postaci zwykłego tekstu jest przesyłane przewodowo. Przestarzałe.
• zaufanie: Brak uwierzytelnienia. Nazwa użytkownika musi nadal istnieć w auth_file .
• dowolne: Podobnie jak w przypadku metody zaufania, ale podana nazwa użytkownika jest ignorowana. Wymaga skonfigurowania wszystkich baz danych do logowania jako określony użytkownik. Dodatkowo baza danych konsoli pozwala każdemu użytkownikowi zalogować się jako administrator.

Inne błyszczące funkcje

W tej wersji dostępnych jest więcej funkcji. Możesz odwiedzić stronę dziennika zmian PgBouncer lub sprawdzić poniższą listę innych ulepszeń:

• Ustaw query_wait_timeout domyślnie do 120s. Ten parametr określa maksymalny czas, jaki zapytania mogą spędzić w oczekiwaniu na wykonanie. Jeśli w tym czasie zapytanie nie zostanie przypisane do serwera, klient zostanie rozłączony. Służy to zapobieganiu przechwytywania połączeń przez nieodpowiadające serwery. Pomaga również, gdy serwer nie działa lub baza danych odrzuca połączenia z jakiegokolwiek powodu. Jeśli ta opcja jest wyłączona, klienci będą ustawiani w kolejce w nieskończoność. Bieżące ustawienie domyślne (0) powoduje nieskończone kolejkowanie, co nie jest przydatne. W wersji 1.7, jeśli klient ma oczekujące zapytania i nie został przypisany do połączenia z serwerem, połączenie klienta zostanie domyślnie zerwane po 120 sekundach.
• Wyłącz server_reset_query_always domyślnie. Teraz zapytanie resetowania jest używane tylko w pulach, które są w trybie sesji.
• Zwiększ pkt_buf do 4096 bajtów. Poprawia wydajność z TLS . Zachowanie jest prawdopodobnie zależne od obciążenia, ale powinno być bezpieczne, ponieważ od wersji 1.2 bufory pakietów są rozdzielane od połączeń i leniwie używane z puli.
• Oczekiwana liczba potoków wsparcia ReadyForQuery pakiety. Pozwala to uniknąć zbyt wczesnego zwolnienia serwera. Poprawki #52.
• Poprawione sbuf_loopcnt logika — gwarantuje ponowne przetworzenie gniazda, nawet jeśli nie ma żadnego zdarzenia z gniazda. Wymagane dla TLS ponieważ ma własne buforowanie.
• Dostosuj testy systemu do pracy z nowoczesnym BSD i MacOS . (Eric Radman )
• Usuń kryptę autor. Jest przestarzały i nie jest obsługiwany przez PostgreSQL od 8.4 .
• Napraw zwykły „–z troską” opcja configure – bez argumentu była zepsuta.

Co to jest PgBouncer?

PgBouncer to narzędzie do zarządzania połączeniami klientów z bazą danych PostgreSQL. Krótko mówiąc, utrzymuje pulę połączeń z serwerem PostgreSQL i ponownie wykorzystuje istniejące połączenia. Chociaż może to być przydatne do zmniejszenia obciążenia połączenia klienta, umożliwia również ograniczenie maksymalnej liczby otwartych połączeń z serwerem bazy danych. Może być również używany do kształtowania ruchu, takiego jak przekierowywanie połączeń do jednej lub więcej baz danych na różne serwery baz danych. Oprócz tego PgBouncer może być używany do zarządzania bezpieczeństwem na poziomie użytkownika, a nawet bazy danych.

Możesz pobrać PgBouncer przez ich stronę pobierania i zacząć z niego korzystać już teraz!

Więcej informacji na temat PgBouncera można znaleźć w moim poprzednim wpisie na blogu o PgBouncer.

Miłego czytania!