Nei log degli errori di MySQL, vedo questi pochi avvisi come questi:
120611 16:12:30 [Warning] Aborted connection 2619503 to db: "db_name" user: "user_name" host: "webapp_hostname" (Got an error reading communication packets)
Non ho notato alcuna perdita di dati di per sé, quindi mi chiedo cosa significhi questo avviso o cosa lo causa e se come si potrebbe risolvere il problema che li causa. Questo è su RHEL 6.1 e MySQL Enterprise 5.5.
Answer
Uno dei killer silenziosi di MySQL Connections è il pacchetto MySQL.
Per prima cosa, vediamo cosa sia un pacchetto MySQL.
Secondo la pagina 99 di “Comprensione di MySQL Internals” (ISBN 0-596-00957 -7) , ecco i paragrafi 1-3 che spiegano i pacchetti MySQL:
Il codice di comunicazione di rete MySQL è stato scritto presupponendo che le query siano sempre ragionevolmente breve, e quindi può essere inviato ed elaborato dal server in un blocco, che nella terminologia MySQL è chiamato pacchetto . Il server alloca la memoria per un buffer temporaneo per memorizzare il pacchetto e richiede abbastanza per adattarlo completamente. Questa architettura richiede una precauzione per evitare che il server esaurisca la memoria — un limite alla dimensione del pacchetto, che questa opzione realizza.
Il codice di interesse in relazione a questa opzione si trova in sql / net_serv.cc . Dai unocchiata a my_net_read () , quindi segui la chiamata a my_real_read () e presta particolare attenzione a net_realloc () .
Questa variabile limita anche la lunghezza di un risultato di molte funzioni stringa. Vedi sql / field.cc e sql / intem_strfunc.cc per i dettagli.
La conoscenza di questo sui pacchetti MySQL consente a uno sviluppatore / amministratore di database di ridimensionarli per ospitare più BLOB allinterno di un pacchetto anche se sono odiosamente grandi. Sicuramente, un pacchetto troppo piccolo causerà problemi per le connessioni aperte a questo riguardo.
Secondo Documentazione MySQL
-
Puoi anche ottenere questi errori se invii una query al server che non è corretta grande. Se mysqld riceve un pacchetto troppo grande o fuori servizio, presume che qualcosa sia andato storto con il client e chiude la connessione. Se hai bisogno di query di grandi dimensioni (ad esempio, se lavori con colonne BLOB di grandi dimensioni), puoi aumentare il limite di query impostando la variabile max_allowed_packet del server, che ha un valore predefinito di 1 MB. Potrebbe anche essere necessario aumentare il massimo dimensione del pacchetto sul lato client. Ulteriori informazioni sullimpostazione della dimensione del pacchetto sono fornite nella Sezione C.5.2.10, “Pacchetto troppo grande”.
-
Anche unistruzione INSERT o REPLACE che inserisce un gran numero di righe può causare questo tipo di errori. Ciascuna di queste istruzioni invia una singola richiesta al server indipendentemente dal numero di righe da inserire ; quindi, puoi spesso evitare lerrore riducendo il numero di righe inviate per INSERT o REPLACE.
RACCOMANDAZIONE
Prova a generare max_allowed_packet a un numero molto maggiore, poiché il valore predefinito è 1 milione. Vorrei ld suggerire circa 10 volte il campo TEXT o BLOB più grande che hai nel tuo attuale set di dati.
Per impostare max_allowed_packet su 256M, puoi aggiungerlo a /etc/my.cnf o my.ini
[mysqld] max_allowed_packet=256M
per coprire i futuri riavvii di mysqld. Per installare il valore ora sul server, esegui questo:
SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;
Provalo !!!
Commenti
- Spiegazione molto buona.
- @RolandoMySQLDBA Ricevo ancora un errore nella versione 5.7.28 dopo aver provato tutte le soluzioni menzionate. Eventuali suggerimenti per risolvere ulteriormente i problemi
Risposta
Per impostazione predefinita, max_connections sarà 100. Prova ad aumentare il parametro di configurazione
max_connections = 400, dopo aver impostato in my.cnf, riavvia il server o impostalo dinamicamente:
set @@global.max_connections = 400;
Prova semplicemente il consiglio di cui sopra per evita questi messaggi di avviso e assicurati inoltre che la tua rete non abbia interruzioni di pacchetti.
Risposta
Ho riscontrato questo problema di recente dopo essere passato da MySQL Enterprise da 5.1.x a 5.7.x , senza modifiche significative al codice dellapplicazione, la “ nota ” ha iniziato ad apparire.
Nel mio caso la causa principale della “ nota ” che appariva era luscita del programma con le connessioni ancora aperte.La circostanza per cui le connessioni non venivano chiuse era un po più complicata e non correlata a MySQL ma a ACE, thread e TSS.
Answer
Non menzionato qui, quindi includo unaltra causa di questo problema. Nel mio caso, durante lutilizzo del client della riga di comando mysql, lerrore è stato causato da un valore basso di 30 secondi di interactive_timeout
:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Ciò persisterà tra le sessioni ma non il riavvio del server.
SET GLOBAL interactive_timeout=6000;
Risposta
Ho riscontrato lo stesso problema con MariaDB 10.3.24. Sembra che lAvvertimento possa verificarsi per tutti i motivi sopra e poi per alcuni. Nel mio caso era dovuto a un record in una delle tabelle del database che aveva un valore di dizionario vuoto per uno dei campi.
+ —- + ——– + | id | config | + —- + ——– + | 3 | {} | + —- + ——– +
Come test ho cambiato “{}” in “()” e questo ha fermato il messaggio. Nel caso in cui aiutasse qualcuno.
Rispondi
Questa riga my.ini ha risolto il mio problema:
log_error_verbosity=1
Fai riferimento a questo link
Commenti
- Non ' penso che tu abbia risolto il problema di fondo ma semplicemente ne abbia interrotto la registrazione.
- Ho ricevuto lo stesso messaggio riportato come " Nota ". Lutilizzo di log_error_verbosity = 2 risolve effettivamente il " problema " (ma un " avviso " dovrebbe essere indirizzato, non ignorato)