Código de erro: 2013. Conexão perdida com o servidor MySQL durante a consulta


250

Eu recebi o código de erro: 2013. Perdi a conexão com o servidor MySQL durante um erro de consulta quando tentei adicionar um índice a uma tabela usando o MySQL Workbench. Notei também que ele aparece sempre que executo uma consulta longa.

Existe alguma distância para aumentar o valor do tempo limite?

Respostas:


471

Novas versões do MySQL WorkBench têm uma opção para alterar tempos limite específicos.

Para mim, estava em Editar → Preferências → Editor SQL → Tempo limite de leitura da conexão DBMS (em segundos): 600

O valor foi alterado para 6000.

Também linhas de limite desmarcadas, pois colocar um limite toda vez que eu quero pesquisar em todo o conjunto de dados fica cansativo.


2
É possível aumentar esse limite em 99.999 segundos? O DBMS connection read time outcampo aceita apenas 5 figuras e a configuração do campo como 0 é equivalente ao parâmetro padrão (600 segundos). (Windows 7 Ultimate de 64 bits, MySQL Workbench 5.2.47 CE)
Franck Dernoncourt


4
desmarque limite de linhas em Editar → Preferências → Consultas SQL
Jon

7
Depois de reiniciar, ele mostra o Erro 2013 novamente, mesmo com o tempo limite de leitura definido como 6000, portanto, isso não parece ser uma solução.
Davicus 23/05

4
Lembre-se de reiniciar o Workbench AND e fechar todas as janelas de consulta abertas primeiro!
pimbrouwers

32

Inicie o servidor de banco de dados com a opção comandline net_read_timeout/ wait_timeoute um valor adequado (em segundos) - por exemplo: --net_read_timeout=100.

Para referência, veja aqui e aqui .


1
Isso é correto, mas a resposta com maior número de ups me ajudou realmente
Sambit Tripathy

6
Como forneço esse parâmetro na linha de comando? Quando estou tentando conectar ao DB: mysql -u root -p --net_read_timeout = 60 ou quando estou tentando iniciar o serviço? serviço sudo mysql start? Em ambos os lugares ele está dando erro: desconhecido variável 'net_read_timeout'
Vikas Goel

@VikasGoel É um parâmetro do lado do servidor. Ou seja mysqld.
Chloe

29

Se sua consulta tiver dados de blob, esse problema poderá ser corrigido aplicando uma my.inialteração conforme proposto nesta resposta :

[mysqld]
max_allowed_packet=16M

Por padrão, será 1 milhão (o valor máximo permitido é 1024 milhões). Se o valor fornecido não for múltiplo de 1024K, ele será arredondado automaticamente para o múltiplo mais próximo de 1024K.

Enquanto o segmento de referência é sobre o erro MySQL 2006 , definindo o max_allowed_packetde 1M a 16M fez corrigir o erro 2013, que apareceu para mim quando executar uma consulta longa.

Para usuários WAMP: você encontrará a bandeira na [wampmysqld]seção.


Este foi exatamente o meu problema. Eu estava importando um backup do banco de dados de um arquivo e o MySQL Workbench estava relatando esse erro de 2013, seguido de "Falha na operação com o código de saída 1". Acontece que o backup tinha grandes colunas de blob excedendo o tamanho padrão max_allowed_packet de 4M do MySQL. Aumentar isso corrigiu. (MySQL 5.6 e Workbench 6.2.3). Obrigado!
ZAlbee 27/10/2014

Esta foi a solução para mim também. Embora eu defina 256M para uma máquina Windows.
smoore4

Tinha 16M, obtinha esse erro com um arquivo de importação várias vezes, mudou para 32M e depois funcionou.
hakre

15

Adicione o seguinte no arquivo / etc / mysql / cnf:

innodb_buffer_pool_size = 64M

exemplo:

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

6
Tem certeza de que o nome do arquivo /etc/mysql/cnfestá correto? Não deveria ser /etc/my.cnf?
Peter VARGA

12
SET @@local.net_read_timeout=360;

Aviso: O seguinte não funcionará quando você o estiver aplicando em conexão remota:

SET @@global.net_read_timeout=360;

O que é 360? Milissegundos, segundos, minutos?
MasterJoe2

10

Existem três causas prováveis ​​para esta mensagem de erro

  1. Geralmente indica problemas de conectividade de rede e você deve verificar as condições da sua rede se esse erro ocorrer com freqüência
  2. Às vezes, o formulário "durante a consulta" acontece quando milhões de linhas são enviadas como parte de uma ou mais consultas.
  3. Mais raramente, isso pode acontecer quando o cliente está tentando a conexão inicial com o servidor

