ERRORE 2006 (HY000): il server MySQL è andato via

Ottengo questo errore quando provo a creare un file SQL di grandi dimensioni (una INSERTquery di grandi dimensioni ).

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

Nulla nella tabella viene aggiornato. Ho provato a eliminare e deselezionare la tabella / database, nonché a riavviare MySQL. Nessuna di queste cose risolve il problema.

Ecco la mia dimensione massima del pacchetto:

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

Ecco la dimensione del file:

$ ls -s file.sql 
79512 file.sql

Quando provo l'altro metodo ...

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

max_allowed_packet=64M

L'aggiunta di questa riga nel my.cnffile risolve il mio problema.

Questo è utile quando le colonne hanno valori elevati, che causano i problemi, puoi trovare la spiegazione qui .

Su Windows questo file si trova in: "C: \ ProgramData \ MySQL \ MySQL Server 5.6"

Su Linux (Ubuntu): / etc / mysql

È possibile aumentare il pacchetto massimo consentito

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

L'aggiornamento globale e le impostazioni my.cnf non hanno funzionato per me per qualche motivo. Passando il max_allowed_packetvalore direttamente al client ha funzionato qui:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

In generale l'errore:

Errore: 2006 ( CR_SERVER_GONE_ERROR) - Il server MySQL è andato via

significa che il client non è stato in grado di inviare una domanda al server .

mysql importare

Nel tuo caso specifico durante l'importazione del file di database tramite mysql, ciò molto probabilmente significa che alcune delle query nel file SQL sono troppo grandi per essere importate e non possono essere eseguite sul server, quindi il client non riesce al primo errore.

Quindi hai le seguenti possibilità:

• Aggiungi force force option ( -f) per mysqlprocedere ed eseguire il resto delle query.

  Ciò è utile se il database ha alcune query di grandi dimensioni relative alla cache che non sono comunque rilevanti.

• Aumenta max_allowed_packetewait_timeout nella configurazione del tuo server (ad es ~/.my.cnf.).

• Scaricare il database utilizzando l' --skip-extended-insertopzione per suddividere le query di grandi dimensioni. Quindi importalo di nuovo.

• Prova ad applicare l' --max-allowed-packetopzione per mysql.

Ragioni comuni

In generale questo errore potrebbe significare diverse cose, come:

• una query sul server non è corretta o è troppo grande,

  Soluzione: aumentare la max_allowed_packetvariabile .

  • Assicurati che la variabile sia nella [mysqld]sezione, no [mysql].

  • Non abbiate paura di usare grandi numeri per i test (come 1G).

  • Non dimenticare di riavviare il server MySQL / MariaDB.

  • Ricontrolla il valore impostato correttamente:

    mysql -sve "SELECT @@max_allowed_packet" # or:
    mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"

• Hai ottenuto un timeout dalla connessione TCP / IP sul lato client.

  Soluzione: aumentare la wait_timeoutvariabile .

• Si è tentato di eseguire una query dopo aver chiuso la connessione al server.

  Soluzione: è necessario correggere un errore logico nell'applicazione.

• La ricerca del nome host non è riuscita (ad es. Problema del server DNS) o il server è stato avviato con l' --skip-networkingopzione.

  Un'altra possibilità è che il firewall blocchi la porta MySQL (ad esempio 3306 per impostazione predefinita).

• Il thread in esecuzione è stato eliminato, quindi riprovare.

• Si è verificato un errore in cui il server è morto durante l'esecuzione della query.

• Un client in esecuzione su un host diverso non dispone dei privilegi necessari per connettersi.

• E molti altri, quindi scopri di più su: B.5.2.9 Il server MySQL è andato via .

Debug

Ecco alcune idee di debug a livello di esperti:

• Controllare i registri, ad es

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")

• Metti alla prova la tua connessione tramite mysql, telneto le funzioni ping (ad esempio mysql_pingin PHP).

• Utilizzare tcpdumpper annusare la comunicazione MySQL (non funzionerà per la connessione socket), ad esempio:

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings

• Su Linux, usa strace. Su BSD / Mac utilizzare dtrace/ dtruss, ad es

  sudo dtruss -a -fn mysqld 2>&1

  Vedi: Introduzione a DTracing MySQL

