ProxySQL is een bekende load balancer in de MySQL-wereld - het wordt geleverd met een geweldige reeks functies waarmee u controle over uw verkeer kunt krijgen en het kunt vormgeven zoals u het wilt. Het kan op veel verschillende manieren worden ingezet - speciale knooppunten, samengebracht met applicatiehosts, silo-aanpak - alles hangt af van de exacte omgeving en zakelijke vereisten. De algemene uitdaging is dat u in de meeste gevallen wilt dat uw ProxySQL-knooppunten dezelfde configuratie bevatten. Als u uw cluster uitschaalt en een nieuwe server toevoegt aan ProxySQL, wilt u dat die server zichtbaar is op alle ProxySQL-instanties, niet alleen op de actieve. Dit leidt tot de vraag:hoe zorg je ervoor dat de configuratie gesynchroniseerd blijft op alle ProxySQL-knooppunten?
Je kunt proberen alle knooppunten met de hand bij te werken, wat zeker niet efficiënt is. Je kunt ook een soort infrastructuur-orkestratietools zoals Ansible of Chef gebruiken om de configuratie over de knooppunten in een bekende staat te houden, waarbij de wijzigingen niet rechtstreeks op ProxySQL worden aangebracht, maar via de tool die je gebruikt om je omgeving te organiseren.
Als u ClusterControl gebruikt, wordt het geleverd met een reeks functies waarmee u de configuratie tussen ProxySQL-instanties kunt synchroniseren, maar deze oplossing heeft zijn nadelen - het is een handmatige actie, u moet eraan denken voer het uit na een configuratiewijziging. Als u dat vergeet te doen, kunt u voor een onaangename verrassing komen te staan als bijvoorbeeld keepalive Virtual IP naar de niet-bijgewerkte ProxySQL-instantie zal verplaatsen.
Geen van deze methoden is eenvoudig of 100% betrouwbaar en de situatie is wanneer de ProxySQL-knooppunten verschillende configuraties hebben en mogelijk gevaarlijk kunnen zijn.
Gelukkig komt ProxySQL met een oplossing voor dit probleem:ProxySQL-cluster. Het idee is vrij eenvoudig - je kunt een lijst met ProxySQL-instanties definiëren die met elkaar praten en anderen informeren over de versie van de configuratie die elk van hen bevat. Configuratie is afhankelijk van een versie, dus elke wijziging van een instelling op een knooppunt zal ertoe leiden dat de configuratieversie wordt verhoogd - dit activeert de configuratiesynchronisatie en de nieuwe versie van de configuratie wordt gedistribueerd en toegepast op alle knooppunten die het ProxySQL-cluster vormen.
Met de recente versie van ClusterControl kun je moeiteloos ProxySQL-clusters opzetten. Wanneer u ProxySQL implementeert, moet u de optie "Native Clustering gebruiken" aanvinken voor alle nodes waarvan u deel wilt uitmaken van het cluster.
Als je dat eenmaal hebt gedaan, ben je zo goed als klaar - de rest gebeurt onder de motorkap.
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)Op beide servers was de proxysql_servers-tabel correct ingesteld met de hostnamen van de knooppunten die het cluster vormen. We kunnen ook controleren of de configuratiewijzigingen correct worden doorgevoerd in het cluster:
We hebben de instelling Max Connections op een van de ProxySQL-knooppunten verhoogd (10.0 .0.131) en we kunnen verifiëren dat het andere knooppunt (10.0.0.132) dezelfde configuratie zal zien:
In geval van foutopsporing in het proces, kunnen we altijd kijken naar het ProxySQL-logboek (meestal in /var/lib/proxysql/proxysql.log) waar we informatie als deze zullen zien:
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:6032Dit is het logboek van 10.0.0.132 waar we duidelijk kunnen zien dat een configuratiewijziging voor tabel mysql_servers werd gedetecteerd op 10.0.0.131 en vervolgens werd gesynchroniseerd en toegepast op 10.0.0.132, waardoor het synchroon liep met het andere knooppunt in het cluster.
Zoals u kunt zien, is het clusteren van ProxySQL een gemakkelijke maar efficiënte manier om ervoor te zorgen dat de configuratie synchroon blijft en aanzienlijk helpt om grotere ProxySQL-implementaties te gebruiken. Laat ons in de reacties weten wat jouw ervaring met ProxySQL-clustering is.