Proxy vrstva mezi aplikacemi a databázemi by se typicky skládala z více proxy uzlů pro vysokou dostupnost. Nejinak je tomu u ProxySQL. ProxySQL, stejně jako jiné moderní proxy, lze použít k vytvoření komplexní logiky pro směrování dotazů. Můžete přidat pravidla dotazů pro odesílání dotazů na konkrétní hostitele, můžete dotazy ukládat do mezipaměti, můžete přidávat a odebírat servery typu backend nebo spravovat uživatele, kteří se mohou připojit k ProxySQL a MySQL. Mnoho uzlů ProxySQL v proxy vrstvě však přináší další problém – synchronizaci napříč distribuovanými instancemi. Jakákoli pravidla nebo jiná logika musí být synchronizována napříč instancemi, aby bylo zajištěno, že se budou chovat stejným způsobem. I když ne všechny servery proxy obsluhují provoz, stále fungují jako pohotovostní režim. V případě, že by potřebovali převzít práci, nechcete žádná překvapení, pokud použitá instance nemá nejnovější změny konfigurace.
Zajistit to ručně je poměrně těžkopádné – provádět změny ručně na všech uzlech. Ke správě konfigurací můžete využít nástroje jako Ansible, Chef nebo Puppet, ale proces synchronizace musí být nakódován a otestován. ClusterControl vám zde může pomoci prostřednictvím možnosti synchronizace konfigurací mezi instancemi ProxySQL, ale také může nastavit a spravovat další komponenty potřebné pro vysokou dostupnost, např. Od verze 1.4.2 však ProxySQL nabízí nativní mechanismus shlukování a synchronizace konfigurace. V tomto příspěvku na blogu probereme, jak to nastavit pomocí kombinace akcí provedených v rozhraní ClusterControl a ProxySQL pro správu příkazového řádku.
Nejprve se podívejme na typické prostředí replikace nasazené pomocí ClusterControl.
Jak můžete vidět ze snímku obrazovky, jedná se o nastavení replikace MySQL se třemi instancemi ProxySQL. Vysoká dostupnost ProxySQL je implementována prostřednictvím Keepalived a Virtual IP, která je vždy přiřazena jednomu z uzlů ProxySQL. Existuje několik kroků, které musíme provést, abychom nakonfigurovali clustering ProxySQL. Nejprve musíme definovat, kterého uživatele má ProxySQL používat k výměně informací mezi uzly. Pojďme definovat nového nad stávajícím administrátorem:
Dále musíme tohoto uživatele definovat v nastavení admin-cluster_password a admin-cluster_username.
To bylo provedeno pouze na jednom z uzlů (10.0.0.126). Pojďme tuto změnu konfigurace synchronizovat se zbývajícími uzly ProxySQL.
Jak jsme uvedli, ClusterControl vám umožňuje synchronizovat konfiguraci mezi uzly ProxySQL pouze v několika krocích. Když úloha skončila synchronizací 10.0.0.127 s 10.0.0.126, zbývá už jen poslední uzel, který musíme synchronizovat.
Poté musíme provést malou změnu v administrativním rozhraní příkazového řádku ProxySQL, které je obvykle dostupné na portu 6032. Musíme vytvořit položky v tabulce 'proxysql_servers', které by definovaly uzly v našem clusteru 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)Po načtení změny do běhového prostředí by měl ProxySQL začít synchronizovat uzly. Existuje několik míst, kde můžete sledovat stav clusteru.
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)Tabulka stats_proxysql_servers_checksums obsahuje mimo jiné seznam uzlů v clusteru, tabulky, které jsou synchronizovány, verze a kontrolní součet tabulky. Pokud kontrolní součet není v souladu, ProxySQL se pokusí získat nejnovější verzi od partnera clusteru. Podrobnější informace o obsahu této tabulky lze nalézt v dokumentaci ProxySQL.
Dalším zdrojem informací o procesu je protokol ProxySQL (ve výchozím nastavení se nachází v /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:6032Jak můžete vidět, máme zde informaci, že byl zjištěn nový kontrolní součet a proces synchronizace je na místě.
Zde se na chvíli zastavme a proberme, jak ProxySQL zpracovává aktualizace konfigurace z více zdrojů. Za prvé, ProxySQL sleduje kontrolní součty, aby zjistil, kdy se konfigurace změnila. Ukládá také, kdy se to stalo – tato data se ukládají jako časové razítko, takže mají jednosekundové rozlišení. ProxySQL má dvě proměnné, které také ovlivňují způsob synchronizace změn.
Cluster_check_interval_ms – určuje, jak často má ProxySQL kontrolovat změny konfigurace. Ve výchozím nastavení je to 1000 ms.
Cluster_mysql_servers_diffs_before_sync – říká nám, kolikrát by kontrola měla detekovat změnu konfigurace, než se synchronizuje. Výchozí nastavení je 3.
To znamená, že i když provedete změnu konfigurace na stejném hostiteli, pokud ji budete provádět méně často než 4 sekundy, zbývající uzly ProxySQL ji nemusí být schopny synchronizovat, protože nová změna se zobrazí před předchozí. byla synchronizována. To také znamená, že pokud provedete změny konfigurace na více instancích ProxySQL, měli byste je provést s alespoň 4 sekundovou přestávkou mezi nimi, protože jinak budou některé změny ztraceny a v důsledku toho se konfigurace budou lišit. Například přidáte Server1 na Proxy1 a po 2 sekundách přidáte Server2 na Proxy2. Všechny ostatní proxy odmítnou změnu na Proxy1, protože zjistí, že Proxy2 má novější konfiguraci. 4 sekundy po změně na Proxy2 převezmou všechny proxy (včetně Proxy1) konfiguraci z Proxy2.
Protože komunikace v rámci clusteru není synchronní a pokud uzel ProxySQL, na kterém jste provedli změny, selhal, změny nemusí být replikovány včas. Nejlepším přístupem je provést stejnou změnu na dvou uzlech ProxySQL. Tímto způsobem, pokud oba selžou přesně ve stejnou dobu, jeden z nich bude schopen šířit novou konfiguraci.
Za zmínku také stojí, že topologie clusteru ProxySQL může být poměrně flexibilní. V našem případě máme tři uzly, všechny mají tři položky v tabulce proxysql_servers. Takové uzly tvoří shluk, do kterého můžete zapisovat do libovolného uzlu a změny se budou šířit. Kromě toho je možné přidat externí uzly, které by pracovaly v režimu „pouze pro čtení“, což znamená, že by pouze synchronizovaly změny provedené v „core“ clusteru, ale nebudou šířit změny, které byly provedeny přímo. na sebe. Vše, co potřebujete na novém uzlu, je mít pouze „jádrové“ uzly clusteru nakonfigurované v proxysql_servers a v důsledku toho se připojí k těmto uzlům a získá změny dat, ale nebude se na něj dotazovat zbytek clusteru. pro změny jeho konfigurace. Toto nastavení lze použít k vytvoření zdroje pravdy s několika uzly v clusteru a dalšími uzly ProxySQL, které pouze získají konfiguraci z hlavního „jádrového“ clusteru.
Navíc k tomu všemu ProxySQL cluster podporuje automatické znovupřipojování uzlů – při startu budou synchronizovat svou konfiguraci. Lze jej také snadno škálovat přidáním dalších uzlů.
Doufáme, že tento příspěvek na blogu vám poskytne přehled o tom, jak lze nakonfigurovat cluster ProxySQL. Cluster ProxySQL bude pro ClusterControl transparentní a nebude mít vliv na žádné operace, které můžete chtít provádět z uživatelského rozhraní ClusterControl.