ProxySQL è uno dei migliori proxy disponibili per MySQL. Ha introdotto una grande quantità di opzioni per gli amministratori di database. Ha reso possibile modellare il traffico del database ritardando, memorizzando nella cache o riscrivendo le query al volo. Può anche essere utilizzato per creare un ambiente in cui i failover non influiranno sulle applicazioni e sarà trasparente per loro. Abbiamo già trattato le funzionalità più importanti di ProxySQL nei precedenti post del blog:
- Come utilizzare ClusterControl e ProxySQL per la memorizzazione nella cache delle query
- Come creare un firewall SQL con ClusterControl e ProxySQL
- Come distribuire un cluster ProxySQL
- Come distribuire facilmente l'ambiente di replica MySQL con ProxySQL per un'elevata disponibilità
Abbiamo anche un tutorial che copre ProxySQL che mostra come può essere utilizzato nelle configurazioni di MySQL e MariaDB.
Abbastanza recentemente è stato rilasciato ProxySQL 2.0.3, una versione di patch per la serie 2.0. I bug vengono risolti e la linea 2.0 sembra iniziare a ottenere la trazione che merita. In questo post del blog vorremmo discutere le principali modifiche introdotte in ProxySQL 2.0.
Lettura causale utilizzando GTID
Tutti coloro che hanno dovuto affrontare il ritardo di replica e hanno lottato con scenari di lettura dopo scrittura interessati dal ritardo di replica saranno sicuramente molto soddisfatti di questa funzionalità. Finora, negli ambienti di replica MySQL, l'unico modo per garantire letture causali era leggere dal master (e non importa se si utilizza la replica asincrona o semisincrona). Un'altra opzione era quella di scegliere Galera, che aveva un'opzione per imporre letture causali da, come, sempre (prima era wsrep-causal-reads e ora è wsrep-sync-wait). Abbastanza recentemente (in 8.0.14) la replica del gruppo MySQL ha ottenuto funzionalità simili. La replica regolare, tuttavia, da sola, non può affrontare questo problema. Fortunatamente, ProxySQL è qui e ci offre un'opzione per definire in base alla regola per query con ciò che il gruppo host legge che corrisponde a quella regola di query dovrebbe essere coerente. L'implementazione viene fornita con il lettore binlog ProxySQL e può funzionare con il formato binlog ROW per MySQL 5.7 e versioni successive. Solo Oracle MySQL è supportato a causa della mancanza di funzionalità richieste in MariaDB. Questa caratteristica e i suoi dettagli tecnici sono stati spiegati sul blog ufficiale di ProxySQL.
SSL per connessioni frontend
ProxySQL ha sempre avuto il supporto per la connessione SSL back-end ma mancava della crittografia SSL per le connessioni provenienti dai client. Non è stato un grosso problema, dato che il modello di distribuzione consigliato consisteva nel collocare ProxySQL sui nodi dell'applicazione e utilizzare un socket Unix sicuro per connettersi dall'app al proxy. Questa è comunque una raccomandazione, soprattutto se si utilizza ProxySQL per le query di memorizzazione nella cache (i socket Unix sono più veloci delle connessioni TCP, anche quelle locali e con la cache è bene evitare di introdurre inutili latenza). La cosa buona è che con ProxySQL 2.0 ora c'è una scelta poiché ha introdotto il supporto SSL per le connessioni in entrata. Puoi abilitarlo facilmente impostando mysql-have_ssl su "true". L'abilitazione di SSL non comporta un impatto inaccettabile sulle prestazioni. Al contrario, secondo i risultati del blog ufficiale di ProxySQL, il calo delle prestazioni è molto basso.
Supporto nativo per il cluster Galera
Galera Cluster è stato supportato da ProxySQL quasi dall'inizio, ma finora è stato fatto tramite lo script esterno che (in genere) è stato chiamato dallo scheduler interno di ProxySQL. Stava allo script assicurarsi che la configurazione di ProxySQL fosse corretta, che lo scrittore (oi writer) fosse stato rilevato e configurato correttamente nel gruppo host dei writer. Lo script è stato in grado di rilevare i diversi stati che il nodo Galera potrebbe avere (primario, non primario, sincronizzato, donatore/non sincronizzato, unione, unito) e contrassegnare il nodo di conseguenza come disponibile o meno. Il problema principale è che la sceneggiatura originale non è mai stata intesa come nient'altro che la prova del concetto scritta in Bash. Tuttavia, quando è stato distribuito insieme a ProxySQL, ha iniziato a essere migliorato, modificato da contributori esterni. Altri (come Percona) hanno cercato di creare i propri script, in bundle con il loro software. Alcune correzioni sono state introdotte nello script dal repository ProxySQL, altre sono state introdotte nella versione Percona dello script. Ciò ha portato a confusione e anche se tutti gli script comunemente usati hanno gestito il 95% dei casi d'uso, nessuno di quelli popolari ha davvero coperto tutte le diverse situazioni e variabili che il cluster Galera potrebbe finire per utilizzare. Fortunatamente, ProxySQL 2.0 viene fornito con il supporto nativo per Galera Cluster. Ciò fa sì che ProxySQL supporti internamente la replica MySQL, MySQL Group Replication e ora Galera Cluster. Il modo in cui è fatto è molto simile. Vorremmo coprire la configurazione di questa funzione in quanto potrebbe non essere chiara a prima vista.
Come con la replica MySQL e MySQL Group Replication, è stata creata una tabella in ProxySQL:
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Ci sono numerose impostazioni da configurare e le esamineremo una per una. Prima di tutto, ci sono quattro gruppi host:
- Writer_hostgroup - conterrà tutti i writer (con read_only=0) fino all'impostazione "max_writers". Per impostazione predefinita è solo uno scrittore
- Backup_writer_hostgroup - contiene i writer rimanenti (sola_lettura=0) che rimangono dopo che "max_writers" è stato aggiunto a writer_hostgroup
- Reader_hostgroup - contiene lettori (sola_lettura=1), può contenere anche scrittori di backup, secondo l'impostazione 'writer_is_also_reader'
- Offline_hostgroup - contiene nodi ritenuti non utilizzabili (offline o in uno stato che rende impossibile la gestione del traffico)
Quindi abbiamo le impostazioni rimanenti:
- Attivo - se la voce in mysql_galera_hostgroups è attiva o meno
- Max_writers - quanti nodi al massimo possono essere inseriti nel writer_hostgroup
- Writer_is_also_reader - se impostato su 0, i writer (read_only=0) non verranno inseriti in reader_hostgroup. Se impostato su 1, i writer (read_only=0) verranno inseriti in reader_hostgroup. Se impostato su 2, i nodi di backup_writer_hostgroup verranno inseriti in reader_hostgroup. Questo è un po' complesso, quindi presenteremo un esempio più avanti in questo post del blog
- Max_transactions_behind - in base a wsrep_local_recv_queue, la coda massima accettabile. Se la coda sul nodo supera max_transactions_behind, il nodo specificato verrà contrassegnato come SHUNNED e non sarà disponibile per il traffico
La sorpresa principale potrebbe essere la gestione dei lettori, che è diversa da come funzionava lo script incluso in ProxySQL. Prima di tutto, quello che devi tenere a mente è il fatto che ProxySQL usa read_only=1 per decidere se il nodo è un lettore o meno. Questo è comune nelle configurazioni di replica, non così comune in Galera. Pertanto, molto probabilmente, vorrai utilizzare l'impostazione "writer_is_also_reader" per configurare come aggiungere i lettori al reader_hostgroup. Consideriamo tre nodi Galera, tutti hanno read_only=0. Abbiamo anche max_writers=1 poiché vogliamo indirizzare tutte le scritture verso un nodo. Abbiamo configurato mysql_galera_hostgroups come segue:
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Esaminiamo tutte le opzioni:
writer_is_also_reader=0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Questo risultato è diverso da quello che vedresti negli script:lì avresti nodi rimanenti contrassegnati come lettori. Qui, dato che non vogliamo che gli scrittori siano lettori e dato che non c'è nessun nodo con read_only=1, nessun lettore sarà configurato. Un writer (come per max_writers), nodi rimanenti in backup_writer_hostgroup.
writer_is_also_reader=1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Qui vogliamo che i nostri scrittori agiscano come lettori, quindi tutti loro (attivi e di backup) verranno inseriti nel reader_hostgroup.
writer_is_also_reader=2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)Questa è un'impostazione per coloro che non vogliono che il loro scrittore attivo gestisca le letture. In questo caso verranno utilizzati per le letture solo i nodi di backup_writer_hostgroup. Tieni inoltre presente che il numero di lettori cambierà se imposti max_writers su un altro valore. Se lo impostassimo su 3, non ci sarebbero i writer di backup (tutti i nodi finirebbero nel gruppo host del writer), quindi, ancora una volta, non ci sarebbero nodi nel gruppo host del lettore.
Ovviamente, vorrai configurare le regole di query in base alla configurazione del gruppo host. Non passeremo attraverso questo processo qui, puoi controllare come può essere fatto nel blog ProxySQL. Se desideri testare come funziona in un ambiente Docker, abbiamo un blog che spiega come eseguire il cluster Galera e ProxySQL 2.0 su Docker.
Altre modifiche
Quello che abbiamo descritto sopra sono i miglioramenti più notevoli in ProxySQL 2.0. Ce ne sono molti altri, come da changelog. Vale la pena menzionare i miglioramenti alla cache delle query (ad esempio, l'aggiunta di PROXYSQL FLUSH QUERY CACHE) e le modifiche che consentono a ProxySQL di fare affidamento su super_read_only per determinare master e slave nella configurazione della replica.
Ci auguriamo che questa breve panoramica delle modifiche in ProxySQL 2.0 ti aiuti a determinare quale versione di ProxySQL dovresti usare. Tieni presente che il ramo 1.4, anche se non riceverà nuove funzionalità, viene comunque mantenuto.