Ulteriori informazioni su come eseguire il debug del server o client MySQL su: 26.5 Debug e porting di MySQL .

Per riferimento, controlla il codice sorgente nel sql-common/client.cfile responsabile per generare l' CR_SERVER_GONE_ERRORerrore per il comando client.

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

Per ogni evenienza, per controllare le variabili è possibile utilizzare

$> mysqladmin variables -u user -p 

Questo visualizzerà le variabili correnti, in questo caso max_allowed_packet, e come qualcuno ha detto in un'altra risposta puoi impostarlo temporaneamente con

mysql> SET GLOBAL max_allowed_packet=1072731894

Nel mio caso il file cnf non è stato preso in considerazione e non so perché, quindi il codice SET GLOBAL mi ha davvero aiutato.

Ho risolto l'errore ERROR 2006 (HY000) at line 97: MySQL server has gone awaye ho migrato con successo un file sql> 5 GB eseguendo questi due passaggi nell'ordine:

1. Creato /etc/my.cnf come altri hanno raccomandato, con i seguenti contenuti:

   [mysql]
   connect_timeout = 43200
   max_allowed_packet = 2048M
   net_buffer_length = 512M
   debug-info = TRUE

2. Aggiungendo i flag --force --wait --reconnectal comando (es mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect.).

Nota importante: è stato necessario eseguire entrambi i passaggi, perché se non mi sono preoccupato di apportare le modifiche al file /etc/my.cnf e di aggiungere quei flag, alcune delle tabelle mancavano dopo l'importazione.

Sistema utilizzato: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 per osx10.8 (i386)

Ho avuto lo stesso problema, ma la modifica di max_allowed_packet nel file my.ini / my.cnf in [mysqld] ha risolto il problema.

aggiungi una linea

max_allowed_packet=500M

ora riavvia il servizio MySQL al termine.

È inoltre possibile accedere al database come root (o privilegio SUPER) e farlo

set global max_allowed_packet=64*1024*1024;

non richiede anche un riavvio di MySQL. Si noti che è necessario correggere il my.cnffile come indicato in altre soluzioni:

[mysqld]
max_allowed_packet=64M

E conferma la modifica dopo aver riavviato MySQL:

show variables like 'max_allowed_packet';

È possibile utilizzare anche la riga di comando, ma ciò potrebbe richiedere l'aggiornamento degli script di avvio / arresto che potrebbero non sopravvivere agli aggiornamenti e alle patch di sistema.

Come richiesto, sto aggiungendo la mia risposta qui. Sono contento di vedere che funziona!

La soluzione sta aumentando i valori dati wait_timeoute i connect_timeoutparametri nel file delle opzioni, sotto il[mysqld] tag.

