HAProxy връзки срещу MySQL връзки - какво трябва да знаете

Наличието на балансьор на натоварване или обратен прокси пред вашия MySQL или MariaDB сървър добавя малко сложност към настройката на вашата база данни, което може да доведе до различни неща. Теоретично балансьорът на натоварване, който се намира пред MySQL сървърите (например HAProxy пред Galera Cluster) трябва просто да действа като мениджър на връзки и да разпределя връзките към сървърите на бекенда според някакъв алгоритъм за балансиране. MySQL, от друга страна, има свой собствен начин за управление на клиентски връзки. В идеалния случай ще трябва да конфигурираме тези два компонента заедно, за да избегнем неочаквано поведение и да стесним повърхността за отстраняване на неизправности при отстраняване на проблеми.

Ако имате такава настройка, важно е да разберете тези компоненти, тъй като те могат да повлияят на цялостната производителност на вашата услуга за база данни. В тази публикация в блога ще се потопим в max_connections на MySQL и HAProxy maxconn опции съответно. Имайте предвид, че времето за изчакване е друг важен параметър, който трябва да знаем, но ще разгледаме това в отделна публикация.

Максимален брой връзки на MySQL

Свързани ресурси Балансиране на натоварването на MySQL с HAProxy – Урок Възпроизвеждане на уебинар и въпроси и отговори:как да внедрите и управлявате ProxySQL, HAProxy и MaxScale Уебинар Повторение и слайдове:Как да изградите мащабируеми инфраструктури на база данни с MariaDB и HAProxy

Броят на връзките, разрешени към MySQL сървър, се контролира от max_connections системна променлива. Стойността по подразбиране е 151 (MySQL 5.7).

За да определите добър номер за max_connections , основните формули са:

Къде,

**Променлива innodb_additional_mem_pool_size се премахва в MySQL 5.7.4+. Ако използвате по-стара версия, вземете предвид тази променлива.

И,

Използвайки горните формули, можем да изчислим подходящ max_connections стойност за този конкретен MySQL сървър. За да стартирате процеса, спрете всички връзки от клиенти и рестартирайте MySQL сървъра. Уверете се, че имате само минималния брой процеси, работещи в този конкретен момент. Можете да използвате 'mysqladmin' или '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)

От горния изход можем да кажем, че само един потребител е свързан към MySQL сървъра, който е root. След това извлечете наличната RAM (в MB) на хоста (вижте под колоната „налично“):

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

Само за информация, колоната „налично“ дава приблизителна оценка колко памет е налична за стартиране на нови приложения, без размяна (достъпно само в ядрото 3.14+).

След това посочете наличната памет, 1928 MB в следния оператор:

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

От този пример можем да имаме до 265 MySQL връзки едновременно в зависимост от наличната RAM памет, която хостът разполага. Няма смисъл да конфигурирате по-висока стойност от тази. След това добавете следния ред в конфигурационния файл на MySQL под директивата [mysqld]:

max_connections = 265

Рестартирайте услугата MySQL, за да приложите промяната. Когато общият брой едновременни връзки достигне 265, ще получите грешка "Твърде много връзки", когато се опитвате да се свържете с mysqld сървъра. Това означава, че всички налични връзки се използват от други клиенти. MySQL всъщност позволява max_connections +1 клиенти за свързване. Допълнителната връзка е запазена за използване от акаунти, които имат привилегия SUPER. Така че, ако се сблъскате с тази грешка, трябва да опитате да получите достъп до сървъра като root потребител (или всеки друг SUPER потребител) и да погледнете списъка с процеси, за да започнете отстраняването на неизправности.

Максимален брой връзки на HAProxy

HAProxy има 3 типа максимални връзки (maxconn) - глобални, по подразбиране/слушане и сървър по подразбиране. Да приемем, че HAProxy екземпляр е конфигуриран с два слушателя, единият за слушане с множество записващи на порт 3307 (връзките се разпределят към всички сървъри на сървъра на MySQL), а друг е с единичен запис на порт 3308 (връзките се препращат към един 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]

Нека да разгледаме значението на някои от конфигурационните редове:

global.maxconn [a]

Общият брой едновременни връзки, на които е разрешено да се свързват към този HAProxy екземпляр. Обикновено тази стойност е най-високата стойност от всички. В този случай HAProxy ще приеме максимум 2000 връзки наведнъж и ще ги разпредели до всички слушатели, дефинирани в процеса на HAProxy, или работник (можете да стартирате множество HAProxy процеси с помощта на nbproc опция).

