Połączenia HAProxy a połączenia MySQL — co powinieneś wiedzieć

Posiadanie modułu równoważenia obciążenia lub zwrotnego serwera proxy przed serwerem MySQL lub MariaDB nieco komplikuje konfigurację bazy danych, co może prowadzić do tego, że niektóre rzeczy będą zachowywać się inaczej. Teoretycznie load balancer, który znajduje się przed serwerami MySQL (na przykład HAProxy przed Galera Cluster) powinien działać jak menedżer połączeń i dystrybuować połączenia do serwerów zaplecza zgodnie z jakimś algorytmem równoważenia. Z drugiej strony MySQL ma swój własny sposób zarządzania połączeniami klientów. Idealnie byłoby, gdybyśmy musieli skonfigurować te dwa komponenty razem, aby uniknąć nieoczekiwanych zachowań i zawęzić obszar rozwiązywania problemów podczas debugowania problemów.

Jeśli masz taką konfigurację, ważne jest, aby zrozumieć te składniki, ponieważ mogą one wpływać na ogólną wydajność usługi bazy danych. W tym poście na blogu zagłębimy się w max_connections w MySQL i HAProxy maxconn opcje odpowiednio. Pamiętaj, że limit czasu to kolejny ważny parametr, o którym powinniśmy wiedzieć, ale omówimy to w osobnym poście.

Maksymalne połączenia MySQL

Liczba połączeń dozwolonych do serwera MySQL jest kontrolowana przez max_connections zmienna systemowa. Domyślna wartość to 151 (MySQL 5.7).

Aby określić dobrą liczbę dla max_connections , podstawowe formuły to:

Gdzie,

**Zmienna innodb_additional_mem_pool_size została usunięta w MySQL 5.7.4+. Jeśli używasz starszej wersji, weź tę zmienną pod uwagę.

I,

Korzystając z powyższych wzorów, możemy obliczyć odpowiednie max_connections wartość dla tego konkretnego serwera MySQL. Aby rozpocząć proces, zatrzymaj wszystkie połączenia od klientów i zrestartuj serwer MySQL. Upewnij się, że masz tylko minimalną liczbę uruchomionych procesów w danym momencie. W tym celu możesz użyć „mysqladmin” lub „SHOW PROCESSLIST”:

$ mysqladmin -uroot -p processlist
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| Id     | User | Host      | db   | Command | Time | State | Info             | Progress |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| 232172 | root | localhost | NULL | Query   |    0 | NULL  | show processlist |    0.000 |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
1 row in set (0.00 sec)

Z powyższego wyniku możemy stwierdzić, że tylko jeden użytkownik jest podłączony do serwera MySQL, który jest rootem. Następnie pobierz dostępną pamięć RAM (w MB) hosta (spójrz w kolumnie „dostępne”):

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3778        1427         508         148        1842        1928
Swap:          2047           4        2043

Tylko dla informacji, kolumna „dostępna” podaje szacunkową ilość pamięci dostępnej do uruchamiania nowych aplikacji, bez wymiany (dostępne tylko w jądrze 3.14+).

Następnie określ dostępną pamięć, 1928 MB w następującym oświadczeniu:

mysql> SELECT ROUND((1928 - (ROUND((@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@query_cache_size + @@tmp_table_size + @@key_buffer_size) / 1024 / 1024))) / (ROUND(@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@thread_stack + @@join_buffer_size + @@binlog_cache_size) / 1024 / 1024)) AS 'Possible Max Connections';
+--------------------------+
| Possible Max Connections |
+--------------------------+
|                      265 |
+--------------------------+

**Zmienna innodb_additional_mem_pool_size została usunięta w MySQL 5.7.4+. Jeśli używasz starszej wersji, weź tę zmienną pod uwagę.

W tym przykładzie możemy mieć jednocześnie do 265 połączeń MySQL, zgodnie z dostępną pamięcią RAM hosta. Nie ma sensu konfigurować wyższej wartości. Następnie dołącz następujący wiersz w pliku konfiguracyjnym MySQL, pod dyrektywą [mysqld]:

