ProxySQL è un noto sistema di bilanciamento del carico nel mondo MySQL:viene fornito con un ottimo set di funzionalità che ti consentono di assumere il controllo del tuo traffico e modellarlo come meglio credi. Può essere implementato in molti modi diversi - nodi dedicati, collocazione con host di applicazioni, approccio silo - tutto dipende dall'esatto ambiente e dai requisiti aziendali. La sfida comune è che tu, nella maggior parte dei casi, desideri che i tuoi nodi ProxySQL contengano la stessa configurazione. Se si ridimensiona il cluster e si aggiunge un nuovo server a ProxySQL, si desidera che il server sia visibile su tutte le istanze ProxySQL, non solo su quella attiva. Questo porta alla domanda:come assicurarsi di mantenere la configurazione sincronizzata su tutti i nodi ProxySQL?
Puoi provare ad aggiornare tutti i nodi manualmente, il che non è sicuramente efficiente. Puoi anche utilizzare una sorta di strumenti di orchestrazione dell'infrastruttura come Ansible o Chef per mantenere la configurazione tra i nodi in uno stato noto, apportando le modifiche non direttamente su ProxySQL ma tramite lo strumento che utilizzi per organizzare il tuo ambiente.
Se ti capita di utilizzare ClusterControl, viene fornito con una serie di funzionalità che ti consentono di sincronizzare la configurazione tra le istanze ProxySQL ma questa soluzione ha i suoi svantaggi:è un'azione manuale, devi ricordarti di eseguirlo dopo una modifica della configurazione. Se ti dimentichi di farlo, potresti avere una brutta sorpresa se, ad esempio, keepalived sposterà l'IP virtuale nell'istanza ProxySQL non aggiornata.
Nessuno di questi metodi è semplice o affidabile al 100% e la situazione è quando i nodi ProxySQL hanno configurazioni diverse e potrebbero essere potenzialmente pericolosi.
Fortunatamente, ProxySQL viene fornito con una soluzione per questo problema:ProxySQL Cluster. L'idea è abbastanza semplice:puoi definire un elenco di istanze ProxySQL che parleranno tra loro e informeranno gli altri sulla versione della configurazione che ciascuna di esse contiene. La configurazione ha una versione, pertanto qualsiasi modifica di qualsiasi impostazione su qualsiasi nodo comporterà l'aumento della versione della configurazione:ciò attiva la sincronizzazione della configurazione e la nuova versione della configurazione viene distribuita e applicata su tutti i nodi che formano il cluster ProxySQL.
La versione recente di ClusterControl consente di configurare i cluster ProxySQL senza sforzo. Quando si distribuisce ProxySQL, è necessario selezionare l'opzione "Usa clustering nativo" per tutti i nodi che si desidera far parte del cluster.
Una volta che lo fai, hai praticamente finito - il resto accade sotto il cappuccio.
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)Su entrambi i server la tabella proxysql_servers è stata impostata correttamente con i nomi host dei nodi che formano il cluster. Possiamo anche verificare che le modifiche alla configurazione siano propagate correttamente nel cluster:
Abbiamo aumentato l'impostazione Max Connections su uno dei nodi ProxySQL (10.0 .0.131) e possiamo verificare che l'altro nodo (10.0.0.132) vedrà la stessa configurazione:
In caso di necessità di eseguire il debug del processo, possiamo sempre cercare di il log ProxySQL (di solito situato in /var/lib/proxysql/proxysql.log) dove vedremo informazioni come questa:
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:6032Questo è il log da 10.0.0.132 dove possiamo vedere chiaramente che una modifica alla configurazione per la tabella mysql_servers è stata rilevata su 10.0.0.131 e quindi è stata sincronizzata e applicata su 10.0.0.132, rendendola sincronizzata con l'altro nodo nel cluster.
Come puoi vedere, il clustering di ProxySQL è un modo semplice ma efficiente per garantire che la sua configurazione rimanga sincronizzata e aiuta in modo significativo a utilizzare distribuzioni ProxySQL più grandi. Facci sapere nei commenti qual è la tua esperienza con il clustering ProxySQL.
