Прокси слой между приложения и бази данни обикновено се състои от множество прокси възли за висока наличност. Това не е различно за ProxySQL. ProxySQL, подобно на други съвременни прокси сървъри, може да се използва за изграждане на сложна логика за маршрутизиране на заявки. Можете да добавяте правила за заявки, за да изпращате заявки до определени хостове, можете да кеширате заявки, можете да добавяте и премахвате бекенд сървъри или да управлявате потребители, на които е разрешено да се свързват с ProxySQL и MySQL. Въпреки това многобройните възли на ProxySQL в прокси слоя въвеждат друг проблем - синхронизация между разпределени инстанции. Всички правила или друга логика трябва да бъдат синхронизирани между екземпляри, за да се гарантира, че се държат по същия начин. Дори ако не всички прокси сървъри обработват трафик, те все още работят като резервни. В случай, че те трябва да поемат работата, не искате изненади, ако използваният екземпляр няма последните промени в конфигурацията.
Доста е тромаво да осигурите това ръчно - да направите промените на ръка на всички възли. Можете да използвате инструменти като Ansible, Chef или Puppet за управление на конфигурации, но процесът на синхронизиране трябва да бъде кодиран и тестван. ClusterControl може да ви помогне тук чрез опция за синхронизиране на конфигурации между екземпляри на ProxySQL, но също така може да настрои и управлява другите компоненти, необходими за висока наличност, например виртуален IP. Но започвайки от версия 1.4.2, ProxySQL предлага вграден механизъм за клъстериране и синхронизиране на конфигурацията. В тази публикация в блога ще обсъдим как да го настроим с комбинация от действия, предприети в администраторския интерфейс на командния ред на ClusterControl и ProxySQL.
Първо, нека да разгледаме типична среда за репликация, внедрена от ClusterControl.
Както можете да видите от екранната снимка, това е настройка за репликация на MySQL с три екземпляра на ProxySQL. Високата наличност на ProxySQL се реализира чрез Keepalived и Virtual IP, който винаги се присвоява на един от възлите на ProxySQL. Има няколко стъпки, които трябва да предприемем, за да конфигурираме ProxySQL клъстерирането. Първо, трябва да дефинираме кой потребител ProxySQL трябва да използва за обмен на информация между възлите. Нека дефинираме нов върху съществуващия администратор:
След това трябва да дефинираме този потребител в настройките на admin-cluster_password и admin-cluster_username.
Това е направено само на един от възлите (10.0.0.126). Нека синхронизираме тази промяна в конфигурацията с останалите ProxySQL възли.
Както казахме, ClusterControl ви позволява да синхронизирате конфигурацията между възлите на ProxySQL само с няколко стъпки. Когато задачата приключи синхронизирането на 10.0.0.127 с 10.0.0.126, остава само последният възел, който трябва да синхронизираме.
След това трябва да направим малка промяна в интерфейса на административния команден ред на ProxySQL, който обикновено е достъпен на порт 6032. Трябва да създадем записи в таблицата 'proxysql_servers', която да дефинира възлите в нашия ProxySQL клъстер.
mysql> INSERT INTO proxysql_servers (hostname) VALUES ('10.0.0.126'), ('10.0.0.127'), ('10.0.0.128');
Query OK, 3 rows affected (0.00 sec)mysql> LOAD PROXYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE PROXYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.01 sec)След зареждане на промяната в времето за изпълнение, ProxySQL трябва да започне да синхронизира възлите. Има няколко места, където можете да проследявате състоянието на клъстера.
mysql> SELECT * FROM stats_proxysql_servers_checksums;
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| hostname | port | name | version | epoch | checksum | changed_at | updated_at | diff_check |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| 10.0.0.128 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_query_rules | 2 | 1539772933 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_servers | 4 | 1539772933 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_users | 2 | 1539772933 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | proxysql_servers | 2 | 1539773835 | 0x8EB13E2B48C3FDB0 | 1539773835 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_query_rules | 3 | 1539773719 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_servers | 5 | 1539773719 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_users | 3 | 1539773719 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | proxysql_servers | 2 | 1539773812 | 0x8EB13E2B48C3FDB0 | 1539773813 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_query_rules | 1 | 1539770578 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_servers | 3 | 1539771053 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_users | 1 | 1539770578 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | proxysql_servers | 2 | 1539773546 | 0x8EB13E2B48C3FDB0 | 1539773546 | 1539773916 | 0 |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
18 rows in set (0.00 sec)Таблицата stats_proxysql_servers_checksums съдържа, наред с другото, списък с възли в клъстера, таблици, които са синхронизирани, версии и контролна сума на таблицата. Ако контролната сума не е на линия, ProxySQL ще се опита да получи най-новата версия от партньор на клъстера. По-подробна информация за съдържанието на тази таблица може да бъде намерена в документацията на ProxySQL.
Друг източник на информация за процеса е дневникът на ProxySQL (по подразбиране той се намира в /var/lib/proxysql/proxysql.log).
2018-10-17 11:00:25 [INFO] Cluster: detected a new checksum for mysql_query_rules from peer 10.0.0.126:6032, version 2, epoch 1539774025, checksum 0xD615D5416F61AA72 . Not syncing yet …
2018-10-17 11:00:27 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 3. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 4. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 started
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 completed
2018-10-17 11:00:28 [INFO] Cluster: Loading to runtime MySQL Query Rules from peer 10.0.0.126:6032
2018-10-17 11:00:28 [INFO] Cluster: Saving to disk MySQL Query Rules from peer 10.0.0.126:6032Както можете да видите, тук имаме информация, че е открита нова контролна сума и процесът на синхронизиране е на място.
Нека спрем за момент тук и да обсъдим как ProxySQL обработва актуализации на конфигурацията от множество източници. На първо място, ProxySQL проследява контролните суми, за да открие кога конфигурацията се е променила. Той също така съхранява кога се е случило - тези данни се съхраняват като времева марка, така че имат една секунда разделителна способност. ProxySQL има две променливи, които също оказват влияние върху това как се синхронизират промените.
Cluster_check_interval_ms - определя колко често ProxySQL трябва да проверява за промени в конфигурацията. По подразбиране е 1000 мс.
Cluster_mysql_servers_diffs_before_sync - той ни казва колко пъти една проверка трябва да открие промяна в конфигурацията, преди да бъде синхронизирана. Настройката по подразбиране е 3.
Това означава, че дори ако ще направите промяна в конфигурацията на същия хост, ако я направите по-рядко от 4 секунди, останалите ProxySQL възли може да не успеят да го синхронизират, защото нова промяна ще се появи преди предишната беше синхронизиран. Това също така означава, че ако направите промени в конфигурацията на множество екземпляри на ProxySQL, трябва да ги направите с поне 4 секунди прекъсване между тях, тъй като в противен случай някои от промените ще бъдат загубени и в резултат конфигурациите ще се разминават. Например добавяте Server1 към Proxy1 и след 2 секунди добавяте Server2 към Proxy2. Всички други прокси сървъри ще отхвърлят промяната на Proxy1, защото ще открият, че Proxy2 има по-нова конфигурация. 4 секунди след промяната на Proxy2, всички прокси сървъри (включително Proxy1) ще изтеглят конфигурацията от Proxy2.
Тъй като комуникацията в клъстера не е синхронна и ако ProxySQL възел, който сте направили промените, е неуспешен, промените може да не бъдат репликирани навреме. Най-добрият подход е да направите същата промяна на два ProxySQL възела. По този начин, освен ако и двете не успеят точно по едно и също време, един от тях ще може да разпространи нова конфигурация.
Също така си струва да се отбележи, че топологията на клъстера ProxySQL може да бъде доста гъвкава. В нашия случай имаме три възела, всички имат по три записа в таблицата proxysql_servers. Такива възли образуват клъстера, където можете да пишете на всеки възел и промените ще бъдат разпространени. Освен това е възможно да се добавят външни възли, които да работят в режим „само за четене“, което означава, че те само ще синхронизират промените, направени в „основния“ клъстер, но няма да разпространяват промени, които са били извършени директно върху себе си. Всичко, от което се нуждаете на новия възел, е да имате само „основните“ възли на клъстера, конфигурирани в proxysql_servers и в резултат на това той ще се свърже с тези възли и ще получи промените в данните, но няма да бъде запитан от останалата част от клъстера за промените в конфигурацията му. Тази настройка може да се използва за създаване на източник на истина с няколко възли в клъстера и други възли на ProxySQL, които просто получават конфигурацията от основния „ядро“ клъстер.
В допълнение към всичко това, ProxySQL клъстерът поддържа автоматично повторно присъединяване на възлите - те ще синхронизират конфигурацията си при стартиране. Може също така лесно да се мащабира чрез добавяне на още възли.
Надяваме се, че тази публикация в блога ви дава представа как може да бъде конфигуриран ProxySQL клъстер. ProxySQL клъстерът ще бъде прозрачен за ClusterControl и няма да засегне нито една от операциите, които може да искате да изпълните от потребителския интерфейс на ClusterControl.