HAProxy ще спре да приема връзки, когато това ограничение бъде достигнато. Параметърът "ulimit-n" автоматично се настройва на тази стойност. Тъй като сокетите се считат за еквивалентни на файлове от системна гледна точка, ограничението на файловите дескриптори по подразбиране е доста малко. Вероятно ще искате да повишите лимита по подразбиране, като настроите ядрото за файлови дескриптори.

defaults.maxconn [b]

По подразбиране максималната стойност на връзките за всички слушатели. Няма смисъл, ако тази стойност е по-висока от global.maxconn .

Ако „maxconn“ липсва под строфа „listen“ (listen.maxconn ), слушателят ще се подчини на тази стойност. В този случай слушателят на mysql_3308 ще получи максимум 3 връзки наведнъж. За да сте в безопасност, задайте тази стойност равна на global.maxconn , разделено на броя на слушателите. Въпреки това, ако искате да дадете приоритет на други слушатели, за да имат повече връзки, използвайте listen.maxconn вместо това.

listen.maxconn [c]

Максималните разрешени връзки за съответния слушател. Слушателят има предимство пред defaults.maxconn ако е посочено. Няма смисъл, ако тази стойност е по-висока от global.maxconn .

За справедливо разпределение на връзките към бекенд сървъри, като в случая на слушател с множество записвания (mysql_3307), задайте тази стойност като listen.default-server.maxconn умножете по броя на бекенд сървърите. В този пример по-добра стойност трябва да бъде 12 вместо 8 [c]. Ако изберем да се придържаме към тази конфигурация, се очаква db1 и db2 да получат максимум 3 връзки всяка, докато db3 ще получи максимум 2 връзки (поради най-малкото балансиране на conn), което възлиза на общо 8 връзки. Няма да достигне ограничението, посочено в [d].

За слушател с един запис (mysql_3308), където връзките трябва да бъдат разпределени към един и само един бекенд сървър в даден момент, задайте тази стойност да бъде същата или по-висока от listen.default-server.maxconn .

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

Това е максималният брой връзки, които всеки бекенд сървър може да получи наведнъж. Няма смисъл, ако тази стойност е по-висока от listen.maxconn или defaults.maxconn . Тази стойност трябва да е по-ниска или равна на max_connections на MySQL променлива. В противен случай рискувате да изчерпите връзките към задния MySQL сървър, особено когато променливите за изчакване на MySQL са конфигурирани по-ниски от изчакванията на HAProxy.

В този пример сме настроили всеки MySQL сървър да получава само максимум 4 връзки наведнъж за възли на Galera с множество записващи устройства [d]. Докато възелът Galera с един запис ще получи максимум 3 връзки наведнъж, поради ограничението, което се прилага от [b]. Тъй като посочихме „backup“ [f] на другия възел, активният възел ще получи наведнъж всичките 3 връзки, разпределени на този слушател.

Горното обяснение може да бъде илюстрирано на следната диаграма:

За да обобщим разпределението на връзките, се очаква db1 да получи максимален брой от 6 връзки (3 от 3307 + 3 от 3308). db2 ще получи 3 връзки (освен ако db1 падне, където ще получи допълнителни 3), а db3 ще се придържа към 2 връзки, независимо от промените в топологията в клъстера.

Наблюдение на връзката с ClusterControl

С ClusterControl можете да наблюдавате използването на MySQL и HAProxy връзка от потребителския интерфейс. Следната екранна снимка предоставя обобщение на съветника за свързване на MySQL (ClusterControl -> Performance -> Advisors), където той следи текущите и използваните някога MySQL връзки за всеки сървър в клъстера:

За HAProxy ClusterControl се интегрира със страницата със статистически данни на HAProxy, за да събира показатели. Те са представени в раздела Възли:

От горната екранна снимка можем да кажем, че всеки бекенд сървър на слушател с множество записвания получава максимум 8 връзки. Текат 4 едновременни сесии. Те са подчертани в горния червен квадрат, докато слушателят с единичен запис обслужва 2 връзки и ги препраща съответно към един възел.

Заключение

Конфигурирането на максимални връзки за HAProxy и MySQL сървър е важно, за да се осигури добро разпределение на натоварването към нашите сървъри на бази данни и да се защитят MySQL сървърите от претоварване или изчерпване на връзките му.