Erro de MySQL ao ler pacotes de comunicação

Nos logs de erros do MySQL, vejo alguns avisos como estes:

120611 16:12:30 [Warning] Aborted connection 2619503 to db: 'db_name' user: 'user_name' host: 'webapp_hostname' (Got an error reading communication packets)

Não notei nenhuma perda de dados em si, por isso estou me perguntando o que significa esse aviso ou o que o causa e se é possível resolver o problema que os causa. Isso está no RHEL 6.1 e no MySQL Enterprise 5.5.

Um dos assassinos silenciosos do MySQL Connections é o MySQL Packet.

Primeiro, vamos descobrir o que é um pacote MySQL.

De acordo com a página 99 de "Entendendo o MySQL Internals" (ISBN 0-596-00957-7) , aqui estão os parágrafos 1-3 que explicam os Pacotes do MySQL:

O código de comunicação de rede do MySQL foi escrito sob a premissa de que as consultas sempre são razoavelmente curtas e, portanto, podem ser enviadas e processadas pelo servidor em um pedaço, chamado de pacote na terminologia do MySQL. O servidor aloca a memória para um buffer temporário para armazenar o pacote e solicita o suficiente para ajustá-lo totalmente. Essa arquitetura requer uma precaução para evitar que o servidor fique sem memória - um limite para o tamanho do pacote, que essa opção realiza.

O código de interesse em relação a esta opção é encontrado em sql / net_serv.cc . Dê uma olhada em my_net_read () , siga a chamada para my_real_read () e preste atenção especial a net_realloc () .

Essa variável também limita o comprimento de um resultado de muitas funções de string. Veja sql / field.cc e sql / intem_strfunc.cc para obter detalhes.

Saber isso sobre os pacotes MySQL permite que um desenvolvedor / DBA os dimensione para acomodar vários BLOBs dentro de um pacote, mesmo que sejam desagradáveis. Definitivamente, um pacote muito pequeno causará problemas para conexões abertas a esse respeito.

De acordo com a documentação MySQL

• Você também pode obter esses erros se enviar uma consulta ao servidor incorreta ou muito grande. Se o mysqld recebe um pacote muito grande ou fora de ordem, assume que algo deu errado com o cliente e fecha a conexão. Se você precisar de grandes consultas (por exemplo, se estiver trabalhando com grandes colunas BLOB), poderá aumentar o limite de consultas configurando a variável max_allowed_packet do servidor, que possui um valor padrão de 1 MB. Você também pode precisar aumentar o tamanho máximo do pacote no lado do cliente. Mais informações sobre a configuração do tamanho do pacote são fornecidas na Seção C.5.2.10, “Pacotes muito grandes”.

• Uma instrução INSERT ou REPLACE que insere muitas linhas também pode causar esse tipo de erro. Qualquer uma dessas instruções envia uma única solicitação ao servidor, independentemente do número de linhas a serem inseridas; portanto, muitas vezes você pode evitar o erro reduzindo o número de linhas enviadas por INSERT ou REPLACE.

RECOMENDAÇÃO

Tente aumentar o max_allowed_packet para um número muito maior, pois o padrão é 1M. Eu sugeriria cerca de 10 vezes o maior campo TEXT ou BLOB que você possui no seu conjunto de dados atual.

Para definir o max_allowed_packet como 256M, você pode adicioná-lo ao /etc/my.cnf ou my.ini

[mysqld]
max_allowed_packet=256M

para cobrir futuras reinicializações do mysqld. Para instalar o valor agora no servidor, execute o seguinte:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;

De uma chance !!!

Por padrão, max_connections será 100. Tente aumentar o parâmetro de configuração

max_connections = 400, após a configuração no my.cnf, reinicie o servidor ou configure-o dinamicamente:

    set @@global.max_connections = 400;

Basta tentar a recomendação acima para evitar essas mensagens de aviso e também garantir que sua rede não tenha queda de pacotes.

Eu encontrei esse problema recentemente depois de passar do MySQL Enterprise 5.1.x para 5.7.x , sem nenhuma alteração significativa no código do aplicativo que a ' nota ' começou a aparecer.

No meu caso, a causa principal da ' anotação ' exibida foi o programa saindo com as conexões ainda abertas. As circunstâncias para as conexões não serem fechadas eram um pouco mais envolvidas e não relacionadas ao MySQL, mas ao ACE, threads e TSS.

Esta linha my.ini resolveu meu problema:

log_error_verbosity=1

Faça referência a este link