max_connections = 265

Uruchom ponownie usługę MySQL, aby zastosować zmianę. Gdy łączna liczba jednoczesnych połączeń osiągnie 265, otrzymasz błąd „Zbyt wiele połączeń” podczas próby połączenia z serwerem mysqld. Oznacza to, że wszystkie dostępne połączenia są używane przez innych klientów. MySQL faktycznie zezwala na max_connections +1 klientów do połączenia. Dodatkowe połączenie jest zarezerwowane dla kont z uprawnieniem SUPER. Więc jeśli napotkasz ten błąd, powinieneś spróbować uzyskać dostęp do serwera jako użytkownik root (lub dowolny inny użytkownik SUPER) i spojrzeć na listę procesów, aby rozpocząć rozwiązywanie problemów.

Maksymalna liczba połączeń HAProxy

HAProxy posiada 3 typy połączeń max (maxconn) - globalne, defaults/listen i default-server. Załóżmy, że instancja HAProxy jest skonfigurowana z dwoma odbiornikami, jednym nasłuchiwaniem przez wiele zapisów na porcie 3307 (połączenia są dystrybuowane do wszystkich serwerów zaplecza MySQL), a drugim jest pojedynczy zapis na porcie 3308 (połączenia są przekazywane do pojedynczego serwera MySQL):

global
    ...
    maxconn 2000 #[a]
    ...
defaults
    ...
    maxconn 3 #[b]
    ...
listen mysql_3307
    ...
    maxconn 8 #[c]
    balance leastconn
    default-server port 9200 maxqueue 10 weight 10 maxconn 4 #[d]
    server db1 192.168.55.171 check
    server db2 192.168.55.172 check
    server db3 192.168.55.173 check
listen mysql_3308
    ...
    default-server port 9200 maxqueue 10 weight 10 maxconn 5 #[e]
    server db1 192.168.55.171 check
    server db2 192.168.55.172 check backup #[f]

Przyjrzyjmy się znaczeniu niektórych linii konfiguracyjnych:

global.maxconn [a]

Łączna liczba jednoczesnych połączeń, które mogą łączyć się z tą instancją HAProxy. Zwykle ta wartość jest najwyższą wartością ze wszystkich. W takim przypadku HAProxy zaakceptuje jednocześnie maksymalnie 2000 połączeń i roześle je do wszystkich słuchaczy zdefiniowanych w procesie HAProxy lub roboczym (możesz uruchomić wiele procesów HAProxy za pomocą nbproc opcja).

HAProxy przestanie akceptować połączenia po osiągnięciu tego limitu. Parametr „ulimit-n” jest automatycznie dopasowywany do tej wartości. Ponieważ gniazda są uważane za równoważne plikom z perspektywy systemu, domyślny limit deskryptorów plików jest raczej niewielki. Prawdopodobnie będziesz chciał podnieść domyślny limit, dostrajając jądro pod kątem deskryptorów plików.

defaults.maxconn [b]

Domyślna maksymalna wartość połączeń dla wszystkich słuchaczy. Nie ma sensu, jeśli ta wartość jest wyższa niż global.maxconn .

Jeśli w sekcji „listen” brakuje wiersza „maxconn” (listen.maxconn ), słuchacz będzie przestrzegać tej wartości. W tym przypadku słuchacz mysql_3308 uzyska jednocześnie maksymalnie 3 połączenia. Aby być bezpiecznym, ustaw tę wartość na global.maxconn , podzielone przez liczbę słuchaczy. Jeśli jednak chcesz nadać priorytet innym słuchaczom, aby mieć więcej połączeń, użyj listen.maxconn zamiast tego.

słuchaj.maxconn [c]

Maksymalna liczba połączeń dozwolonych dla odpowiedniego odbiornika. Odbiornik ma pierwszeństwo przed defaults.maxconn jeśli określono. Nie ma sensu, jeśli ta wartość jest wyższa niż global.maxconn .

