ProxySQL er en velkendt load balancer i MySQL-verdenen - den kommer med et fantastisk sæt funktioner, der giver dig mulighed for at tage kontrol over din trafik og forme den, som du synes, den passer. Det kan implementeres på mange forskellige måder - dedikerede noder, samlokaliseret med applikationsværter, silotilgang - alt afhænger af det nøjagtige miljø og forretningskrav. Den fælles udfordring er, at du i de fleste tilfælde ønsker, at dine ProxySQL-noder skal indeholde den samme konfiguration. Hvis du skalerer din klynge ud og tilføjer en ny server til ProxySQL, vil du have, at serveren skal være synlig på alle ProxySQL-instanser, ikke kun på den aktive. Dette leder til spørgsmålet - hvordan sikrer man, at man holder konfigurationen synkroniseret på tværs af alle ProxySQL-noder?
Du kan prøve at opdatere alle noder manuelt, hvilket bestemt ikke er effektivt. Du kan også bruge en form for infrastruktur-orkestreringsværktøjer som Ansible eller Chef til at holde konfigurationen på tværs af noderne i en kendt tilstand, hvilket gør ændringerne ikke direkte på ProxySQL, men gennem det værktøj, du bruger til at organisere dit miljø.
Hvis du tilfældigvis bruger ClusterControl, kommer den med et sæt funktioner, der giver dig mulighed for at synkronisere konfigurationen mellem ProxySQL-instanser, men denne løsning har sine ulemper - det er en manuel handling, du skal huske at udføre det efter en konfigurationsændring. Hvis du glemmer at gøre det, kan du få en grim overraskelse, hvis for eksempel keepalived flytter Virtual IP til den ikke-opdaterede ProxySQL-instans.
Ingen af disse metoder er enkle eller 100 % pålidelige, og situationen er, når ProxySQL-noderne har forskellige konfigurationer og kan være potentielt farlige.
Heldigvis kommer ProxySQL med en løsning på dette problem - ProxySQL Cluster. Ideen er ret simpel - du kan definere en liste over ProxySQL-instanser, der vil tale med hinanden og informere andre om den version af konfigurationen, som hver af dem indeholder. Konfigurationen er versioneret, derfor vil enhver ændring af enhver indstilling på enhver node resultere i, at konfigurationsversionen øges - dette udløser konfigurationssynkroniseringen, og den nye version af konfigurationen distribueres og anvendes på tværs af alle noder, der udgør ProxySQL-klyngen.
Den nyere version af ClusterControl giver dig mulighed for at opsætte ProxySQL-klynger uden besvær. Når du implementerer ProxySQL, skal du markere "Brug indbygget klynge" for alle de noder, du ønsker skal være en del af klyngen.
Når du gør det, er du stort set færdig - resten sker under emhætten.
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)På begge servere blev proxysql_servers-tabellen sat korrekt med værtsnavnene på de noder, der udgør klyngen. Vi kan også bekræfte, at konfigurationsændringerne er korrekt udbredt på tværs af klyngen:
Vi har øget indstillingen Max Connections på en af ProxySQL-noderne (10.0) .0.131), og vi kan bekræfte, at den anden node (10.0.0.132) vil se den samme konfiguration:
I tilfælde af behov for at fejlfinde processen, kan vi altid se til ProxySQL-loggen (typisk placeret i /var/lib/proxysql/proxysql.log), hvor vi vil se oplysninger som denne:
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:6032Dette er loggen fra 10.0.0.132, hvor vi tydeligt kan se, at en konfigurationsændring for tabel mysql_servers blev registreret den 10.0.0.131 og derefter blev den synkroniseret og anvendt den 10.0.0.132, hvilket gjorde den synkroniseret med den anden node i klyngen.
Som du kan se, er clustering af ProxySQL en nem, men effektiv måde at sikre, at dens konfiguration forbliver synkroniseret og hjælper betydeligt med at bruge større ProxySQL-implementeringer. Fortæl os i kommentarerne, hvad din oplevelse med ProxySQL-klynger er.