ProxySQL е добре познат инструмент за балансиране на натоварването в света на MySQL – идва с страхотен набор от функции, които ви позволяват да поемете контрола над трафика си и да го оформите, както сметнете за подходящ. Може да бъде разгърнат по много различни начини - специални възли, разположени заедно с хостове на приложения, силозен подход - всичко зависи от точната среда и бизнес изискванията. Общото предизвикателство е, че вие в повечето случаи искате вашите ProxySQL възли да съдържат същата конфигурация. Ако мащабирате своя клъстер и добавите нов сървър към ProxySQL, искате този сървър да бъде видим на всички екземпляри на ProxySQL, а не само на активния. Това води до въпроса - как да се уверите, че поддържате конфигурацията в синхрон във всички ProxySQL възли?
Можете да опитате да актуализирате всички възли на ръка, което определено не е ефективно. Можете също да използвате някакъв вид инструменти за оркестриране на инфраструктура като Ansible или Chef, за да поддържате конфигурацията на възлите в известно състояние, като правите модификациите не директно в ProxySQL, а чрез инструмента, който използвате за организиране на вашата среда.
Ако случайно използвате ClusterControl, той идва с набор от функции, които ви позволяват да синхронизирате конфигурацията между екземпляри на ProxySQL, но това решение има своите недостатъци - това е ръчно действие, трябва да запомните да изпълнете го след промяна на конфигурацията. Ако забравите да направите това, може да бъдете до неприятна изненада, ако например keepalived премести виртуалния IP адрес към неактуализирания екземпляр на ProxySQL.
Нито един от тези методи не е прост или 100% надежден и ситуацията е, когато възлите на ProxySQL имат различни конфигурации и може да са потенциално опасни.
За щастие ProxySQL идва с решение за този проблем - ProxySQL Cluster. Идеята е доста проста - можете да дефинирате списък с ProxySQL екземпляри, които ще разговарят помежду си и ще информират другите за версията на конфигурацията, която всяка от тях съдържа. Конфигурацията е версия, така че всяка промяна на която и да е настройка на всеки възел ще доведе до увеличаване на версията на конфигурацията - това задейства синхронизирането на конфигурацията и новата версия на конфигурацията се разпространява и прилага във всички възли, които образуват ProxySQL клъстера.
Последната версия на ClusterControl ви позволява да настроите ProxySQL клъстери без усилие. Когато разгръщате ProxySQL, трябва да поставите отметка до опцията „Използване на собствени клъстери“ за всички възли, които искате да бъдат част от клъстера.
След като го направите, сте почти готови - останалото се случва под качулката.
MySQL [(none)]> select * from proxysql_servers;
+------------+------+--------+----------------+
| hostname | port | weight | comment |
+------------+------+--------+----------------+
| 10.0.0.131 | 6032 | 0 | proxysql_group |
| 10.0.0.132 | 6032 | 0 | proxysql_group |
+------------+------+--------+----------------+
2 rows in set (0.001 sec)И на двата сървъра таблицата proxysql_servers е зададена правилно с имената на хостовете на възлите, които образуват клъстера. Можем също така да проверим дали промените в конфигурацията са правилно разпространени в клъстера:
Увеличихме настройката за максимални връзки на един от възлите на ProxySQL (10.0 .0.131) и можем да проверим, че другият възел (10.0.0.132) ще види същата конфигурация:
В случай на необходимост от отстраняване на грешки в процеса, винаги можем да потърсим дневника на ProxySQL (обикновено се намира в /var/lib/proxysql/proxysql.log), където ще видим информация като тази:
2020-11-26 13:40:47 [INFO] Cluster: detected a new checksum for mysql_servers from peer 10.0.0.131:6032, version 11, epoch 1606398059, checksum 0x441378E48BB01C61 . Not syncing yet ...
2020-11-26 13:40:49 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 3. Own version: 9, epoch: 1606398022. Proceeding with remote sync
2020-11-26 13:40:50 [INFO] Cluster: detected a peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060, diff_check 4. Own version: 9, epoch: 1606398022. Proceeding with remote sync
2020-11-26 13:40:50 [INFO] Cluster: detected peer 10.0.0.131:6032 with mysql_servers version 12, epoch 1606398060
2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 started. Expected checksum 0x441378E48BB01C61
2020-11-26 13:40:50 [INFO] Cluster: Fetching MySQL Servers from peer 10.0.0.131:6032 completed
2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 before proceessing
2020-11-26 13:40:50 [INFO] Cluster: Fetching checksum for MySQL Servers from peer 10.0.0.131:6032 successful. Checksum: 0x441378E48BB01C61
2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_servers table
2020-11-26 13:40:50 [INFO] Cluster: Writing mysql_replication_hostgroups table
2020-11-26 13:40:50 [INFO] Cluster: Loading to runtime MySQL Servers from peer 10.0.0.131:6032Това е регистрационният файл от 10.0.0.132, където можем ясно да видим, че промяна в конфигурацията за таблица mysql_servers е открита на 10.0.0.131 и след това тя е синхронизирана и приложена на 10.0.0.132, правейки я синхронизирана с другия възел в клъстера.
Както можете да видите, клъстерирането на ProxySQL е лесен, но ефективен начин да се гарантира, че конфигурацията му остава в синхрон и помага значително за използване на по-големи внедрявания на ProxySQL. Кажете ни в коментарите какъв е вашият опит с ProxySQL клъстерирането.
