Avere un sistema di bilanciamento del carico o un proxy inverso davanti al server MySQL o MariaDB aggiunge un po' di complessità alla configurazione del database, il che potrebbe comportare che alcune cose si comportino diversamente. Teoricamente, un sistema di bilanciamento del carico che si trova di fronte ai server MySQL (ad esempio un HAProxy di fronte a un cluster Galera) dovrebbe semplicemente agire come un gestore di connessione e distribuire le connessioni ai server di back-end secondo un algoritmo di bilanciamento. MySQL, d'altra parte, ha il suo modo di gestire le connessioni client. Idealmente, dovremmo configurare questi due componenti insieme in modo da evitare comportamenti imprevisti e restringere la superficie di risoluzione dei problemi durante il debug dei problemi.
Se si dispone di tale configurazione, è importante comprendere questi componenti poiché possono influire sulle prestazioni complessive del servizio di database. In questo post del blog ci addentreremo nelle max_connections di MySQL e HAProxy maxconn rispettivamente le opzioni. Nota che il timeout è un altro parametro importante che dovremmo conoscere, ma lo tratteremo in un post separato.
Connessioni massime di MySQL
Risorse correlate MySQL Load Balancing con HAProxy - Tutorial Webinar Replay e Q&A:come distribuire e gestire ProxySQL, HAProxy e MaxScale Webinar Replay &Slides:Come costruire infrastrutture di database scalabili con MariaDB e HAProxyIl numero di connessioni consentite a un server MySQL è controllato da max_connections variabile di sistema. Il valore predefinito è 151 (MySQL 5.7).
Per determinare un buon numero per max_connections , le formule di base sono:
Dove,
**Variabile innodb_additional_mem_pool_size viene rimosso in MySQL 5.7.4+. Se stai utilizzando la versione precedente, prendi in considerazione questa variabile.
E,
Utilizzando le formule di cui sopra, possiamo calcolare un adatto max_connections valore per questo particolare server MySQL. Per avviare il processo, interrompere tutte le connessioni dai client e riavviare il server MySQL. Assicurati di avere solo il numero minimo di processi in esecuzione in quel particolare momento. Puoi usare 'mysqladmin' o 'SHOW PROCESSLIST' per questo scopo:
$ mysqladmin -uroot -p processlist
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| 232172 | root | localhost | NULL | Query | 0 | NULL | show processlist | 0.000 |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
1 row in set (0.00 sec)Dall'output sopra, possiamo dire che solo un utente è connesso al server MySQL che è root. Quindi, recupera la RAM disponibile (in MB) dell'host (guarda nella colonna 'disponibile'):
$ free -m
total used free shared buff/cache available
Mem: 3778 1427 508 148 1842 1928
Swap: 2047 4 2043A titolo informativo, la colonna 'disponibile' fornisce una stima della quantità di memoria disponibile per l'avvio di nuove applicazioni, senza swap (disponibile solo nel kernel 3.14+).
Quindi, specifica la memoria disponibile, 1928 MB nella seguente istruzione:
mysql> SELECT ROUND((1928 - (ROUND((@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@query_cache_size + @@tmp_table_size + @@key_buffer_size) / 1024 / 1024))) / (ROUND(@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@thread_stack + @@join_buffer_size + @@binlog_cache_size) / 1024 / 1024)) AS 'Possible Max Connections';
+--------------------------+
| Possible Max Connections |
+--------------------------+
| 265 |
+--------------------------+**Variabile innodb_additional_mem_pool_size viene rimosso in MySQL 5.7.4+. Se stai utilizzando la versione precedente, prendi in considerazione questa variabile.
Da questo esempio, possiamo avere fino a 265 connessioni MySQL contemporaneamente in base alla RAM disponibile dell'host. Non ha senso configurare un valore superiore a quello. Quindi, aggiungi la seguente riga all'interno del file di configurazione di MySQL, sotto la direttiva [mysqld]:
max_connections = 265Riavvia il servizio MySQL per applicare la modifica. Quando il totale delle connessioni simultanee raggiunge 265, viene visualizzato un errore "Troppe connessioni" quando si tenta di connettersi al server mysqld. Ciò significa che tutte le connessioni disponibili sono utilizzate da altri client. MySQL consente effettivamente max_connections +1 client per connettersi. La connessione extra è riservata all'utilizzo da parte degli account che hanno il privilegio SUPER. Quindi, se riscontri questo errore, dovresti provare ad accedere al server come utente root (o qualsiasi altro utente SUPER) e guardare l'elenco dei processi per avviare la risoluzione dei problemi.
Connessioni massime di HAProxy
HAProxy ha 3 tipi di connessioni massime (maxconn):globale, defaults/listen e default-server. Si supponga che un'istanza HAProxy configurata con due listener, uno per l'ascolto multi-scrittore sulla porta 3307 (le connessioni sono distribuite a tutti i server MySQL di back-end) e un'altra è single-writer sulla porta 3308 (le connessioni vengono inoltrate a un singolo server MySQL):
global
...
maxconn 2000 #[a]
...
defaults
...
maxconn 3 #[b]
...
listen mysql_3307
...
maxconn 8 #[c]
balance leastconn
default-server port 9200 maxqueue 10 weight 10 maxconn 4 #[d]
server db1 192.168.55.171 check
server db2 192.168.55.172 check
server db3 192.168.55.173 check
listen mysql_3308
...
default-server port 9200 maxqueue 10 weight 10 maxconn 5 #[e]
server db1 192.168.55.171 check
server db2 192.168.55.172 check backup #[f]Diamo un'occhiata al significato di alcune righe di configurazione:
global.maxconn [a]
Il numero totale di connessioni simultanee a cui è consentito connettersi a questa istanza HAProxy. Di solito, questo valore è il valore più alto di tutti. In questo caso, HAProxy accetterà un massimo di 2000 connessioni alla volta e le distribuirà a tutti i listener definiti nel processo HAProxy, o lavoratore (è possibile eseguire più processi HAProxy utilizzando nbproc opzione).
HAProxy smetterà di accettare connessioni quando viene raggiunto questo limite. Il parametro "ulimit-n" viene regolato automaticamente su questo valore. Poiché i socket sono considerati equivalenti ai file dal punto di vista del sistema, il limite predefinito dei descrittori di file è piuttosto piccolo. Probabilmente vorrai aumentare il limite predefinito ottimizzando il kernel per i descrittori di file.
default.maxconn [b]
Valore predefinito delle connessioni massimo per tutti i listener. Non ha senso se questo valore è superiore a global.maxconn .
Se la riga "maxconn" non è presente nella stanza "listen" (listen.maxconn ), l'ascoltatore obbedirà a questo valore. In questo caso, il listener mysql_3308 riceverà un massimo di 3 connessioni alla volta. Per sicurezza, imposta questo valore uguale a global.maxconn , diviso per il numero di ascoltatori. Tuttavia, se desideri dare la priorità ad altri ascoltatori per avere più connessioni, usa listen.maxconn invece.
ascolta.maxconn [c]
Le connessioni massime consentite per il listener corrispondente. L'ascoltatore ha la precedenza su defaults.maxconn se specificato. Non ha senso se questo valore è superiore a global.maxconn .
Per un'equa distribuzione delle connessioni ai server back-end, come nel caso di un listener multi-writer (mysql_3307), imposta questo valore come listen.default-server.maxconn moltiplicare per il numero di server back-end. In questo esempio, un valore migliore dovrebbe essere 12 invece di 8 [c]. Se scegliamo di attenerci a questa configurazione, db1 e db2 dovrebbero ricevere un massimo di 3 connessioni ciascuno, mentre db3 riceverà un massimo di 2 connessioni (a causa del bilanciamento di lessconn), per un totale di 8 connessioni. Non raggiungerà il limite come specificato in [d].
Per listener single-writer (mysql_3308) in cui le connessioni devono essere allocate a uno e un solo server back-end alla volta, impostare questo valore in modo che sia uguale o superiore a listen.default-server.maxconn .
ascolta.default-server.maxconn [d][e]
Questo è il numero massimo di connessioni che ogni server back-end può ricevere alla volta. Non ha senso se questo valore è maggiore di listen.maxconn o defaults.maxconn . Questo valore dovrebbe essere inferiore o uguale a max_connections di MySQL variabile. In caso contrario, rischi di esaurire le connessioni al server MySQL di back-end, soprattutto quando le variabili di timeout di MySQL sono configurate a un valore inferiore ai timeout di HAProxy.
In questo esempio, abbiamo impostato ogni server MySQL per ottenere solo un massimo di 4 connessioni alla volta per i nodi Galera multi-writer [d]. Mentre il nodo Galera a scrittore singolo riceverà un massimo di 3 connessioni alla volta, a causa del limite che si applica da [b]. Poiché abbiamo specificato "backup" [f] sull'altro nodo, il nodo attivo riceverà immediatamente tutte e 3 le connessioni assegnate a questo listener.
La spiegazione di cui sopra può essere illustrata nel diagramma seguente:
Per riassumere la distribuzione delle connessioni, db1 dovrebbe ottenere un numero massimo di 6 connessioni (3 da 3307 + 3 da 3308). Il db2 riceverà 3 connessioni (a meno che db1 non si interrompa, dove ne otterrà altre 3) e db3 si attaccherà a 2 connessioni indipendentemente dalle modifiche alla topologia nel cluster.
Monitoraggio della connessione con ClusterControl
Con ClusterControl è possibile monitorare l'utilizzo della connessione MySQL e HAProxy dall'interfaccia utente. Lo screenshot seguente fornisce un riepilogo dell'advisor di connessione MySQL (ClusterControl -> Performance -> Advisors) in cui monitora le connessioni MySQL attuali e mai utilizzate per ogni server nel cluster:
Per HAProxy, ClusterControl si integra con la pagina delle statistiche HAProxy per raccogliere le metriche. Questi sono presentati nella scheda Nodi:
Dallo screenshot sopra, possiamo dire che ogni server back-end su listener multi-scrittore ottiene un massimo di 8 connessioni. Sono in esecuzione 4 sessioni simultanee. Questi sono evidenziati nel quadrato rosso in alto, mentre il listener single-writer serve 2 connessioni e le inoltra rispettivamente a un singolo nodo.
Conclusione
La configurazione delle connessioni massime per HAProxy e il server MySQL è importante per garantire una buona distribuzione del carico ai nostri server di database e proteggere i server MySQL dal sovraccarico o dall'esaurimento delle sue connessioni.
