Připojení HAProxy vs připojení MySQL - Co byste měli vědět

Mít vyrovnávání zátěže nebo reverzní proxy před serverem MySQL nebo MariaDB trochu komplikuje nastavení databáze, což může vést k tomu, že se některé věci budou chovat jinak. Teoreticky by měl load balancer, který je umístěn před servery MySQL (například HAProxy před Galera Cluster), fungovat jako správce připojení a distribuovat připojení k backendovým serverům podle nějakého vyvažovacího algoritmu. Na druhou stranu MySQL má svůj vlastní způsob správy klientských připojení. V ideálním případě bychom potřebovali nakonfigurovat tyto dvě součásti společně, abychom se vyhnuli neočekávanému chování a zúžili plochu pro odstraňování problémů při ladění problémů.

Pokud máte takové nastavení, je důležité porozumět těmto komponentám, protože mohou ovlivnit celkový výkon vaší databázové služby. V tomto příspěvku na blogu se ponoříme do max_connections MySQL a HAProxy maxconn možnosti resp. Všimněte si, že časový limit je dalším důležitým parametrem, který bychom měli znát, ale tomu se budeme věnovat v samostatném příspěvku.

Maximální počet připojení MySQL

Počet povolených připojení k serveru MySQL je řízen parametrem max_connections systémová proměnná. Výchozí hodnota je 151 (MySQL 5.7).

Chcete-li určit dobrý počet pro max_connections , základní vzorce jsou:

Kde,

**Proměnná innodb_additional_mem_pool_size je odstraněn v MySQL 5.7.4+. Pokud používáte starší verzi, vezměte tuto proměnnou v úvahu.

A,

Pomocí výše uvedených vzorců můžeme vypočítat vhodný max_connections hodnotu pro tento konkrétní server MySQL. Chcete-li zahájit proces, zastavte všechna připojení z klientů a restartujte server MySQL. Ujistěte se, že v daný okamžik běží pouze minimální počet procesů. Pro tento účel můžete použít 'mysqladmin' nebo '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 výše uvedeného výstupu můžeme říci, že pouze jeden uživatel je připojen k serveru MySQL, což je root. Poté načtěte dostupnou RAM (v MB) hostitele (podívejte se do sloupce 'available'):

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

Jen pro informaci, sloupec 'available' uvádí odhad toho, kolik paměti je k dispozici pro spouštění nových aplikací, bez swapování (dostupné pouze v jádře 3.14+).

Poté zadejte dostupnou paměť, 1928 MB, v následujícím příkazu:

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 |
+--------------------------+

**Proměnná innodb_additional_mem_pool_size je odstraněn v MySQL 5.7.4+. Pokud používáte starší verzi, vezměte tuto proměnnou v úvahu.

Z tohoto příkladu můžeme mít až 265 připojení MySQL současně podle dostupné paměti RAM hostitele. Nemá smysl konfigurovat vyšší hodnotu. Poté přidejte následující řádek do konfiguračního souboru MySQL pod direktivou [mysqld]:

max_connections = 265

Chcete-li použít změnu, restartujte službu MySQL. Když celkový počet současných připojení dosáhne 265, zobrazí se při pokusu o připojení k serveru mysqld chyba „Příliš mnoho připojení“. To znamená, že všechna dostupná připojení jsou používána ostatními klienty. MySQL ve skutečnosti povoluje max_connections +1 klientům pro připojení. Další připojení je vyhrazeno pro použití účty, které mají oprávnění SUPER. Pokud tedy narazíte na tuto chybu, měli byste se pokusit o přístup k serveru jako uživatel root (nebo jakýkoli jiný SUPER uživatel) a podívat se na seznam procesů, abyste mohli začít s odstraňováním problémů.

Maximální počet připojení HAProxy

HAProxy má 3 typy maximálních připojení (maxconn) – globální, výchozí/naslouchat a výchozí-server. Předpokládejme, že instance HAProxy je konfigurována se dvěma posluchači, jedním pro naslouchání s více zapisovacími jednotkami na portu 3307 (připojení jsou distribuována na všechny backendové servery MySQL) a další je s jedním zapisovačem na portu 3308 (připojení jsou předávána na jeden server 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]

Podívejme se na význam některých konfiguračních řádků:

global.maxconn [a]

Celkový počet souběžných připojení, která se mohou připojit k této instanci HAProxy. Obvykle je tato hodnota nejvyšší ze všech. V tomto případě HAProxy přijme maximálně 2000 připojení najednou a rozdělí je všem posluchačům definovaným v procesu HAProxy nebo workeru (můžete spustit více procesů HAProxy pomocí nbproc možnost).