Para mais detalhes, leia >>

Causa 2:

SET GLOBAL interactive_timeout=60;

do padrão de 30 segundos a 60 segundos ou mais

Causa 3:

SET GLOBAL connect_timeout=60;

2 me fornece este erro - Código: 1227. Acesso negado; Você precisa (pelo menos um dos) o privilégio SUPER (s) para esta operação
MasterJoe2

9

Obrigado! Mas com as atualizações do mysqldb, o configure se tornou:

max_allowed_packet

net_write_timeout

net_read_timeout

documento mysql


8

Você deve definir as propriedades 'interactive_timeout' e 'wait_timeout' no arquivo de configuração do mysql com os valores necessários.


Isso me ajuda. 'interactive_timeout' no my.cnf foi definido como 100, é muito curto. depois eu mudei para 3600 s (ou qualquer valor grande o suficiente para você), problema resolved.Thx
CobraBJ

7

Basta executar uma atualização do MySQL que reconstruirá o mecanismo innoDB juntamente com a reconstrução de muitas tabelas necessárias para o funcionamento adequado do MySQL, como performance_schema, por exemplo ,information_schema , etc.

Emita o comando abaixo em seu shell:

sudo mysql_upgrade -u root -p

O erro não se apresentou até o MySQL Workbench 6.1.4 (e apenas depois de um tempo) e também acontece no 6.1.6 (embora apenas após alguns usos), então não tenho certeza de como reconstruir vários servidores é uma correção para um problema que apenas se apresentou em uma GUI recentemente.
Davicus 23/05

Isso corrigiu meu problema. Eu tinha acabado de usar o Ansible para configurar o banco de dados sobre um já existente, e as coisas deram errado. A execução deste comando restaurou tudo para o estado de funcionamento.
Jubz

4

Eu sei que é velho, mas no mac

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

4

Altere o tempo de "tempo limite de leitura" em Editar-> Preferências-> Editor SQL-> Sessão MySQL


3

Tente desmarcar o limite de linhas em Editar → Preferências → Consultas SQL

porque Você deve definir as propriedades 'interactive_timeout' e 'wait_timeout' no arquivo de configuração do mysql com os valores necessários.


3

Se você enfrentar esse problema durante a restauração de um grande arquivo de despejo e puder descartar o problema de que ele tem alguma coisa a ver com a rede (por exemplo, execução no localhost), minha solução pode ser útil.

Meu mysqldump continha pelo menos um INSERT que era grande demais para o mysql calcular. Você pode visualizar esta variável digitando show variables like "net_buffer_length";dentro do seu mysql-cli. Você tem três possibilidades:

  • aumentar net_buffer_length dentro do mysql -> isso precisaria reiniciar o servidor
  • criar despejo com --skip-extended-insert, por inserção, uma linha é usada -> embora esses despejos sejam muito mais agradáveis ​​de ler, isso não é adequado para despejos grandes> 1 GB, porque tende a ser muito lento
  • crie dump com inserções estendidas (que é o padrão), mas limite o net-buffer_length, por exemplo, --net-buffer_length NR_OF_BYTESonde NR_OF_BYTES é menor que o net_buffer_length do servidor -> Eu acho que essa é a melhor solução, embora não seja necessário reiniciar o servidor mais lentamente.

Eu usei o seguinte comando mysqldump: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile


2

Eu tive o mesmo problema ao carregar um arquivo .csv. Convertido o arquivo para .sql.

Usando o comando abaixo, eu consigo solucionar esse problema.

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

Espero que isso ajude.


2

Se todas as outras soluções aqui falharem - verifique seu syslog (/ var / log / syslog ou similar) para ver se o servidor está ficando sem memória durante a consulta.

Teve esse problema quando innodb_buffer_pool_size foi definido muito próximo da memória física sem um arquivo de troca configurado. O MySQL recomenda para um servidor específico do banco de dados definir innodb_buffer_pool_size no máximo em torno de 80% da memória física , eu o defini em cerca de 90%, o kernel estava acabando com o processo mysql. Movemos innodb_buffer_pool_size de volta para cerca de 80% e isso corrigiu o problema.


2

No meu caso, definir o intervalo de tempo limite da conexão para 6000 ou algo mais alto não funcionou.

Acabei de fazer o que a bancada diz que posso fazer.

O tempo máximo que a consulta pode levar para retornar dados do DBMS.Set 0 para ignorar o tempo limite de leitura.

Nas Preferências do Mac -> Editor SQL -> Vá para Sessão MySQL -> defina o intervalo de tempo limite de leitura da conexão como 0.

