ProxySQL
ProxySQL
e' uno strumento Open Source che fornisce funzioni
di alta affidabilita', bilanciamento di carico, pooling delle connessioni,
cache delle query, ... e molto altro alle applicazioni che
utilizzano MySQL,
il DBMS relazionale Open Source noto per
la velocita', la semplicita' di utilizzo e la diffusione.
Configurato correttamente ProxySQL e' un ottimo proxy che opera in modo trasparente
tra le applicazioni ed i database MySQL facendo in modo che ogni connessione
ed ogni statement siano indirizzati al nodo corretto.
Questa pagina descrive le principali caratteristiche di ProxySQL:
dopo un'introduzione su
MySQL e ProxySQL,
vedremo brevemente
l'installazione e la configurazione,
presenteremo alcune possibili architetture
e quindi vedremo con esempi pratici i piu' comuni
casi d'uso
(Replica,
Galera Cluster,
Split Read/Write vs Read-Only,
Query Cache,
...).
Per meglio comprendere questo documento e' opportuna una conoscenza di base su MySQL;
un documento introduttivo e' Introduzione a MySQL.
Importante e' anche conoscere la replica MySQL.
MySQL
Un breve accenno all'architettura di MySQL puo' essere utile...
L'architettura di MySQL e' semplicissima: vi e' un solo processo che gestisce tutto!
Per ogni connessione viene allocato un thread e sono presenti alcuni thread interni di gestione.
Gli utenti si collegano a MySQL utilizzando una connessione TCP-IP su una porta socket.
Di default la porta utilizzata da MySQL e' la 3306.
Il processo mysqld e' in LISTEN su tale porta e quando arriva una nuova richiesta di connessione
effettua l'attivazione del thread corrispondente.
Ogni database corrisponde ad una directory posta sotto /var/lib/mysql (o nella directory indicata dal parametro datadir).
All'interno della directory si trovano i file relativi ad ogni tabella.
La memorizzazione dei dati dipende dallo Storage Engine.
E' sempre presente un file tabella.frm che contiene la struttura della tabella,
eventuali altri file dipendono dall'Engine di memorizzazione.
La configurazione dei parametri di MySQL si effettua modificando il file my.cnf,
la cui disposizione nel file system dipende dal sistema operativo utilizzato ma spesso e' /etc/my.cnf
mentre la configurazione degli accessi si effettua a livello
di database con i comandi SQL di GRANT.
La replica in MySQL e' molto flessibile e sono possibili molteplici alternative.
Storicamente basata sulla replica degli statement, la replica MySQL si e' evoluta
con il formato ROW based e quindi con il GTID.
In ogni caso tecnicamente la replica
utilizza i file bin-log sul Primary per salvare le transazioni mentre sul Secondary
sono presenti due thread che si occupano di ricevere le transazioni e quindi di applicarle.
Nei casi piu' semplici di configurazione della replica
si utilizza un solo database Primary ed alcuni database Secondary
in sola lettura.
Tuttavia sono disponibili configurazioni in cascata, per l'uso su piu' datacenter,
in configurazione semi sincrona, per la riduzione dell'RPO,
ed anche in cluster utilizzando
Galera o InnoDB Cluster.
ProxySQL
ProxySQL utilizza il protocollo di rete MySQL
e quindi le applicazioni accedono a ProxySQL senza necessita' di modifiche.
La porta di accesso a MySQL e', per default, la 3306 mentre la porta di accesso
a ProxySQL e' la 6033 (le stesse cifre invertite).
ProxySQL viene posto davanti ad uno o ad una serie di DB MySQL per fornire alcune funzionalita'
che non sono disponibili nativamente in MySQL:
- High Availability
ProxySQL fornisce l'alta affidabilita' (HA: High Availability)
su una gruppo di database MySQL in replica facendo sempre puntare le applicazioni
verso i database funzionanti.
Per fare questo ProxySQL utilizza controlli sul DB e
sofisticati algoritmi, che dipendono dal tipo di replica presente,
per evitare falsi positivi e split brain.
- Connection Pooling
ProxySQL mantiene attive le connessioni al DB e le riutilizza quando richieste dai client.
Questo riduce in modo significativo il carico dovuto all'apertura di nuove connessioni.
Il connection multiplexing utilizzato da ProxySQL riduce notevolmente sia
il carico che il numero di connessioni verso le basi dati consentendo di gestire
migliaia di connessioni alle basi dati.
- Load balancing
ProxySQL distribuisce le query sui server disponibili bilanciando il carico.
ProxySQL comprende il protocollo MySQL ed e' in grado di distingue nelle query tra SELECT e DML
puo' inviare le modifiche al Primary e le query ai Secondary.
- Query Caching
ProxySQL puo' effettuare il caching del risultato delle query.
Si tratta di una funzionalita'
molto vantaggiosa per alcune applicazioni
ed ancora piu' utile con
MySQL 8.0
perche' la Query Cache e' stata eliminata dal database.
- Online reconfiguration
Come ultimo punto ma non per importanza...
ProxySQL viene configurato online senza
necessita' di riavviarlo neanche per le modifiche piu' complesse.
La modalita' utilizzata e' simile a quella che si adotta sui
dispositivi di rete e consente riconfigurazioni
e tuning senza interrompere mai il servizio verso i database.
In realta' c'e' molto di piu'... continuate a leggere!
Installazione
Come descritto nella
documentazione ufficiale
e' possibile installare ProxySQL in diversi modi:
installando i pacchetti per le principali distribuzioni linux,
partendo dal repository GIT,
utilizzando il DockerHub repository, ...
Nel seguito vediamo come effettuare l'installazione dell'ultima release su Debian/Ubuntu:
wget -nv -O /etc/apt/trusted.gpg.d/proxysql-2.5.4-keyring.gpg 'https://repo.proxysql.com/ProxySQL/proxysql-2.5.x/repo_pub_key.gpg'
apt-get update
apt-get install proxysql
Quindi i comandi per attivare il servizio sono:
systemctl enable proxysql
systemctl start proxysql
Gia' fatto!
Ora ProxySQL e' attivo come servizio ed e' possibile configurarlo...
Configurazione
Una delle caratteristiche principali di ProxySQL e' che la configurazione
avviene online, con un'interfaccia a comandi SQL e senza interrompere mai
il servizio.
ProxySQL utilizza il concetto di layer per la configurazione.
La configurazione viene preparata nel layer Memory e, quando e' completa,
puo' essere passata al layer Runtime per renderla attiva.
La configurazione deve essere salvata sul layer Disk per essere mantenuta
al riavvio.
Tutte le configurazioni vengono effettuate in SQL, con un qualsiasi client MySQL
collegato alla porta di amministrazione (default 6032).
In ProxySQL presenti tre livelli o layer.
Il layer su cui vengono effettuate le configurazioni
e' chiamato Memory.
Ad esempio la configurazione di un nodo richiede l'inserimento di una
riga nella tabella mysql_servers
mentre l'impostazione di una variabile si effettua sulla la global_variables.
Le configurazioni possono essere controllate con SELECT o modificate
con UPDATE.
Le configurazioni pero' non sono attive finche' non vengono caricate sul
layer Runtime con il comando LOAD ... TO RUNTIME.
Il layer runtime e' quello mantiene la configurazione e lo stato attuale
di ogni componente.
Quando viene interrotto il processo di ProxySQL tutte le configurazioni
in Memory vengono perdute. Per rendere permanente una configurazione
basta salvarla sul layer Disk con il comando SAVE ... TO DISK.
Dal punto di vista pratico, una volta compresa l'utilizzo dei layer,
la configurazione si effettua con semplici comandi SQL.
Connessi alla porta di amministrazione ProxySQL presenta una serie di database:
mysql> show databases;
+-----+---------------+-------------------------------------+
| seq | name | file |
+-----+---------------+-------------------------------------+
| 0 | main | |
| 2 | disk | /var/lib/proxysql/proxysql.db |
| 3 | stats | |
| 4 | monitor | |
| 5 | stats_history | /var/lib/proxysql/proxysql_stats.db |
+-----+---------------+-------------------------------------+
ProxySQL utilizza per la configurazione una decina di tabelle del database main.
Le principali sono: mysql_servers, mysql_users e
global_variables.
Le altre tabelle sono utilizate a seconda delle configurazioni scelte.
Una serie di tabelle con il prefisso runtime_ corrispondono all'analogo
nel layer Runtime.
Le variabili che e' possibile impostare con ProxySQL sono divise
in due gruppi.
admin_variables fa riferimento alle variabili
globali che controllano le funzioni dell'interfaccia di amministrazione;
mysql_variables fa riferimento alle variabili
globali che impostano le funzionalita' pe trattare il traffico MySQL.
Il database stats mantiene una serie di tabelle statistiche.
Le statistiche possono essere resettate accedendo con il suffisso _reset.
Sono disponibili altri comandi, alcune sintassi equivalenti e la possibilita'
di caricare un file di configurazione iniziale... ma si tratta di dettagli
che vedremo, anche se solo in parte, nei prossimi esempi.
Architetture con ProxySQL
In questo capitolo diamo solo qualche cenno alle architetture in cui e' utilizzabile ProxySQL
perche' possibilita' sono davvero molte.
Nella configurazione piu' semplice ProxySQL e' posto davanti ad un DB MySQL.
In questo caso la principale funzionalita' utilizzata e' quella del connection pooling.
Tuttavia le funzionalita' di HA di ProxySQL si sfruttano mettendo in cluster due o piu' MySQL
configurati in replica.
Vi sono differenti modalita' di replica supportate da ProxySQL:
- MySQL replica
Nella configurazione piu' semplice si utilizza la normale replica MySQL.
ProxySQL e' in grado di garantire
sia l'HA, facendo accedere le applicazioni al solo nodo primario,
sia la separazione degli statement SQL, facendo eseguire i comandi di DML sul nodo primario
e quelli di SELECT in load balancing sui nodi secondari.
- Group Replication
Piu' complessa e' la group replication
che permette una gestione dinamica dei nodi e la configurazione multiprimary
[NdA in pratica il ProxySQL sostituisce il MySQL Router in una configurazione
InnoDB Cluster].
I nodi vengono dinamicamente assegnati ad Hostgroup differenti a seconda
dello stato logico: Writer, Reader, Backup Writer, Offline.
- Galera
Dalla versione 2 ProxySQL gestice in modo nativo Galera,
il cluster piu' utilizzato per MySQL ed i suoi fork, senza necessita' di utilizzare
lo scheduler.
Anche con Galera gli stati logici sono: Writer, Reader, Backup Writer, Offline.
In ogni configurazione ProxySQL fornisce il connection pooling e l'automatic fail over.
Inoltre puo' gestire in modo molto sofisticato il routing verso i DB server
utilizzando pesi e condizioni ulteriori.
Un ultimo punto importante riguardo all'architettura e' quello relativo al deploy di ProxySQL
ovvero dove installarlo.
Sui web/application server oppure sui nodi che ospitano la base dati oppure su server/VM/container dedicati?
Poiche' ProxySQL e' particolarmente leggero spesso viene ospitato
direttamente sul nodo che ospita l'applicazione.
Se l'applicazione viene installata su piu' nodi,
lo stesso avviene per ProxySQL garantendo cosi'
sia la scalabilita' orizzontale che l'alta affidabilita'.
Poiche' ProxySQL riduce parecchio il numero di sessioni
aperte verso il database in questo modo e' possibile scalare
in modo molto significativo.
Altre configurazioni possibili sono quelle di ospitare ProxySQL sui DB server
oppure su un POD dedicato.
In realta' ogni soluzione presenta vantaggi e svantaggi:
la scelta migliore dipende dall'architettura complessiva del sistema
che deve evitare SPOF per ogni singolo componente
e spesso e' opportuno eseguire un benchmark per validare la soluzione adottata.
Utilizzo
Dal punto di vista dell'utilizzo applicativo accedere direttamente ad un database MySQL
o attraverso ProxySQL e' quasi indifferente anche se
in realta' l'accesso mediante proxy presenta una serie di piccole,
ma a volte importanti, differenze.
Come abbiamo gia' visto
la porta socket in ascolto di MySQL e' la 3306 mentre quella ProxySQL
e' la 6033 [NdA lo stesso numero con le cifre invertite], ma sono entrambe valori che possono essere cambiati;
i comandi amministrativi vengono invece rivolti al ProxySQL sulla porta di default 6032.
Nel seguito vediamo alcuni esempi di semplici configurazioni avendo
a disposizione diversi nodi MySQL agli indirizzi 10.0.0.x con una configurazione standard.
Per connetterci all'interfaccia di amministrazione di ProxySQL utilizzeremo:
mysql -u admin -padmin -h 127.0.0.1 -P6032 --prompt 'ProxySQL> '
Configurazione iniziale
mysql> CREATE USER 'monitor'@'%' IDENTIFIED BY 'xxx';
mysql> GRANT USAGE, REPLICATION CLIENT ON *.* TO 'monitor'@'%';
ProxySQL> UPDATE global_variables SET variable_value='monitor' WHERE variable_name='mysql-monitor_username';
ProxySQL> UPDATE global_variables SET variable_value='xxx' WHERE variable_name='mysql-monitor_password';
ProxySQL> LOAD MYSQL VARIABLES TO RUNTIME;
ProxySQL> SAVE MYSQL VARIABLES TO DISK;
ProxySQL> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (1,'10.0.0.1',3306);
ProxySQL> LOAD MYSQL SERVERS TO RUNTIME;
ProxySQL> SAVE MYSQL SERVERS TO DISK;
ProxySQL> INSERT INTO mysql_users(username,password,default_hostgroup) VALUES ('sbtest','yyy',1);
ProxySQL> LOAD MYSQL USERS TO RUNTIME;
ProxySQL> SAVE MYSQL USERS TO DISK;
Come configurazione iniziale dobbiamo eseguire una serie di impostazioni:
l'utente per il monitoraggio dei DB server, l'elenco dei server MySQL
ed un utente per la connessione.
L'utenza per il monitoraggio deve essere definita sui nodi MySQL e quindi va configurata
come variabile in ProxySQL. Vi sono due gruppi di variabili in ProxySQL: ADMIN e MYSQL
facilmente identificabili dal prefisso.
Per configurare i server MySQL bastano pochi campi: l'indirizzo, hostgroup di appartenenza
e l'eventuale porta [NdA non e' obbligatorio indicare la porta se e' il default 3306].
L'hostgroup e' un concetto importante in ProxySQL perche' indica nodi con lo stesso trattamento.
Per esempio e' possibile definire un hostgroup per i nodi in sola lettura;
ProxySQL spostera' un nodo MySQL nell'hostgroup corretto a seconda delle regole impostate
e fara' in modo che tutte le connessioni client raggiungano i nodi degli hostgroup adatti.
Appena inseriti in Memory i server MySQL possono essere controllati sulla tabella
monitor.mysql_server_connect_log e quando caricati in Runtime sono visibili
sulla tabella mysql_servers.
E' infine necessario definire gli utenti con cui si collegano le applicazioni.
In pratica si tratta di una doppia definizione:
infatti sono distinti gli utenti con cui le applicazioni si collegano a ProxySQL
e quelli che da ProxySQL si collegano a MySQL [NdA campi backend, frontend].
Questo consente una notevole flessibilita' nella gestione e nell'indirizzamento
delle applicazioni ai nodi/utenti/schema finali, anche se spesso su utilizzano
gli stessi utenti.
Replica
ProxySQL> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (1,'10.0.0.2',3306);
ProxySQL> INSERT INTO mysql_replication_hostgroups (writer_hostgroup,reader_hostgroup,comment) VALUES (1,2,'cluster1');
ProxySQL> LOAD MYSQL SERVERS TO RUNTIME;
ProxySQL> SAVE MYSQL SERVERS TO DISK;
Definire una configurazione in replica e' molto semplice con ProxySQL: basta aggiungere i nodi MySQL
e definire gli hostgroup.
Sara' ProxySQL a spostare i nodi MySQL sull'hostgroup corretto basandosi sulla
configurazione della variabile read_only = 1 che deve essere impostata sui DB Secondari
[NdA per l'esattezza il controllo e' effettuato a seconda dell'impostazione del campo check_type
che puo' assumere i valori: read_only, innodb_read_only, super_read_only].
La configurazione della replica puo' essere complessa a piacere: prevedere repliche in cascata,
nodi distribuiti in modo geografico, ... ma la configurazione degli accessi degli utenti su ProxySQL
resta molto semplice perche' basta indirizzarli sull'hostgroup corretto.
In questo caso basata assegnare 1 come default_hostgroup per gli accessi OLTP e 2 per gli accessi in sola lettura.
Sara' ProxySQL ad assegnare i nodi agli hostgroup corretti a fronte di qualsiasi variazione
dello stato delle repliche.
Il monitoraggio si effettua principalmente
sulle tabelle monitor.mysql_server_read_only_log, monitor.mysql_server_replication_lag_log.
Manutenzione
ProxySQL> UPDATE mysql_servers SET status='OFFLINE_SOFT' WHERE hostname='10.0.0.5';
ProxySQL> UPDATE mysql_servers SET status='OFFLINE_HARD' WHERE hostname='10.0.0.4';
ProxySQL> LOAD MYSQL SERVERS TO RUNTIME;
...
ProxySQL> UPDATE mysql_servers SET status='ONLINE' WHERE status NOT IN ('ONLINE');
ProxySQL> LOAD MYSQL SERVERS TO RUNTIME;
Gestire le manutenzioni dei server e' molto semplice con ProxySQL.
Con OFFLINE_SOFT non vengono accettate nuove connessioni ma le connessioni attive
vengono mantenute. Con OFFLINE_HARD vengono abortite immediatamente eventuali connessioni presenti.
OFFLINE_HARD e' tecnicamente analogo ad una DELETE ma e' piu' comodo il primo comando se il nodo verra'
riattivato.
Per riattivare un nodo lo si imposta ad ONLINE.
Esiste un ulteriore stato impostato automaticamente da ProxySQL: SHUNNED,
che viene usato da ProxySQL quando esclude un nodo dall'hostgruop (eg. perche' e' in ritardo sulla replica dati).
Galera Cluster
ProxySQL> INSERT INTO mysql_servers (hostgroup_id,hostname,port) VALUES (10,'10.0.0.1',3306);
ProxySQL> INSERT INTO mysql_servers (hostgroup_id,hostname,port) VALUES (10,'10.0.0.2',3306);
ProxySQL> INSERT INTO mysql_servers (hostgroup_id,hostname,port) VALUES (10,'10.0.0.3',3306);
ProxySQL> INSERT INTO mysql_galera_hostgroups (writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
offline_hostgroup, active, max_writers, writer_is_also_reader, max_transactions_behind)
VALUES (10, 20, 30, 40, 1, 1, 1, 100);
ProxySQL> LOAD MYSQL SERVERS TO RUNTIME;
ProxySQL> SAVE MYSQL SERVERS TO DISK;
Un'alternativa alla semplice replica MySQL e' l'utilizzo di Galera Cluster
che e' molto piu' complessa perche' tipicamente configurata in modalita' multimaster,
la gestione dei nodi e' dinamica, gli stati dei nodi sono molteplici
[NdA Initialized, Joining, Waiting on SST, Joined, Donor, Synced],
in caso di SST/IST verso un nodo da ripristinare
viene scelto un nodo Donor che puo' essere rallentato, ...
Per la configurazione abbiamo bisogno di tre host e che non vi sia nulla nella tabella
mysql_replication_hostgroups, cosa che possiamo ottenere semplicemente con una DELETE...
Inseriti i nodi Galera basta inserire un record nella tabella mysql_galera_hostgroups
indicando gli opportuni hostgroup.
Le possibilita' di configurazione sono molteplici: in questo caso abbiamo scelto
di utilizzare un solo nodo in scrittura per ridurre le contese nei certification test
e di utilizzare il nodo in scrittura anche come nodo di lettura.
La gestione dei corretti indirizzamenti con Galera,
rispetto alla normale replica MySQL
e' molto piu' complessa,
ma e' ProxySQL che tiene conto di tutti gli stati possibili dei nodi
assegnando a ciascuno gli hostgroup corretti.
Oltre al Galera Cluster ProxySQL e' in grado di gestire con altre tabelle di configurazioni
ma modalita' simili l'InnoDB Cluster, MySQL Aurora, ...
Read vs Write (rules)
Vi sono molti modi per gestire la separazione del carico di letture/scritture con ProxySQL.
Una prima tecnica e' quella di utilizzare porte differenti per le connessioni Read/Write e quelle Read-Only,
un'altra possibilita' e' quella di utilizzare utenze diverse, ...
Nell'esempio che segue utilizziamo la tecnica piu' utilizzata con ProxySQL
perche' non richiede modifiche nelle configurazioni applicative o sulla base dati.
SELECT digest,SUBSTR(digest_text,0,25),
count_star,sum_time,sum_time/count_star avg_time,min_time, max_time,
ROUND(sum_time*100.00/(SELECT SUM(sum_time) FROM stats_mysql_query_digest),3) pct
FROM stats_mysql_query_digest
WHERE digest_text LIKE 'SELECT%'
AND sum_time/count_star > 1000000
ORDER BY sum_time DESC LIMIT 20;
Con questa select determiniamo i DIGEST delle query che e' opportuno far eseguire
sui secondary perche' sono piu' pesanti come prestazioni e non impattano
le applicazioni.
Naturalmente i risultati vanno confrontati con quanto risulta sui nodi MySQL
ed i particolare sulla tabella performance_schema.events_statements_summary_by_digest.
ProxySQL> INSERT INTO mysql_query_rules (rule_id,active,digest,destination_hostgroup,apply)
VALUES (1,1,'0x3492452344353455',2,1);
ProxySQL> LOAD MYSQL QUERY RULES TO RUNTIME;
ProxySQL> SAVE MYSQL QUERY RULES TO DISK;
In questo modo le query che corrispondono al DIGEST inserito vengono redirette sull'hostgroup Read-Only.
E' spesso citato come esempio di separazione di carico l'utilizzo di regole basate su regular expession.
Non e' sempre utilizzabile perche' spesso negli OLTP vengono eseguite SELECT su valori appena inseriti
nelle transazioni... in ogni caso ecco la configurazione:
ProxySQL> DELETE FROM mysql_query_rules;
ProxySQL> INSERT INTO mysql_query_rules (rule_id,active,match_digest,destination_hostgroup,apply)
VALUES (1,1,'^SELECT.*FOR UPDATE$',1,1), (2,1,'^SELECT',2,1);
ProxySQL> LOAD MYSQL QUERY RULES TO RUNTIME;
ProxySQL> SAVE MYSQL QUERY RULES TO DISK;
Le due regole definite tengono conto delle SELECT FOR UPDATE che vanno eseguite sul nodo in scrittura
per effetturare il lock, ma non possono tenere conto dell'eventuale ritardo nella replica,
della necessita' di utilizzare la stessa transazione, ... se possibile utilizzate uno dei metodi precedenti!
Le regole possono essere concatenate impostando i campi flagIN, flagOUT, apply
consentendo cosi' di gestire condizioni complesse su tutti i campi disponibili.
Query Cache
ProxySQL> INSERT INTO mysql_query_rules (rule_id,active,digest,cache_ttl,apply)
VALUES (5,1,'0x3492452344353455',10000,1);
ProxySQL> LOAD MYSQL QUERY RULES TO RUNTIME;
ProxySQL> SAVE MYSQL QUERY RULES TO DISK;
Utilizzando le regole e' possibile anche effettuare il caching delle query.
La configurazione della regola e' molto semplice: basta impostare il valore del campo cache_ttl
che va espresso in millisecondi.
Al momento
non sono disponibili modalita' differenti dal TTL (Time To Live) per invalidare le query mantenute in cache,
quindi la scelta delle query va svolta con attenzione, ma su alcune applicazioni i vantaggi sono notevoli.
Connection Pooling
L'utilizzo del connection pooling con ProxySQL e' automatico
e non richiede impostazioni per essere utilizzato con i parametri di default.
Il primo significativo effetto sui nodi MySQL e' la diminuzione del numero
di sessioni connesse ed e' facilmente controllabile con la tabella stats.stats_mysql_connection_pool.
Le impostazioni possibili sono molteplici.
Il parametro max_connections puo' essere impostato come variabile, a livello di utente,
a livello di server.
In diverse tabelle e' possibile indicare un peso [NdA campo weight] per effettuare un bilanciamento
che ProxySQL effettua in modo statistico.
E' possibile disabilitare con una regola il multiplexing impostando il campo
mysql_query_rules.multiplexing ed e' poi possibile controllarlo sulla tabella
stats_mysql_processlist.extended_info.
Altri Load Balancer, Proxy e database
Quando il numero di connessioni ad un database e' elevato e' spesso opportuno utilizzare
un connection pooling.
In molti casi si utilizzano connection pool applicativi
ma e' anche possibile utilizzare tool esterni.
La scelta di un load balancer presenta molteplici possibilita'
in termini di funzionalita', prestazioni, numero di connessioni supportate, costi, ...
Tra i moltissimi fornitori di load balancer Hardware:
F5 BIG-IP Local Traffic Manager (LTM),
Citrix NetScaler,
Cisco,
Radware,
Kemp,
Barracuda,
...
Tra i moltissimi fornitori di load balancer Software generici:
HAProxy
(sito ufficiale),
NGINX,
...
Ed infine i proxy server, specifici per MySQL:
ProxySQL (che abbiamo descritto in questa pagina),
Max Scale,
MySQL Router,
...
Si deve ricordare che praticamente tutti i fornitori HW
hanno anche una versione SW, che tutti i balancer SW possono
essere installati su appliance e che per fare bilanciamento
non e' strettamente necessario un load balancer
(lo fanno anche il DNS ed i DB driver).
Se si aggiunge la possibilita' che ogni componente sia virtualizzato
oppure mantenuto su un container gestito da Kubernetes si capisce
la grande varieta' delle alternnative.
I load balancer riportati in precedenza possono essere utilizzati per tutte le basi dati
e sono tipicamente molto veloci
mentre i proxy server che utilizzano il protocollo MySQL possono essere utilizzati solo
con MySQL (e tutti i fork) ma hanno funzionalita' molto piu' ricche come lo sharding
o il load balancing delle sole SELECT.
Facendo un parallelo, forse troppo ardito,
un tool per gestire le connessioni a Postgres
e' PGPool-II;
naturalmente e' adatto alla base dati PostgreSQL e non a MySQL
ma presenta una serie di funzionalita' simili a ProxySQL:
entrambe sono molto intelligenti e riescono ad integrarsi
nelle piu' complesse architetture in HA.
Viste molte alternative, ProxySQL resta un'ottima scelta come proxy per MySQL
ed i suoi fork in tutte le configurazione di replica e di cluster...
non e' l'unica scelta possibile ma una delle piu' efficienti e ricche di funzionalita'.
Varie ed eventuali
Le funzionalita' di ProxySQL sono molto ampie e sono state appena accennate in questa
paginetta introduttiva
[NdA statistiche, firewall, utenze multiple, sharding, ...].
ProxySQL maschera la versione dei database MySQL perche' presenta all'applicazione
un valore che e' impostabile. E' cosi' possibile
fingere di far utilizzare una 5.7 o una 8.0 perche' tra loro sono presenti sottili differenze
che a volte hanno impatti sulle applicazioni.
Oltre che MySQL ProxySQL supporta anche la base dati colonnare
ClickHouse ed SQLite.
Lo stesso ProxySQL puo' essere utilizzato per operare contemporaneamente
su piu' DB replicati e cluster separati che utilizzano tecnologie differenti;
basta che sia definito correttamente il routing delle connessioni.
L'evoluzione delle diverse versioni di ProxySQL e le relative funzionalita'
sono riassunti in questa pagina.