ERRO 2006 (HY000): Servidor MySQL desapareceu

Eu recebo esse erro ao tentar obter um arquivo SQL grande (uma grande INSERTconsulta).

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 ***

Nada na tabela é atualizado. Eu tentei excluir e cancelar a exclusão da tabela / banco de dados, bem como reiniciar o MySQL. Nenhuma dessas coisas resolve o problema.

Aqui está o tamanho máximo do meu pacote:

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

Aqui está o tamanho do arquivo:

$ ls -s file.sql 
79512 file.sql

Quando tento o outro método ...

$ ./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

Adicionar esta linha ao my.cnfarquivo resolve meu problema.

Isso é útil quando as colunas têm valores grandes, que causam os problemas, você pode encontrar a explicação aqui .

No Windows, esse arquivo está localizado em: "C: \ ProgramData \ MySQL \ MySQL Server 5.6"

No Linux (Ubuntu): / etc / mysql

Você pode aumentar o pacote máximo permitido

SET GLOBAL max_allowed_packet=1073741824;

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

A atualização global e as configurações do my.cnf não funcionaram para mim por algum motivo. Passando o max_allowed_packetvalor diretamente para o cliente trabalhou aqui:

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

Em geral, o erro:

Erro: 2006 ( CR_SERVER_GONE_ERROR) - servidor MySQL foi embora

significa que o cliente não pôde enviar uma pergunta ao servidor .

mysql importar

No seu caso específico, ao importar o arquivo do banco de dados via mysql , isso provavelmente significa que algumas das consultas no arquivo SQL são muito grandes para serem importadas e não puderam ser executadas no servidor; portanto, o cliente falha no primeiro erro ocorrido.

Então você tem as seguintes possibilidades:

• Adicione a opção force ( -f) para mysqlprosseguir e executar o restante das consultas.

  Isso é útil se o banco de dados tiver algumas consultas grandes relacionadas ao cache que não são relevantes de qualquer maneira.

• Aumente max_allowed_packetewait_timeout na configuração do seu servidor (por exemplo ~/.my.cnf).

• Despejar o banco de dados usando a --skip-extended-insertopção para dividir as consultas grandes. Em seguida, importe-o novamente.

• Tente aplicar a --max-allowed-packetopção para mysql.

Razões comuns

Em geral, esse erro pode significar várias coisas, como:

• uma consulta ao servidor está incorreta ou muito grande,

  Solução: Aumente a max_allowed_packetvariável .

  • Verifique se a variável está na [mysqld]seção, não [mysql].

  • Não tenha medo de usar grandes números para testes (como 1G).

  • Não esqueça de reiniciar o servidor MySQL / MariaDB.

  • Verifique novamente se o valor foi definido corretamente por:

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

• Você recebeu um tempo limite da conexão TCP / IP no lado do cliente.

  Solução: Aumente a wait_timeoutvariável .

• Você tentou executar uma consulta após o fechamento da conexão com o servidor.

  Solução: Um erro lógico no aplicativo deve ser corrigido.

• Falha na pesquisa do nome do host (por exemplo, problema no servidor DNS) ou o servidor foi iniciado com a --skip-networkingopção

  Outra possibilidade é que seu firewall bloqueie a porta MySQL (por exemplo, 3306 por padrão).

• O encadeamento em execução foi interrompido, portanto, tente novamente.

• Você encontrou um erro em que o servidor morreu durante a execução da consulta.

• Um cliente executando em um host diferente não possui os privilégios necessários para se conectar.

• E muito mais, então aprenda mais em: B.5.2.9 O servidor MySQL foi embora .

Depuração

Aqui estão algumas idéias de depuração no nível de especialista:

• Verifique os logs, por exemplo

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

• Teste sua conexão via mysql, telnetou funções de ping (por exemplo, mysql_pingem PHP).

• Use tcpdumppara farejar a comunicação MySQL (não funcionará para conexão de soquete), por exemplo:

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

• No Linux, use strace. No BSD / Mac, use dtrace/ dtruss, por exemplo

  sudo dtruss -a -fn mysqld 2>&1

  Consulte: Introdução ao DTracing MySQL

Aprenda mais sobre como depurar o servidor ou cliente MySQL em: 26.5 Depurando e portando o MySQL .

Para referência, verifique o código-fonte no sql-common/client.carquivo responsável por gerar o CR_SERVER_GONE_ERRORerro para o comando do cliente.

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;
}

Apenas no caso, para verificar variáveis, você pode usar

$> mysqladmin variables -u user -p 

Isso exibirá as variáveis ​​atuais, neste caso max_allowed_packet, e como alguém disse em outra resposta, você pode configurá-lo temporariamente com

mysql> SET GLOBAL max_allowed_packet=1072731894

No meu caso, o arquivo cnf não foi levado em consideração e não sei por que, então o código SET GLOBAL realmente ajudou.

Resolvi o erro ERROR 2006 (HY000) at line 97: MySQL server has gone awaye migrei com êxito um arquivo sql> 5GB executando estas duas etapas em ordem:

1. Criou o /etc/my.cnf conforme recomendado por outras pessoas, com o seguinte conteúdo:

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

