Een proxylaag tussen applicaties en databases bestaat doorgaans uit meerdere proxyknooppunten voor hoge beschikbaarheid. Dit is niet anders voor ProxySQL. ProxySQL kan, net als andere moderne proxy's, worden gebruikt om complexe logica te bouwen voor het routeren van query's. U kunt queryregels toevoegen om query's naar bepaalde hosts te verzenden, u kunt query's cachen, u kunt backend-servers toevoegen en verwijderen of gebruikers beheren die verbinding mogen maken met ProxySQL en MySQL. Talloze ProxySQL-knooppunten in de proxylaag introduceren echter een ander probleem:synchronisatie tussen gedistribueerde instanties. Alle regels of andere logica moeten tussen instanties worden gesynchroniseerd om ervoor te zorgen dat ze zich op dezelfde manier gedragen. Zelfs als niet alle proxy's het verkeer afhandelen, werken ze nog steeds als stand-by. Mochten ze het werk moeten overnemen, dan wil je niet voor verrassingen komen te staan als de gebruikte instantie niet de meest recente configuratiewijzigingen heeft.
Het is nogal omslachtig om dit handmatig te doen - om de wijzigingen met de hand op alle knooppunten aan te brengen. U kunt tools zoals Ansible, Chef of Puppet gebruiken om configuraties te beheren, maar het synchronisatieproces moet worden gecodeerd en getest. ClusterControl kan u hierbij helpen door middel van een optie om configuraties tussen ProxySQL-instanties te synchroniseren, maar het kan ook de andere componenten instellen en beheren die nodig zijn voor hoge beschikbaarheid, bijvoorbeeld Virtual IP. Maar vanaf versie 1.4.2 biedt ProxySQL een native mechanisme voor clustering en configuratiesynchronisatie. In deze blogpost bespreken we hoe je het kunt instellen met een combinatie van acties die worden ondernomen in de ClusterControl en ProxySQL-opdrachtregelbeheerinterface.
Laten we eerst eens kijken naar een typische replicatieomgeving die wordt geïmplementeerd door ClusterControl.
Zoals je kunt zien aan de screenshot, is dit een MySQL-replicatie-installatie met drie ProxySQL-instanties. ProxySQL hoge beschikbaarheid wordt geïmplementeerd via Keepalive en Virtual IP die altijd wordt toegewezen aan een van de ProxySQL-knooppunten. Er zijn een aantal stappen die we moeten nemen om ProxySQL-clustering te configureren. Eerst moeten we definiëren welke gebruiker ProxySQL moet gebruiken om informatie tussen de knooppunten uit te wisselen. Laten we een nieuwe definiëren bovenop de bestaande administratieve gebruiker:
Vervolgens moeten we die gebruiker definiëren in de instellingen admin-cluster_password en admin-cluster_username.
Dit is gedaan op slechts een van de knooppunten (10.0.0.126). Laten we deze configuratiewijziging synchroniseren met de resterende ProxySQL-knooppunten.
Zoals we al zeiden, stelt ClusterControl u in staat om de configuratie tussen ProxySQL-knooppunten in slechts een paar stappen te synchroniseren. Toen de taak eindigde met het synchroniseren van 10.0.0.127 met 10.0.0.126, is er alleen nog het laatste knooppunt dat we moeten synchroniseren.
Hierna moeten we een kleine wijziging aanbrengen in de ProxySQL-beheeropdrachtregelinterface, die doorgaans bereikbaar is op poort 6032. We moeten vermeldingen maken in de tabel 'proxysql_servers' die de knooppunten in ons ProxySQL-cluster zou definiëren.
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)Na het laden van de wijziging naar runtime, zou ProxySQL moeten beginnen met het synchroniseren van de knooppunten. Er zijn een aantal plaatsen waar u de status van het cluster kunt volgen.
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)De tabel stats_proxysql_servers_checksums bevat onder andere een lijst met knooppunten in het cluster, tabellen die worden gesynchroniseerd, versies en controlesom van de tabel. Als de controlesom niet in lijn is, zal ProxySQL proberen de nieuwste versie van een clusterpeer te krijgen. Meer gedetailleerde informatie over de inhoud van deze tabel is te vinden in ProxySQL-documentatie.
Een andere bron van informatie over het proces is het logboek van ProxySQL (het bevindt zich standaard in /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:6032Zoals u kunt zien, hebben we hier informatie dat er een nieuwe controlesom is gedetecteerd en dat het synchronisatieproces is uitgevoerd.
Laten we hier even stoppen en bespreken hoe ProxySQL omgaat met configuratie-updates van meerdere bronnen. Allereerst houdt ProxySQL controlesommen bij om te detecteren wanneer een configuratie is gewijzigd. Het slaat ook op wanneer het is gebeurd - deze gegevens worden opgeslagen als een tijdstempel, dus het heeft een resolutie van één seconde. ProxySQL heeft twee variabelen die ook van invloed zijn op de manier waarop wijzigingen worden gesynchroniseerd.
Cluster_check_interval_ms - het bepaalt hoe vaak ProxySQL moet controleren op configuratiewijzigingen. Standaard is dit 1000 ms.
Cluster_mysql_servers_diffs_before_sync - het vertelt ons hoe vaak een controle een configuratiewijziging moet detecteren voordat deze wordt gesynchroniseerd. Standaardinstelling is 3.
Dit betekent dat, zelfs als u een configuratiewijziging op dezelfde host aanbrengt, als u deze minder vaak dan 4 seconden doet, de resterende ProxySQL-knooppunten deze mogelijk niet kunnen synchroniseren omdat een nieuwe wijziging vóór de vorige verschijnt werd gesynchroniseerd. Het betekent ook dat als u configuratiewijzigingen aanbrengt op meerdere ProxySQL-instanties, u deze moet maken met een pauze van ten minste 4 seconden daartussen, omdat anders sommige wijzigingen verloren gaan en als gevolg daarvan zullen configuraties afwijken. U voegt bijvoorbeeld Server1 toe aan Proxy1 en na 2 seconden voegt u Server2 toe aan Proxy2. Alle andere proxy's zullen de wijziging op Proxy1 afwijzen omdat ze zullen detecteren dat Proxy2 een nieuwere configuratie heeft. 4 seconden na de wijziging op Proxy2 halen alle proxy's (inclusief Proxy1) de configuratie uit Proxy2.
Omdat de communicatie binnen het cluster niet synchroon is en als een ProxySQL-knooppunt waarin u de wijzigingen hebt aangebracht, is mislukt, worden wijzigingen mogelijk niet op tijd gerepliceerd. De beste aanpak is om dezelfde wijziging aan te brengen op twee ProxySQL-knooppunten. Op deze manier kan een van hen, tenzij beide precies tegelijkertijd falen, een nieuwe configuratie verspreiden.
Ook vermeldenswaard is dat de ProxySQL-clustertopologie behoorlijk flexibel kan zijn. In ons geval hebben we drie knooppunten, allemaal met drie vermeldingen in de proxysql_servers-tabel. Dergelijke knooppunten vormen het cluster waar u naar elk knooppunt kunt schrijven en de wijzigingen worden doorgevoerd. Bovendien is het mogelijk om externe knooppunten toe te voegen die in een "alleen-lezen"-modus zouden werken, wat betekent dat ze alleen wijzigingen aan het "kern"-cluster zouden synchroniseren, maar ze zullen geen wijzigingen doorgeven die rechtstreeks zijn uitgevoerd op zichzelf. Het enige dat u op het nieuwe knooppunt nodig hebt, is dat alleen de "kern"-clusterknooppunten zijn geconfigureerd in proxysql_servers en als gevolg daarvan zal het verbinding maken met die knooppunten en de gegevenswijzigingen krijgen, maar het zal niet worden opgevraagd door de rest van het cluster voor zijn configuratiewijzigingen. Deze opstelling zou kunnen worden gebruikt om een bron van waarheid te creëren met verschillende knooppunten in het cluster, en andere ProxySQL-knooppunten, die alleen de configuratie van het belangrijkste "kern"-cluster krijgen.
Naast dat alles ondersteunt ProxySQL-cluster het automatisch opnieuw verbinden van de knooppunten - ze zullen hun configuratie synchroniseren tijdens het starten. Het kan ook eenvoudig worden uitgeschaald door meer knooppunten toe te voegen.
We hopen dat deze blogpost u inzicht geeft in hoe ProxySQL-cluster kan worden geconfigureerd. ProxySQL-cluster is transparant voor ClusterControl en heeft geen invloed op de bewerkingen die u mogelijk wilt uitvoeren vanuit de gebruikersinterface van ClusterControl.