Codice errore: 2013. Connessione persa al server MySQL durante la query

Ho ricevuto il codice di errore: 2013. Ho perso la connessione al server MySQL durante un errore di query quando ho provato ad aggiungere un indice a una tabella usando MySQL Workbench. Ho notato anche che appare ogni volta che eseguo query lunghe.

C'è via per aumentare il valore di timeout?

Le nuove versioni di MySQL WorkBench hanno un'opzione per modificare specifici timeout.

Per me era in Modifica → Preferenze → Editor SQL → Timeout lettura connessione DBMS (in secondi): 600

Modificato il valore in 6000.

Anche le righe dei limiti deselezionate come mettere un limite ogni volta che voglio cercare l'intero set di dati diventa noioso.

Avviare il server DB con l'opzione line di comando net_read_timeout/ wait_timeoute un valore adeguato (in secondi) - ad esempio: --net_read_timeout=100.

Per riferimento vedi qui e qui .

Se la query contiene dati BLOB, questo problema può essere risolto applicando una my.inimodifica come proposto in questa risposta :

[mysqld]
max_allowed_packet=16M

Per impostazione predefinita, sarà 1M (il valore massimo consentito è 1024M). Se il valore fornito non è un multiplo di 1024K, verrà automaticamente arrotondato al multiplo più vicino di 1024K.

Mentre il thread di riferimento riguarda l'errore MySQL 2006 , l'impostazione max_allowed_packetda 1M a 16M ha risolto l'errore 2013 che si presentava per me quando eseguivo una query lunga.

Per gli utenti WAMP: troverai la bandiera nella [wampmysqld]sezione.

Aggiungi quanto segue nel file / etc / mysql / cnf:

innodb_buffer_pool_size = 64M

esempio:

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M

SET @@local.net_read_timeout=360;

Avviso: Quanto segue non funzionerà quando lo si applica in una connessione remota:

SET @@global.net_read_timeout=360;

Esistono tre cause probabili per questo messaggio di errore

1. Di solito indica problemi di connettività di rete e si dovrebbe verificare le condizioni della propria rete se questo errore si verifica frequentemente
2. A volte il modulo "durante la query" si verifica quando vengono inviate milioni di righe come parte di una o più query.
3. Più raramente, può accadere quando il client sta tentando la connessione iniziale al server

Per maggiori dettagli leggi >>

Causa 2:

SET GLOBAL interactive_timeout=60;

dal valore predefinito di 30 secondi a 60 secondi o più

Causa 3:

SET GLOBAL connect_timeout=60;

Grazie! Ha funzionato. Ma con gli aggiornamenti mysqldb la configurazione è diventata:

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

È necessario impostare le proprietà 'interactive_timeout' e 'wait_timeout' nel file di configurazione mysql sui valori necessari.

Basta eseguire un aggiornamento di MySQL che si ri-build motore InnoDB con la ricostruzione di molte tabelle necessarie per il corretto funzionamento di MySQL come ad esempio performance_schema, information_schemae così via

Immettere il comando seguente dalla shell:

sudo mysql_upgrade -u root -p

So che è vecchio ma su Mac

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.

Cambia il tempo di "timeout di lettura" in Modifica-> Preferenze-> editor SQL-> sessione MySQL

Prova a deselezionare il limite delle righe in Modifica → Preferenze → Query SQL

perché è necessario impostare le proprietà 'interactive_timeout' e 'wait_timeout' nel file di configurazione mysql sui valori necessari.

Se si verifica questo problema durante il ripristino di un file di dump di grandi dimensioni e si può escludere che abbia qualcosa a che fare con la rete (ad es. Esecuzione su localhost) di quanto la mia soluzione possa essere utile.

Il mio mysqldump conteneva almeno un INSERT che era troppo grande per essere calcolato da mysql. Puoi visualizzare questa variabile digitando show variables like "net_buffer_length";dentro mysql-cli. Hai tre possibilità:

