Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Gestione delle connessioni
Man mano che le richieste della tua applicazione continuano ad aumentare, aumenta anche il traffico front-end. In uno scenario tipico, configuri il dimensionamento automatico a livello di applicazione per gestire un tale aumento di traffico in entrata. Di conseguenza, il livello delle applicazioni inizia a dimensionare automaticamente e vengono aggiunti altri server applicativi (istanze) per far fronte all'aumento del traffico. Dato che tutti i server delle applicazioni dispongono di impostazioni preconfigurate del pool di connessioni del database, il numero di connessioni al database in entrata aumenta in proporzione alle nuove istanze implementate.
Ad esempio, 20 server di applicazioni configurati con 200 connessioni al database ciascuno aprirebbero un totale di 4.000 connessioni al database. Se il pool di applicazioni si dimensiona fino a 200 istanze (ad esempio, nelle ore di punta), il numero totale di connessioni raggiungerà le 40.000. Con un carico di lavoro tipico, la maggior parte di queste connessioni è probabilmente inattiva. Tuttavia, il picco nelle connessioni potrebbe limitare la possibilità di dimensionare il database Amazon Aurora edizione compatibile con MySQL . Questo perché anche le connessioni inattive consumano memoria e altre risorse del server, come i descrittori di file. In genere, Aurora compatibile con MySQL utilizza meno memoria rispetto a MySQL Community Edition per mantenere lo stesso numero di connessioni. Tuttavia, l'utilizzo della memoria per le connessioni inattive non è ancora pari a zero.
Variabili di configurazione
È possibile controllare il numero di connessioni in entrata consentite per il database con due importanti variabili di configurazione del server: max_connections e max_connect_errors.
Variabile di configurazione max_connections
La variabile di configurazione max_connections limita il numero di connessioni al database per ogni istanza MySQL. È preferibile impostare un valore leggermente superiore al numero massimo di connessioni che si prevede di aprire su ciascuna istanza database.
Se hai abilitato anche performance_schema, fai molta attenzione con l'impostazione max_connections. Le strutture di memoria dello schema di prestazioni vengono dimensionate automaticamente in base alle variabili di configurazione del server, tra cui max_connections. Più alta è il valore della variabile, maggiore è la quantità di memoria utilizzata dallo schema di prestazioni. In casi estremi, questo può causare problemi dovuti all'esaurimento della memoria su tipi di istanze più piccoli. Tieni presente che l'attivazione di Performance Insights abiliterà automaticamente lo schema di prestazioni.
Variabile di configurazione max_connect_errors
La variabile di configurazione max_connect_errors determina quante richieste di connessione interrotta successive sono consentite da un determinato host client. Se l'host client supera il numero specificato di tentativi di connessione consecutivi non riusciti, il server lo blocca. Ulteriori tentativi di connessione da parte di quel client generano un errore.
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
Se ricevi errori "l'host è bloccato", evita di aumentare il valore della variabile max_connect_errors. Esamina invece i contatori diagnostici del server nella variabile di stato aborted_connects e nella tabella host_cach. Utilizza le informazioni raccolte per identificare e risolvere i client che riscontrano problemi di connessione. Inoltre, nota che questo parametro non ha effetto se skip_name_resolve è impostato su 1 (impostazione predefinita).
Consulta il manuale di riferimento MySQL per i dettagli su quanto segue:
Implementa un pool di connessioni
Un evento di scaling potrebbe aggiungere altri server applicativi, che a loro volta potrebbero far superare al server di database il numero di connessioni attive a pieno carico. L'aggiunta di un pool di connessioni o di un livello del proxy tra i server delle applicazioni e il database agisce come un imbuto, riducendo il numero totale di connessioni sul database. Lo scopo principale di un proxy è il riutilizzo delle connessioni al database tramite il multiplexing.
Da un lato, il proxy si connette al database con un numero controllato di connessioni. Dall'altro lato, il proxy accetta le connessioni alle applicazioni. Fornisce inoltre funzionalità aggiuntive, come la memorizzazione nella cache delle query, il buffering delle connessioni, la riscrittura e il routing delle query e il bilanciamento del carico. Il livello del pool di connessioni deve essere configurato per mantenere il numero massimo di connessioni al database al di sotto del numero a pieno carico. Il Server proxy per Amazon RDS
Puoi anche esplorare i seguenti proxy di terze parti che possono essere utilizzati con Aurora edizione compatibile con MySQL:
Evita le congestioni dovute alle connessioni
Valuta come si comporta il tuo pool di connessioni nel caso di un sovraccarico del database o di una replica troppo indietro rispetto al nodo primario. Quando configuri il server proxy o i pool di connessioni, assicurati di non reimpostare l'intero pool di connessioni in base a risposte lente del database (causate da problemi hardware o di storage sottostanti o da vincoli di risorse del database).
L'avvio improvviso di centinaia di connessioni genera una congestione dovuta alle connessioni perché vengono avviate un gran numero di richieste di nuove connessioni al database contemporaneamente. La congestione comporta un uso intensivo di risorse. La creazione di una nuova connessione al database in MySQL è un'operazione costosa perché il backend deve scambiare diversi pacchetti di rete per l'handshake iniziale, generare un nuovo processo, allocare la memoria, gestire l'autenticazione, ecc. Se viene ricevuto un gran numero di richieste in un breve periodo di tempo, può risultare che il database che non risponda.
MySQL ha un meccanismo per proteggersi da picchi di richieste di connessione simili. La variabile back_log può essere impostata sul numero di richieste che possono essere impilate durante un breve periodo di tempo prima che MySQL smetta momentaneamente di rispondere alle nuove richieste. Il valore viene applicato da un thread di gestione delle connessioni, che a sua volta potrebbe subire una congestione dovuta alle connessioni. Per ulteriori informazioni, consulta il Manuale di riferimento di MySQL.
Se la connessione è configurata per essere ripristinata quando il database è lento, inizierai il ciclo più volte. Analogamente, se prevedi un aumento improvviso del traffico del database in determinati momenti della giornata (ad esempio, all'apertura del mercato azionario), inizializza il pool di connessioni in modo da non tentare di aprire molte connessioni mentre inizia un carico di traffico elevato..