E funciona 😄


1

Eu enfrentei esse mesmo problema. Eu acredito que isso acontece quando você tem chaves estrangeiras para tabelas maiores (o que leva tempo).

Tentei executar a instrução create table novamente sem as declarações de chave estrangeira e achei que funcionava.

Depois de criar a tabela, adicionei as restrições de chave estrangeira usando a consulta ALTER TABLE.

Espero que isso ajude alguém.


1

Isso aconteceu comigo porque meu innodb_buffer_pool_size foi definido como maior que o tamanho da RAM disponível no servidor. As coisas estavam sendo interrompidas por causa disso e isso gera esse erro. A correção é atualizar my.cnf com a configuração correta para innodb_buffer_pool_size.


1

Vá para Workbench Editar → Preferências → Editor SQL → Tempo limite de leitura das conexões DBMS: até 3000. O erro não ocorreu mais.


0

Vamos para:

Editar -> Preferências -> Editor SQL

Lá você pode ver três campos no grupo "MySQL Session", onde agora você pode definir os novos intervalos de conexão (em segundos).


0

Acontece que nossa regra de firewall estava bloqueando minha conexão com o MYSQL. Depois que a política de firewall é levantada para permitir a conexão, fui capaz de importar o esquema com sucesso.


0

Eu tive o mesmo problema - mas para mim a solução era um usuário de banco de dados com permissões muito rígidas. Eu tive que permitir a Executehabilidade na mysqlmesa. Depois de permitir que eu não tinha mais conexões perdidas


0

Verifique se os índices estão no lugar primeiro.

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

0

Eu me deparei com isso enquanto executava um processo armazenado - que estava criando muitas linhas em uma tabela no banco de dados. Eu pude ver o erro logo após o tempo ultrapassar o limite de 30 segundos.

Eu tentei todas as sugestões nas outras respostas. Tenho certeza de que algumas delas ajudaram, no entanto - o que realmente fez funcionar para mim foi mudar para o SequelPro do Workbench.

Suponho que foi uma conexão do lado do cliente que não consegui detectar no Workbench. Talvez isso ajude outra pessoa também?


0

Se você estiver usando o SQL Work Bench, poderá tentar usar a Indexação, adicionando um índice às suas tabelas, para adicionar um índice, clique no símbolo de chave inglesa (chave inglesa) da tabela, ele deverá abrir a configuração da tabela, abaixo , clique na exibição de índice, digite um nome de índice e defina o tipo como índice. Nas colunas de índice, selecione a coluna principal em sua tabela.

Execute o mesmo passo para outras chaves primárias em outras tabelas.


0

Parece haver uma resposta faltando aqui para aqueles que usam SSH para se conectar ao banco de dados MySQL. Você precisa verificar dois lugares e não 1, conforme sugerido por outras respostas:

Workbench Editar → Preferências → Editor de SQL → DBMS

Workbench Editar → Preferências → SSH → Tempo Limites

Meus tempos limite de SSH padrão foram definidos muito baixos e causando alguns (mas aparentemente não todos) dos meus problemas de tempo limite. Depois, não esqueça de reiniciar o MySQL Workbench!

Por último, pode valer a pena entrar em contato com o administrador do banco de dados e pedir que ele aumente as propriedades wait_timeout e interactive_timeout no próprio mysql via my.conf + mysql restart ou faça um conjunto global se reiniciar o mysql não for uma opção.

Espero que isto ajude!


0

Três coisas a serem seguidas e certifique-se:

  1. Se várias consultas mostram conexão perdida?
  2. como você usa set query no MySQL?
  3. como excluir + atualizar consulta simultaneamente?

Respostas:

  1. Sempre tente remover o definidor, pois o MySQL cria seu próprio definidor e, se várias tabelas envolvidas para atualização tentarem fazer uma única consulta, às vezes várias consultas mostram perda de conexão.
  2. Sempre defina o valor na parte superior, mas após DELETE, se sua condição não envolver o valor SET.
  3. Use EXCLUIR PRIMEIRO E ATUALIZADO SE AS DUAS OPERAÇÕES FOREM REALIZADAS EM DIFERENTES TABELAS

-1

verifique sobre

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

Espero que isto ajude


-1

Isso geralmente significa que você tem "incompatibilidades com a versão atual do MySQL Server", consulte mysql_upgrade. Encontrei esse mesmo problema e simplesmente tive que executar:

mysql_upgrade --password A documentação declara que "mysql_upgrade deve ser executado sempre que você atualizar o MySQL".

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.