Aby uzyskać sprawiedliwą dystrybucję połączeń do serwerów zaplecza, jak w przypadku programu nasłuchującego z wieloma zapisami (mysql_3307), ustaw tę wartość jako listen.default-server.maxconn pomnóż przez liczbę serwerów zaplecza. W tym przykładzie lepszą wartością powinno być 12 zamiast 8 [c]. Jeśli zdecydujemy się pozostać przy tej konfiguracji, oczekuje się, że db1 i db2 otrzymają maksymalnie 3 połączenia, podczas gdy db3 otrzyma maksymalnie 2 połączenia (ze względu na równoważenie najmniejszych połączeń), co w sumie daje 8 połączeń. Nie osiągnie limitu określonego w [d].

W przypadku programu nasłuchującego z jednym zapisem (mysql_3308), w którym połączenia powinny być przydzielane do jednego i tylko jednego serwera zaplecza naraz, ustaw tę wartość na taką samą lub wyższą niż listen.default-server.maxconn .

listen.default-server.maxconn [d][e]

Jest to maksymalna liczba połączeń, jaką może odbierać jednocześnie każdy serwer zaplecza. Nie ma sensu, jeśli ta wartość jest wyższa niż listen.maxconn lub defaults.maxconn . Ta wartość powinna być mniejsza lub równa max_connections MySQL'a zmienny. W przeciwnym razie ryzykujesz wyczerpanie połączeń z serwerem zaplecza MySQL, zwłaszcza gdy zmienne limitu czasu MySQL są skonfigurowane na mniej niż limity czasu HAProxy.

W tym przykładzie ustawiliśmy każdy serwer MySQL tak, aby jednocześnie uzyskiwał maksymalnie 4 połączenia dla węzłów Galera z wieloma zapisami [d]. Podczas gdy węzeł Galera z jednym zapisem otrzyma jednocześnie maksymalnie 3 połączenia, ze względu na limit, który obowiązuje od [b]. Ponieważ określiliśmy "backup" [f] dla drugiego węzła, aktywny węzeł od razu otrzyma wszystkie 3 połączenia przydzielone temu słuchaczowi.

Powyższe wyjaśnienie można zilustrować następującym diagramem:

Podsumowując rozkład połączeń, oczekuje się, że db1 otrzyma maksymalnie 6 połączeń (3 z 3307 + 3 z 3308). db2 otrzyma 3 połączenia (chyba że db1 przestanie działać, wtedy otrzyma dodatkowe 3), a db3 będzie trzymać się 2 połączeń niezależnie od zmian topologii w klastrze.

Monitorowanie połączeń za pomocą ClusterControl

Dzięki ClusterControl możesz monitorować wykorzystanie połączeń MySQL i HAProxy z poziomu interfejsu użytkownika. Poniższy zrzut ekranu zawiera podsumowanie doradcy połączenia MySQL (ClusterControl -> Performance -> Advisors), gdzie monitoruje bieżące i zawsze używane połączenia MySQL dla każdego serwera w klastrze:

W przypadku HAProxy, ClusterControl integruje się ze stroną statystyk HAProxy w celu zbierania metryk. Są one prezentowane w zakładce Węzły:

Z powyższego zrzutu ekranu możemy powiedzieć, że każdy serwer zaplecza na odbiorniku multi-writer otrzymuje maksymalnie 8 połączeń. Działają 4 równoczesne sesje. Są one podświetlone w górnym czerwonym kwadracie, podczas gdy słuchacz z jednym zapisem obsługuje 2 połączenia i przekazuje je odpowiednio do jednego węzła.

Wniosek

Skonfigurowanie maksymalnej liczby połączeń dla serwera HAProxy i MySQL jest ważne, aby zapewnić dobre rozłożenie obciążenia na nasze serwery baz danych i chronić serwery MySQL przed przeciążeniem lub wyczerpaniem połączeń.