2. Anexando os sinalizadores --force --wait --reconnectao comando (ou seja mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Nota importante: Era necessário executar as duas etapas, porque se eu não me incomodasse em fazer as alterações no arquivo /etc/my.cnf e em anexar esses sinalizadores, algumas tabelas estavam faltando após a importação.

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

Eu tive o mesmo problema, mas alterar o max_allowed_packet no arquivo my.ini / my.cnf no [mysqld] fez o truque.

adicione uma linha

max_allowed_packet=500M

Agora reinicie o serviço MySQL quando terminar.

Você também pode efetuar login no banco de dados como root (ou privilégio SUPER) e fazer

set global max_allowed_packet=64*1024*1024;

não requer uma reinicialização do MySQL também. Observe que você deve corrigir seu my.cnfarquivo conforme descrito em outras soluções:

[mysqld]
max_allowed_packet=64M

E confirme a alteração depois de reiniciar o MySQL:

show variables like 'max_allowed_packet';

Você também pode usar a linha de comando, mas isso pode exigir a atualização dos scripts de início / parada, que podem não sobreviver às atualizações e patches do sistema.

Conforme solicitado, estou adicionando minha própria resposta aqui. Fico feliz em ver que funciona!

A solução está aumentando os valores fornecidos wait_timeoutos connect_timeoutparâmetros e em seu arquivo de opções, sob a [mysqld]tag

Eu tive que recuperar um backup mysql de 400 MB e isso funcionou para mim (os valores que usei abaixo são um pouco exagerados, mas você entendeu):

[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

Bloco de citação

Algumas coisas podem estar acontecendo aqui;

• Você INSERTestá demorando muito e o cliente está desconectando. Quando ele se reconecta, não está selecionando um banco de dados, daí o erro. Uma opção aqui é executar o arquivo em lotes na linha de comando e selecionar o banco de dados nos argumentos, assim;

$ mysql db_name <source.sql

• Outra é executar seu comando via phpou em algum outro idioma. Após cada instrução de execução demorada, você pode fechar e reabrir a conexão, garantindo que esteja conectado no início de cada consulta.

Se você está no Mac e instalou o mysql através do brew como eu, o seguinte funcionou.

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

Fonte: Para instalações do homebrew mysql, onde está o my.cnf?

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

3. mysql.server restart

Encontrei este erro ao usar o Mysql Cluster, não sei se essa pergunta é de uso de cluster ou não. Como o erro é exatamente o mesmo, então dê minha solução aqui. Obtendo esse erro porque os nós de dados falham repentinamente. Mas quando os nós falham, você ainda pode obter o resultado correto usando o cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

E o mysqld também funciona corretamente. Então, a princípio, não consigo entender o que está errado. E cerca de 5 minutos depois, o resultado ndb_mgm não mostra o nó de dados funcionando. Então eu percebo o problema. Então, tente reiniciar todos os nós de dados, o servidor mysql está de volta e tudo está OK.

Mas uma coisa é estranha para mim, depois que perdi o servidor mysql para algumas consultas, quando eu uso o cmd show tables, ainda posso obter as informações de retorno 33 rows in set (5.57 sec), mas nenhuma informação da tabela é exibida.

Para o Amazon RDS (é o meu caso), você pode alterar o max_allowed_packetvalor do parâmetro para qualquer valor numérico em bytes que faça sentido para os maiores dados em qualquer inserção que você possa ter (por exemplo: se você tiver alguns valores de blob de 50mb na inserção, defina max_allowed_packetpara 64M = 67108864), em um novo ou existente parameter-group. Em seguida, aplique esse grupo de parâmetros à sua instância do MySQL (pode ser necessário reiniciar a instância).

Se estiver reconectando e obtendo o ID de conexão 2, o servidor quase definitivamente travou.

Entre em contato com o administrador do servidor e peça-o para diagnosticar o problema. Nenhum SQL não malicioso deve travar o servidor, e a saída do mysqldump certamente não deve.

Provavelmente, o administrador do servidor cometeu um grande erro operacional, como atribuir tamanhos de buffer maiores que os limites do espaço de endereço da arquitetura ou mais que a capacidade da memória virtual. O log de erros do MySQL provavelmente terá algumas informações relevantes; eles estarão monitorando isso se forem competentes de qualquer maneira.

Esse é um problema mais raro, mas vi isso se alguém tiver copiado todo o diretório / var / lib / mysql como uma maneira de migrar seu banco de dados para outro servidor. O motivo pelo qual não funciona é porque o banco de dados estava em execução e usando arquivos de log. Às vezes, não funciona se houver logs em / var / log / mysql. A solução é copiar os arquivos / var / log / mysql também.

Para usuários do Drupal 8 que procuram solução para falha na importação de banco de dados:

No final do arquivo sql dump, pode haver comandos para inserir dados na tabela "webprofiler". Acho que é um arquivo de log de depuração e não é realmente importante para o site funcionar, então tudo isso pode ser removido. Excluí todas essas inserções, incluindo LOCK TABLES e UNLOCK TABLES (e tudo mais). Está na parte inferior do arquivo sql. O problema é descrito aqui:

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

Mas não há solução para isso além de truncar essa tabela.

BTW eu tentei todas as soluções das respostas acima e nada mais ajudou.

Eu tentei todas as soluções acima, todas falharam.

Acabei usando em -h 127.0.0.1vez de usar o padrão var/run/mysqld/mysqld.sock.

Essa mensagem de erro também ocorre quando você criou o esquema com um COLLATION diferente daquele usado no despejo. Então, se o despejo contiver

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

você também deve refletir isso no agrupamento SCHEMA:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

Eu estava usando utf8mb4_general_ci no esquema, porque meu script veio de uma nova instalação do V8, agora carregar um banco de dados no antigo 5.7 travava e me deixava quase louco.

Então, talvez isso ajude você a economizar algumas horas frustrantes ... :-)

(MacOS 10.3, mysql 5.7)

se nenhuma dessas respostas resolver o problema, resolvi-o removendo as tabelas e criando-as novamente automaticamente desta maneira:

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

basta usar esse backup com seu banco de dados e ele removerá e recriará as tabelas necessárias.

Então você faz backup apenas dos dados e faz o mesmo, e ele funcionará.

Que tal usar o cliente mysql assim:

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