• aumentare net_buffer_length all'interno di mysql -> ciò richiederebbe un riavvio del server
• crea dump con --skip-extended-insert, per ogni inserto viene utilizzata una riga -> anche se questi dump sono molto più belli da leggere, questo non è adatto a grandi dump> 1 GB perché tende ad essere molto lento
• creare un dump con inserti estesi (che è l'impostazione predefinita) ma limitare net-buffer_length, ad esempio con --net-buffer_length NR_OF_BYTESdove NR_OF_BYTES è più piccolo di net_buffer_length del server -> Penso che questa sia la soluzione migliore, anche se non è necessario un riavvio più lento.

Ho usato il seguente comando mysqldump: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile

Ho avuto lo stesso problema durante il caricamento di un file .csv. Convertito il file in .sql.

Utilizzando il comando seguente riesco a aggirare questo problema.

mysql -u <user> -p -D <DB name> < file.sql

Spero che questo possa aiutare.

Se tutte le altre soluzioni qui falliscono, controlla il tuo syslog (/ var / log / syslog o simile) per vedere se il tuo server sta esaurendo la memoria durante la query.

Aveva questo problema quando innodb_buffer_pool_size era impostato troppo vicino alla memoria fisica senza un file di swap configurato. MySQL consiglia di impostare un server specifico per il database innodb_buffer_pool_size a un massimo di circa l'80% della memoria fisica , l'ho impostato su circa il 90%, il kernel stava uccidendo il processo mysql. Spostato innodb_buffer_pool_size di nuovo all'80% e questo ha risolto il problema.

Nel mio caso, l'impostazione dell'intervallo di timeout della connessione su 6000 o qualcosa di superiore non ha funzionato.

Ho appena fatto ciò che il banco di lavoro dice che posso fare.

Il tempo massimo che la query può impiegare per restituire i dati dal DBMS.Set 0 per saltare il timeout di lettura.

Su Preferenze Mac -> SQL Editor -> Vai a MySQL Session -> imposta l'intervallo di timeout di lettura della connessione su 0.

E funziona 😄

Ho affrontato lo stesso problema. Credo che accada quando si hanno chiavi esterne per tavoli più grandi (che richiede tempo).

Ho provato a eseguire nuovamente l'istruzione create table senza le dichiarazioni di chiave esterna e ho trovato che funzionava.

Quindi, dopo aver creato la tabella, ho aggiunto i vincoli di chiave esterna utilizzando la query ALTER TABLE.

Spero che questo possa aiutare qualcuno.

Questo mi è successo perché il mio innodb_buffer_pool_size era impostato per essere più grande della dimensione della RAM disponibile sul server. Le cose si stavano interrompendo a causa di ciò e questo errore. La correzione è aggiornare my.cnf con l'impostazione corretta per innodb_buffer_pool_size.

Vai a Workbench Modifica → Preferenze → Editor SQL → Timeout lettura connessioni DBMS: fino a 3000. L'errore non si è più verificato.

Vai a:

Modifica -> Preferenze -> Editor SQL

Qui puoi vedere tre campi nel gruppo "MySQL Session", dove ora puoi impostare i nuovi intervalli di connessione (in secondi).

Si scopre che la nostra regola del firewall stava bloccando la mia connessione a MYSQL. Dopo che la politica del firewall è stata sollevata per consentire la connessione, sono stato in grado di importare lo schema correttamente.

Ho avuto lo stesso problema, ma per me la soluzione era un utente DB con autorizzazioni troppo rigide. Ho dovuto consentire l' Executeabilità sul mysqltavolo. Dopo averlo permesso, non ho più lasciato cadere le connessioni

Controlla se gli indici sono al loro posto per primi.

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'

Mi sono imbattuto in questo mentre eseguivo un proc memorizzato che stava creando molte righe in una tabella nel database. Ho potuto vedere l'errore venire subito dopo che il tempo ha superato il limite di 30 secondi.

Ho provato tutti i suggerimenti nelle altre risposte. Sono sicuro che alcuni di questi mi hanno aiutato, tuttavia, ciò che mi ha fatto davvero funzionare è stato passare a SequelPro da Workbench.

Immagino che fosse una connessione lato client che non riuscivo a individuare in Workbench. Forse questo aiuterà anche qualcun altro?

Se si utilizza SQL Work Bench, è possibile provare a utilizzare l'indicizzazione, aggiungendo un indice alle tabelle, per aggiungere un indice, fare clic sul simbolo chiave inglese (chiave inglese) sulla tabella, si dovrebbe aprire l'impostazione per la tabella, di seguito , fai clic sulla vista indice, digita un nome indice e imposta il tipo su indice, nelle colonne indice, seleziona la colonna principale nella tabella.

Fare lo stesso passo per altre chiavi primarie su altre tabelle.

Sembra che manchi una risposta per coloro che usano SSH per connettersi al loro database MySQL. Devi controllare due posti diversi da 1 come suggerito da altre risposte:

Workbench Modifica → Preferenze → Editor SQL → DBMS

Workbench Modifica → Preferenze → SSH → Timeout

I miei timeout SSH predefiniti erano impostati su un valore molto basso e causavano alcuni (ma apparentemente non tutti) i miei problemi di timeout. Dopo, non dimenticare di riavviare MySQL Workbench!

Infine, potrebbe essere utile contattare l'amministratore DB e chiedere loro di aumentare le proprietà wait_timeout e interactive_timeout in mysql stesso tramite my.conf + mysql restart o eseguendo un set globale se il riavvio di mysql non è un'opzione.

Spero che questo ti aiuti!

Tre cose da seguire e assicurarsi:

1. Se più query mostrano una connessione persa?
2. come usi set query in MySQL?
3. come eliminare + aggiornare la query contemporaneamente?

risposte:

1. Cerca sempre di rimuovere il definitore mentre MySQL crea il proprio definitore e se più tabelle coinvolte per l'aggiornamento tentano di creare una singola query poiché a volte più query mostrano una connessione persa
2. Imposta sempre il valore SET in alto ma dopo CANC se la sua condizione non coinvolge il valore SET.
3. Utilizzare ELIMINA PRIMA DI AGGIORNARE SE ENTRAMBE QUESTE OPERAZIONI SONO EFFETTUATE SU TAVOLI DIVERSI

controllare

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

Spero che questo ti aiuti

Questo di solito significa che hai "incompatibilità con la versione corrente di MySQL Server", vedi mysql_upgrade. Ho riscontrato questo stesso problema e ho dovuto semplicemente eseguire:

mysql_upgrade --password La documentazione afferma che "mysql_upgrade dovrebbe essere eseguito ogni volta che si aggiorna MySQL".