Po dosažení tohoto limitu přestane HAProxy přijímat připojení. Parametr "ulimit-n" se automaticky přizpůsobí této hodnotě. Vzhledem k tomu, že sokety jsou z pohledu systému považovány za ekvivalentní souborům, výchozí limit deskriptorů souborů je poměrně malý. Pravděpodobně budete chtít zvýšit výchozí limit vyladěním jádra pro deskriptory souborů.

defaults.maxconn [b]

Výchozí hodnota maximálního připojení pro všechny posluchače. Pokud je tato hodnota vyšší než global.maxconn, nedává to smysl .

Pokud ve stanze "listen" chybí řádek "maxconn" (listen.maxconn ), posluchač se této hodnotě podřídí. V tomto případě posluchač mysql_3308 získá maximálně 3 připojení najednou. Pro jistotu nastavte tuto hodnotu na global.maxconn , děleno počtem posluchačů. Pokud však chcete upřednostnit ostatní posluchače, aby měli více připojení, použijte listen.maxconn místo toho.

listen.maxconn [c]

Maximální povolená připojení pro odpovídající posluchač. Posluchač má přednost před defaults.maxconn pokud je uvedeno. Pokud je tato hodnota vyšší než global.maxconn, nedává to smysl .

Pro spravedlivou distribuci připojení k backendovým serverům, jako v případě naslouchacího modulu pro více zápisů (mysql_3307), nastavte tuto hodnotu jako listen.default-server.maxconn vynásobte počtem backendových serverů. V tomto příkladu by lepší hodnota měla být 12 místo 8 [c]. Pokud se rozhodneme zůstat u této konfigurace, očekává se, že db1 a db2 obdrží každý maximálně 3 připojení, zatímco db3 obdrží maximálně 2 připojení (kvůli vyvažování nejmenších připojení), což znamená celkem 8 připojení. Nedosáhne limitu uvedeného v [d].

Pro single-writer listener (mysql_3308), kde by připojení měla být alokována vždy pouze jednomu backend serveru, nastavte tuto hodnotu na stejnou nebo vyšší hodnotu než listen.default-server.maxconn .

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

Toto je maximální počet připojení, které může každý backend server přijmout najednou. Pokud je tato hodnota vyšší než listen.maxconn, nedává to smysl nebo defaults.maxconn . Tato hodnota by měla být nižší nebo rovna max_connections MySQL variabilní. V opačném případě riskujete vyčerpání připojení k backendovému serveru MySQL, zvláště když jsou proměnné časového limitu MySQL nakonfigurovány nižší než časové limity HAProxy.

V tomto příkladu jsme nastavili každý server MySQL tak, aby získal maximálně 4 připojení najednou pro uzly Galera s více zapisovači [d]. Zatímco uzel Galera s jedním zápisem získá maximálně 3 připojení najednou, kvůli limitu, který platí od [b]. Protože jsme druhému uzlu zadali "backup" [f], aktivní uzel okamžitě získá všechna 3 připojení přidělená tomuto posluchači.

Výše uvedené vysvětlení lze ilustrovat na následujícím diagramu:

Abychom shrnuli distribuci připojení, očekává se, že db1 získá maximální počet 6 připojení (3 z 3307 + 3 z 3308). db2 získá 3 připojení (pokud nedojde k výpadku db1, kde získá další 3) a db3 zůstane u 2 připojení bez ohledu na změny topologie v klastru.

Monitorování připojení pomocí ClusterControl

Pomocí ClusterControl můžete sledovat využití připojení MySQL a HAProxy z uživatelského rozhraní. Následující snímek obrazovky poskytuje shrnutí poradce připojení MySQL (ClusterControl -> Performance -> Advisors), kde monitoruje aktuální a někdy používaná připojení MySQL pro každý server v clusteru:

Pro HAProxy se ClusterControl integruje se statickou stránkou HAProxy a shromažďuje metriky. Ty jsou uvedeny na kartě Nodes:

Z výše uvedeného snímku obrazovky můžeme říci, že každý backendový server na multi-writer listener získá maximálně 8 připojení. Probíhají 4 souběžné relace. Ty jsou zvýrazněny v horním červeném čtverci, zatímco posluchač s jedním zápisem obsluhuje 2 připojení a přesměrovává je do jednoho uzlu.

Závěr

Konfigurace maximálního počtu připojení pro server HAProxy a MySQL je důležitá pro zajištění dobrého rozložení zátěže na naše databázové servery a pro ochranu serverů MySQL před přetížením nebo vyčerpáním jejich připojení.