Ett proxylager mellan applikationer och databaser skulle vanligtvis bestå av flera proxynoder för hög tillgänglighet. Detta är inte annorlunda för ProxySQL. ProxySQL, precis som andra moderna proxyservrar, kan användas för att bygga komplex logik för routing av frågor. Du kan lägga till frågeregler för att skicka frågor till särskilda värdar, du kan cache-föra frågor, du kan lägga till och ta bort backend-servrar eller hantera användare som får ansluta till ProxySQL och MySQL. Men många ProxySQL-noder i proxylagret introducerar ett annat problem - synkronisering över distribuerade instanser. Alla regler eller annan logik måste synkroniseras mellan instanser för att säkerställa att de beter sig på samma sätt. Även om inte alla proxyservrar hanterar trafik, fungerar de fortfarande som standby. Om de skulle behöva ta över arbetet vill du inte ha några överraskningar om instansen som används inte har de senaste konfigurationsändringarna.
Det är ganska besvärligt att säkerställa detta manuellt - att göra ändringarna för hand på alla noder. Du kan använda verktyg som Ansible, Chef eller Puppet för att hantera konfigurationer, men synkroniseringsprocessen måste kodas och testas. ClusterControl kan hjälpa dig här genom ett alternativ att synkronisera konfigurationer mellan ProxySQL-instanser, men det kan också ställa in och hantera de andra komponenter som krävs för hög tillgänglighet, t.ex. Virtual IP. Men från och med version 1.4.2 erbjuder ProxySQL en inbyggd klustrings- och konfigurationssynkroniseringsmekanism. I det här blogginlägget kommer vi att diskutera hur man ställer in det med en blandning av åtgärder som vidtas i ClusterControl och ProxySQL kommandoradsadministratörsgränssnitt.
Först av allt, låt oss ta en titt på en typisk replikeringsmiljö som distribueras av ClusterControl.
Som du kan se från skärmdumpen är detta en MySQL-replikeringsinställning med tre ProxySQL-instanser. ProxySQL hög tillgänglighet implementeras genom Keepalved och Virtual IP som alltid tilldelas en av ProxySQL-noderna. Det finns ett par steg vi måste ta för att konfigurera ProxySQL-klustring. Först måste vi definiera vilken användare ProxySQL ska använda för att utbyta information mellan noderna. Låt oss definiera en ny ovanpå den befintliga administrativa användaren:
Därefter måste vi definiera den användaren i inställningarna admin-cluster_password och admin-cluster_username.
Detta har gjorts på bara en av noderna (10.0.0.126). Låt oss synkronisera denna konfigurationsändring till de återstående ProxySQL-noderna.
Som vi sa låter ClusterControl dig synkronisera konfigurationen mellan ProxySQL-noder med bara ett par steg. När jobbet slutade synkronisera 10.0.0.127 med 10.0.0.126, är det bara den sista noden vi behöver synkronisera.
Efter detta måste vi göra en liten ändring i det administrativa kommandoradsgränssnittet för ProxySQL, som vanligtvis är tillgängligt på port 6032. Vi måste skapa poster i tabellen 'proxysql_servers' som skulle definiera noderna i vårt ProxySQL-kluster.
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)Efter att ha laddat ändringen till körtid bör ProxySQL börja synkronisera noderna. Det finns ett par ställen där du kan spåra klustrets tillstånd.
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)Tabellen stats_proxysql_servers_checksums innehåller bland annat en lista med noder i klustret, tabeller som är synkroniserade, versioner och kontrollsumma för tabellen. Om kontrollsumman inte är i linje kommer ProxySQL att försöka hämta den senaste versionen från en klusterpeer. Mer detaljerad information om innehållet i denna tabell finns i ProxySQL-dokumentationen.
En annan informationskälla om processen är ProxySQL:s logg (som standard finns den i /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:6032Som du kan se har vi här information om att en ny kontrollsumma har upptäckts och att synkroniseringsprocessen är på plats.
Låt oss stanna ett ögonblick här och diskutera hur ProxySQL hanterar konfigurationsuppdateringar från flera källor. Först och främst spårar ProxySQL kontrollsummor för att upptäcka när en konfiguration har ändrats. Den lagrar också när det hände - denna data lagras som en tidsstämpel, så den har en upplösning på en sekund. ProxySQL har två variabler som också påverkar hur ändringar synkroniseras.
Cluster_check_interval_ms - det bestämmer hur ofta ProxySQL ska leta efter konfigurationsändringar. Som standard är det 1000ms.
Cluster_mysql_servers_diffs_before_sync - den talar om för oss hur många gånger en kontroll ska upptäcka en konfigurationsändring innan den synkroniseras. Standardinställningen är 3.
Detta innebär att även om du kommer att göra en konfigurationsändring på samma värd, om du gör den mindre ofta än 4 sekunder, kanske de återstående ProxySQL-noderna inte kan synkronisera den eftersom en ny ändring kommer att dyka upp före den föregående synkroniserades. Det betyder också att om du gör konfigurationsändringar på flera ProxySQL-instanser, bör du göra dem med minst 4 sekunders paus mellan dem eftersom annars en del av ändringarna kommer att gå förlorade och som ett resultat kommer konfigurationer att divergera. Till exempel lägger du till Server1 på Proxy1 och efter 2 sekunder lägger du till Server2 på Proxy2 . Alla andra proxyservrar kommer att avvisa ändringen på Proxy1 eftersom de kommer att upptäcka att Proxy2 har en nyare konfiguration. 4 sekunder efter ändringen på Proxy2 kommer alla proxyservrar (inklusive Proxy1) att hämta konfigurationen från Proxy2.
Eftersom kommunikationen inom kluster inte är synkron och om en ProxySQL-nod som du gjorde ändringarna i misslyckades, kanske ändringar inte replikeras i tid. Det bästa tillvägagångssättet är att göra samma ändring på två ProxySQL-noder. På så sätt, om inte båda misslyckas exakt samtidigt, kommer en av dem att kunna sprida ny konfiguration.
Värt att notera är också att ProxySQL-klustertopologin kan vara ganska flexibel. I vårt fall har vi tre noder, alla har tre poster i proxysql_servers-tabellen. Sådana noder bildar klustret där du kan skriva till vilken nod som helst och ändringarna kommer att spridas. Utöver det är det möjligt att lägga till externa noder som skulle fungera i ett "skrivskyddat" läge, vilket innebär att de bara skulle synkronisera ändringar som gjorts i "kärn"-klustret men de kommer inte att sprida ändringar som utfördes direkt på sig själva. Allt du behöver på den nya noden är att bara ha "kärn"-klusternoderna konfigurerade i proxysql_servers och som ett resultat kommer den att ansluta till dessa noder och få dataändringarna, men det kommer inte att frågas av resten av klustret för dess konfigurationsändringar. Denna inställning skulle kunna användas för att skapa en sanningskälla med flera noder i klustret och andra ProxySQL-noder, som bara får konfigurationen från huvudklustret "kärn".
Utöver allt detta stöder ProxySQL-kluster automatisk återkoppling av noderna - de kommer att synkronisera sin konfiguration när de startar. Det kan också enkelt skalas ut genom att lägga till fler noder.
Vi hoppas att det här blogginlägget ger dig en inblick i hur ProxySQL-kluster kan konfigureras. ProxySQL-klustret kommer att vara transparent för ClusterControl och det kommer inte att påverka någon av de operationer du kanske vill utföra från ClusterControl-gränssnittet.