ProxySQL ha guadagnato molto interesse in questo momento nel mondo dei database MySQL e MariaDB, per non parlare di ClickHouse che aiuta a sostenere il caso di ProxySQL.
Si può affermare con certezza che ProxySQL è diventato il proxy di database predefinito per la famiglia di database MySQL (come Percona Server, Oracle MySQL, Galera Cluster o anche con MariaDB).
ProxySQL è, infatti, un efficiente risolutore di problemi con funzionalità estremamente ricche che gestiscono la comunicazione database client-server; fungendo da middleware in un approccio molto avanzato e performante.
Ha reso possibile la capacità di 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. La community di ProxySQL è molto reattiva e crea costantemente correzioni, patch e versioni in modo tempestivo.
Ma quanto è performante la tua configurazione ProxySQL e come puoi determinare che la tua configurazione è stata ottimizzata correttamente? Questo blog si concentra sulla determinazione delle prestazioni dei tuoi nodi ProxySQL e su come monitorarli in modo efficiente.
Problemi comuni che puoi incontrare con ProxySQL
L'installazione predefinita di ProxySQL include uno strumento di ottimizzazione semplice e leggero in grado di gestire carichi da medi a pesanti. Sebbene ciò possa dipendere dal tipo di query inviate al middleware, può avere un impatto e iniziare a riscontrare colli di bottiglia e latenza.
Problemi di latenza
Ad esempio, può essere difficile determinare cosa può portare a problemi di latenza se non hai un sistema di monitoraggio. Allo stesso modo, puoi monitorare o controllare manualmente lo schema delle statistiche proprio come di seguito:
mysql> select * from stats_mysql_connection_pool\G
*************************** 1. row ***************************
hostgroup: 20
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 2. row ***************************
hostgroup: 20
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
*************************** 3. row ***************************
hostgroup: 10
srv_host: 192.168.10.227
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 10855
*************************** 4. row ***************************
hostgroup: 40
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 5. row ***************************
hostgroup: 40
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
5 rows in set (0.01 sec)Questo ti permette di monitorare la latenza in base al gruppo host. Ma aumenta la seccatura a meno che tu non debba innovare e sviluppare uno o più script che riescano a informarti.
Errori di connessione del client
Il timeout massimo della connessione dovuto al numero massimo di connessioni nel backend (nodo del database stesso) può portarti alla perplessità se non sei in grado di determinare qual è la fonte principale del problema. Puoi controllare il database delle statistiche per verificare la presenza di tali connessioni interrotte nel client o anche nel server e le connessioni negate come segue,
mysql> select * from stats.stats_mysql_global where variable_name like '%connect%';
+-------------------------------------+----------------+
| Variable_Name | Variable_Value |
+-------------------------------------+----------------+
| Client_Connections_aborted | 0 |
| Client_Connections_connected | 205 |
| Client_Connections_created | 10067 |
| Server_Connections_aborted | 44 |
| Server_Connections_connected | 30 |
| Server_Connections_created | 14892 |
| Server_Connections_delayed | 0 |
| Client_Connections_non_idle | 205 |
| Access_Denied_Max_Connections | 0 |
| Access_Denied_Max_User_Connections | 0 |
| MySQL_Monitor_connect_check_OK | 41350 |
| MySQL_Monitor_connect_check_ERR | 92 |
| max_connect_timeouts | 0 |
| Client_Connections_hostgroup_locked | 0 |
| mysql_killed_backend_connections | 0 |
+-------------------------------------+----------------+
15 rows in set (0.01 sec)È anche l'ideale se puoi verificare e controllare il numero massimo di connessioni dell'utente back-end per vedere quale è il numero di limiti di connessione che può aprire o utilizzare. Ad esempio, ho quanto segue nel mio test,
mysql> select username, active, transaction_persistent, max_connections from mysql_users;
+---------------+--------+------------------------+-----------------+
| username | active | transaction_persistent | max_connections |
+---------------+--------+------------------------+-----------------+
| proxydemo | 1 | 1 | 10000 |
| proxysql-paul | 1 | 1 | 10000 |
+---------------+--------+------------------------+-----------------+
2 rows in set (0.00 sec)Query lente
Identificare le query lente non può essere così difficile in ProxySQL, ma può essere inefficiente se eseguito manualmente. Puoi verificarlo se stai facendo manualmente con la variabile,
mysql> select * from stats_mysql_global where variable_name like '%slow%';
+---------------+----------------+
| Variable_Name | Variable_Value |
+---------------+----------------+
| Slow_queries | 2 |
+---------------+----------------+
1 row in set (0.00 sec)Anche se questo può fornirti alcuni numeri, puoi controllare nella tabella stats_mysql_query_digest sotto lo schema delle statistiche se vuoi scavare più a fondo. Ad esempio di seguito,
mysql> select count_star,sum_time,(sum_time/count_star)/1000 as average_time_ms,digest_text
-> from stats_mysql_query_digest
-> where count_star > 100 order by average_time_ms desc limit 10;
+------------+----------+-----------------+--------------------------------------+
| count_star | sum_time | average_time_ms | digest_text |
+------------+----------+-----------------+--------------------------------------+
| 884 | 15083961 | 17 | UPDATE sbtest1 SET k=k+? WHERE id=? |
| 930 | 16000111 | 17 | UPDATE sbtest9 SET k=k+? WHERE id=? |
| 914 | 15695810 | 17 | UPDATE sbtest4 SET k=k+? WHERE id=? |
| 874 | 14467420 | 16 | UPDATE sbtest8 SET k=k+? WHERE id=? |
| 904 | 15294520 | 16 | UPDATE sbtest3 SET k=k+? WHERE id=? |
| 917 | 15228077 | 16 | UPDATE sbtest6 SET k=k+? WHERE id=? |
| 907 | 14613238 | 16 | UPDATE sbtest2 SET k=k+? WHERE id=? |
| 900 | 15113004 | 16 | UPDATE sbtest5 SET k=k+? WHERE id=? |
| 917 | 15299381 | 16 | UPDATE sbtest7 SET k=k+? WHERE id=? |
| 883 | 15010119 | 16 | UPDATE sbtest10 SET k=k+? WHERE id=? |
+------------+----------+-----------------+--------------------------------------+
10 rows in set (0.01 sec)
che cattura le prime 10 query lente in base a un campionamento di 100.
Utilizzo della memoria
Gli elementi hardware come CPU, disco e memoria devono essere monitorati per garantire che il tuo ProxySQL sia performante. Tuttavia, la cosa più cruciale è la memoria, poiché ProxySQL utilizzerà molto la memoria a causa del meccanismo della cache delle query. Per impostazione predefinita, la cache delle query, che dipende dalla variabile mysql-query_cache_size_MB, è impostata su 256 Mib. A questo proposito, può arrivare a una situazione in cui utilizza la memoria e devi determinare e diagnosticare se trovi problemi all'interno del tuo nodo ProxySQL o addirittura se vieni notato all'interno del livello dell'applicazione.
Quando lo identifichi, potresti finire per controllare le tabelle negli schemi stats_history e stats. Puoi vedere l'elenco delle tabelle che possono aiutarti durante la diagnosi,
mysql> show tables from stats;
| stats_memory_metrics |
19 rows in set (0.00 sec)
or,
mysql> show tables from stats_history;
+------------------------+
| tables |
+------------------------+
| mysql_connections |
| mysql_connections_day |
| mysql_connections_hour |
| mysql_query_cache |
| mysql_query_cache_day |
| mysql_query_cache_hour |
| system_cpu |
| system_cpu_day |
| system_cpu_hour |
| system_memory |
| system_memory_day |
| system_memory_hour |
+------------------------+
15 rows in set (0.00 sec)Determinazione efficiente delle prestazioni del tuo ProxySQL
Ci sono diversi modi per determinare le prestazioni del tuo nodo ProxySQL. L'utilizzo di ClusterControl offre la possibilità di determinarlo con grafici semplici ma diretti. Ad esempio, quando ProxySQL è integrato nel tuo cluster, sarai in grado di impostare le regole di query, modificare le max_connections dell'utente, determinare le query principali, modificare un gruppo host di utenti e fornirti le prestazioni del tuo nodo ProxySQL. Guarda gli screenshot qui sotto...
Tutto quello che vedi è la prova di quanto abilmente ClusterControl possa fornirti informazioni su le prestazioni del tuo nodo ProxySQL. Ma questo non ti limita a quello. ClusterControl dispone anche di dashboard ricchi e potenti che chiamiamo SCUMM, che include dashboard Panoramica di ProxySQL.
Se intendi determinare query lente, puoi semplicemente dare un'occhiata alla dashboard. Il controllo della distribuzione della latenza sui diversi gruppi host a cui sono assegnati i nodi di back-end ti aiuta ad avere una rapida visione delle prestazioni in base alla distribuzione. È possibile monitorare le connessioni client e server, fornendo informazioni dettagliate sulla cache delle query. Ancora più importante e non meno importante, fornisce l'utilizzo della memoria utilizzato dal nodo ProxySQL. Guarda i grafici sottostanti...
Questi grafici fanno parte della dashboard che ti aiuta semplicemente a determinare facilmente il prestazioni del tuo nodo ProxySQL.
ClusterControl non ti limita quando hai a che fare con ProxySQL. Inoltre, qui c'è una ricca funzionalità in cui puoi anche fare un backup o importare la configurazione che è molto importante quando hai a che fare con l'alta disponibilità per i tuoi nodi ProxySQL.
Conclusione
Non è mai stato così facile monitorare e determinare se hai problemi con il tuo ProxySQL. Come nell'esempio di questo blog, stiamo mostrando ClusterControl come uno strumento che può fornirti efficienza e fornirti informazioni dettagliate per determinare i problemi in sospeso che stai affrontando con i tuoi problemi relativi alle prestazioni.
