sql >> Databasteknik >  >> RDS >> MariaDB

En översikt över ProxySQL-klustring i ClusterControl

ProxySQL är en välkänd lastbalanserare i MySQL-världen - den kommer med en fantastisk uppsättning funktioner som låter dig ta kontroll över din trafik och forma den hur du vill. Den kan distribueras på många olika sätt - dedikerade noder, samlokaliserad med applikationsvärdar, silo-metoden - allt beror på den exakta miljön och affärskraven. Den gemensamma utmaningen är att du, i de flesta fall, vill att dina ProxySQL-noder ska innehålla samma konfiguration. Om du skalar ut ditt kluster och lägger till en ny server till ProxySQL vill du att servern ska vara synlig på alla ProxySQL-instanser, inte bara på den aktiva. Detta leder till frågan - hur ser man till att hålla konfigurationen synkroniserad över alla ProxySQL-noder?

Du kan försöka uppdatera alla noder för hand, vilket definitivt inte är effektivt. Du kan också använda någon form av orkestreringsverktyg för infrastruktur som Ansible eller Chef för att hålla konfigurationen över noderna i ett känt tillstånd, vilket gör ändringarna inte direkt på ProxySQL utan genom verktyget du använder för att organisera din miljö.

Om du råkar använda ClusterControl kommer den med en uppsättning funktioner som låter dig synkronisera konfigurationen mellan ProxySQL-instanser men den här lösningen har sina nackdelar - det är en manuell åtgärd, du måste komma ihåg att exekvera det efter en konfigurationsändring. Om du glömmer att göra det kan du få en otäck överraskning om, till exempel, keepalived kommer att flytta Virtual IP till den icke-uppdaterade ProxySQL-instansen.

Ingen av dessa metoder är enkel eller 100 % tillförlitlig och situationen är när ProxySQL-noderna har olika konfigurationer och kan vara potentiellt farliga.

Lyckligtvis kommer ProxySQL med en lösning för detta problem - ProxySQL Cluster. Tanken är ganska enkel - du kan definiera en lista med ProxySQL-instanser som kommer att prata med varandra och informera andra om versionen av konfigurationen som var och en av dem innehåller. Konf

Den senaste versionen av ClusterControl låter dig ställa in ProxySQL-kluster utan ansträngning. När du distribuerar ProxySQL bör du markera alternativet "Använd inbyggd klustring" för alla noder som du vill ska vara en del av klustret.

När du gör det är du i stort sett klar - resten sker under huven.

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å båda servrarna var proxysql_servers-tabellen korrekt inställd med värdnamnen för noderna som bildar klustret. Vi kan också verifiera att konfigurationsändringarna sprids ordentligt över klustret:

Vi har ökat inställningen Max Connections på en av ProxySQL-noderna (10.0) .0.131) och vi kan verifiera att den andra noden (10.0.0.132) kommer att se samma konfiguration:

I händelse av ett behov av att felsöka processen kan vi alltid se till ProxySQL-loggen (vanligen placerad i /var/lib/proxysql/proxysql.log) där vi kommer att se information så här:

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:6032

Detta är loggen från 10.0.0.132 där vi tydligt kan se att en konfigurationsändring för tabellen mysql_servers upptäcktes den 10.0.0.131 och sedan synkroniserades och tillämpades den 10.0.0.132, vilket gjorde den synkroniserad med den andra noden i klustret.

Som du kan se är klustring av ProxySQL ett enkelt men effektivt sätt att säkerställa att dess konfiguration förblir synkroniserad och avsevärt hjälper till att använda större ProxySQL-distributioner. Berätta för oss i kommentarerna vad din erfarenhet av ProxySQL-klustring är.


  1. Sammanfoga datafiler med Statistica, del 2

  2. Definiera en en-till-en-relation i SQL Server

  3. Fixa "Applikationen "SQLDeveloper.app" kan inte öppnas.

  4. Använder GO inom en transaktion