Ho dovuto recuperare un backup mysql da 400 MB e questo ha funzionato per me (i valori che ho usato di seguito sono un po 'esagerati, ma ottieni il punto):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

blockquote

Qui potrebbero accadere un paio di cose;

• Il vostro INSERTè in esecuzione lunga, e il client è disconnessione. Quando si riconnette non sta selezionando un database, quindi l'errore. Un'opzione qui è eseguire il file batch dalla riga di comando e selezionare il database negli argomenti, in questo modo;

$ mysql nome_db <source.sql

• Un altro è eseguire il comando tramite phpo in un'altra lingua. Dopo ogni istruzione a esecuzione prolungata, puoi chiudere e riaprire la connessione, assicurandoti di essere connesso all'inizio di ogni query.

Se sei su Mac e hai installato mysql tramite brew come me, il seguente ha funzionato.

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

Fonte: per installazioni mysql homebrew, dov'è my.cnf?

2. aggiungere max_allowed_packet=1073741824a/usr/local/etc/my.cnf

3. mysql.server restart

Ho riscontrato questo errore quando utilizzo Mysql Cluster, non so se questa domanda provenga o meno dall'uso di un cluster. Poiché l'errore è esattamente lo stesso, quindi dai la mia soluzione qui. Ottenere questo errore perché i nodi di dati si bloccano improvvisamente. Ma quando i nodi si arrestano in modo anomalo, puoi comunque ottenere il risultato corretto usando cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

E anche mysqld funziona correttamente, quindi all'inizio non riesco a capire cosa c'è che non va. E circa 5 minuti dopo, il risultato ndb_mgm non mostra alcun nodo dati funzionante. Quindi mi rendo conto del problema. Quindi, prova a riavviare tutti i nodi di dati, quindi il server mysql è tornato e tutto è OK.

Ma una cosa è strana per me, dopo aver perso il server mysql per alcune query, quando uso cmd like show tables, riesco ancora a ottenere le informazioni di ritorno come 33 rows in set (5.57 sec), ma non vengono visualizzate le informazioni sulla tabella.

Per amazon RDS (è il mio caso), è possibile modificare il max_allowed_packetvalore del parametro in qualsiasi valore numerico in byte che abbia senso per i dati più grandi in qualsiasi inserto che si può avere (ad esempio: se si hanno alcuni valori BLOB di 50 MB nell'inserto, impostare il max_allowed_packeta 64 M = 67108864), in una nuova o esistente parameter-group. Quindi applicare quel gruppo di parametri all'istanza di MySQL (potrebbe essere necessario riavviare l'istanza).

Se si sta riconnettendo e sta ottenendo l'ID di connessione 2, il server si è quasi sicuramente bloccato.

Contattare l'amministratore del server e chiedere loro di diagnosticare il problema. Nessun SQL non dannoso dovrebbe arrestare in modo anomalo il server e l'output di mysqldump non dovrebbe farlo.

È probabile che l'amministratore del server abbia commesso un grosso errore operativo come l'assegnazione di dimensioni del buffer superiori ai limiti dello spazio di indirizzi dell'architettura o superiori alla capacità della memoria virtuale. Il log degli errori di MySQL avrà probabilmente alcune informazioni rilevanti; controlleranno questo se sono comunque competenti.

Questo è un problema più raro ma l'ho visto se qualcuno ha copiato l'intera directory / var / lib / mysql come un modo per migrare il proprio DB su un altro server. Il motivo per cui non funziona è perché il database era in esecuzione e utilizzava i file di registro. A volte non funziona se ci sono registri in / var / log / mysql. La soluzione è di copiare anche i file / var / log / mysql.

Per gli utenti di Drupal 8 che cercano una soluzione per l'errore di importazione del DB:

Alla fine del file di dump sql è possibile inserire comandi nella tabella "webprofiler". Questo è immagino che alcuni file di registro di debug e non siano davvero importanti per il funzionamento del sito, quindi tutto ciò può essere rimosso. Ho eliminato tutti quegli inserti inclusi LOCK TABLES e UNLOCK TABLES (e tutto il resto). È in fondo al file sql. Il problema è descritto qui:

https://www.drupal.org/project/devel/issues/2723437

Ma non c'è soluzione al di fuori di troncare quella tabella.

A proposito ho provato tutte le soluzioni dalle risposte sopra e nient'altro ha aiutato.

Ho provato tutte le soluzioni sopra, tutte fallite.

Ho finito con l'utilizzo -h 127.0.0.1invece di utilizzare l'impostazione predefinita var/run/mysqld/mysqld.sock.

Questo messaggio di errore si verifica anche quando si crea SCHEMA con un COLLATION diverso da quello utilizzato nel dump. Quindi, se la discarica contiene

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

dovresti anche riflettere questo nel confronto SCHEMA:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

Stavo usando utf8mb4_general_ci nello schema, perché il mio script proveniva da una nuova installazione di V8, ora caricando un DB sul vecchio 5.7 si è bloccato e mi ha fatto quasi impazzire.

Quindi, forse questo ti aiuta a risparmiare alcune ore frustating ... :-)

(MacOS 10.3, mysql 5.7)

se nessuna di queste risposte risolve il problema, l'ho risolto rimuovendo le tabelle e creandole di nuovo automaticamente in questo modo:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

quindi usa questo backup con il tuo db e rimuoverà e ricrea le tabelle di cui hai bisogno.

Quindi esegui il backup dei soli dati e fai lo stesso e funzionerà.

Che ne dici di usare il client mysql in questo modo:

mysql -h <hostname> -u username -p <databasename> < file.sql