O erro comum do MySQL:“Ocorreu um erro ao ler o pacote de comunicação”

MySQL é o segundo banco de dados famoso do mundo de acordo com o site do DB Engine atrás do Oracle. O que torna o MySQL famoso é provavelmente porque é um sistema de gerenciamento de banco de dados muito rápido, confiável e flexível. MySQL também é um dos bancos de dados suportados no ClusterControl. Você pode facilmente implantar, dimensionar, monitorar e fazer muitas coisas com o ClusterControl.

Hoje não falaremos sobre nenhum deles, mas discutiremos um dos erros comuns do MySQL e possíveis dicas de solução de problemas. Ao trabalhar com tickets, muitas vezes quando verificamos os relatórios ou logs de erros, vimos esta linha "Ocorreu um erro ao ler o pacote de comunicação" com bastante frequência. Achamos que seria benéfico escrever um blog relacionado a esse erro não apenas para nossos clientes, mas também para outros leitores. Não vamos esperar mais, é hora de mergulhar mais!

Protocolo cliente/servidor MySQL

Primeiro de tudo, precisamos entender como o MySQL se comunica entre cliente e servidor. Tanto o cliente quanto o servidor estão usando o protocolo MySQL que é implementado por Conectores, MySQL Proxy e também a comunicação entre os servidores de replicação mestre e escravo. O protocolo MySQL suporta os recursos como criptografia transparente via SSL, compactação transparente, uma fase de conexão e também uma fase de comando.

Tanto os inteiros quanto as strings são os tipos de dados básicos que são usados ​​em todo o protocolo MySQL. Sempre que o cliente e o servidor MySQL quiserem se comunicar ou enviar os dados, ele dividirá os dados em pacotes com tamanho máximo de 16 MB e também adicionará um cabeçalho de pacote a cada bloco. Dentro de cada pacote, haverá uma carga útil que é onde os tipos de dados (inteiros/strings) desempenham suas partes.

Considerando que o CLIENT_PROTOCOL_41 está habilitado, para quase todos os comandos que o cliente envia ao servidor, o servidor responderá qualquer um dos seguintes pacotes como resposta:

Como diagnosticar os problemas

Normalmente, existem dois tipos de problemas de conexão:erros de comunicação ou conexões abortadas. Sempre que ocorrer algum desses problemas de conexão, as seguintes fontes de informação são o bom ponto de partida para a solução de problemas e análise:

• O log de erros
  

• O log geral de consulta
  

• As variáveis ​​de status Aborted_xxx e Connection_errors_xxx
  

• O cache do host
  

Erros de conexão e possíveis motivos

Caso ocorra algum erro de conexão e dependendo dos erros, ele incrementará o contador de status para Aborted_clients ou Aborted_connects nas variáveis ​​de status. Conforme tirado da documentação do MySQL, Aborted_clients significa o número de conexões que foram abortadas porque o cliente morreu sem fechar a conexão corretamente. Quanto a Aborted_connects, significa o número de tentativas malsucedidas de se conectar ao servidor MySQL.

Se você iniciar o servidor MySQL com a opção --log-warnings, é provável que você veja o exemplo da seguinte mensagem em seu log de erros. Como você notou, a mensagem dizia claramente que se relaciona à conexão abortada, portanto, o contador de status Aborted_connects será incrementado na variável de status:

[Aviso] Conexão abortada 154669 para db:'wordpress' usuário:'wpuser' host:'hostname' (Ocorreu um erro ao ler os pacotes de comunicação)

Normalmente, as tentativas de conexão malsucedidas podem ocorrer devido aos seguintes motivos. Quando você notou isso, possivelmente indica que uma pessoa não autorizada está prestes a violar o banco de dados e você pode querer analisá-lo o mais rápido possível:

• Um cliente não tem privilégios para acessar o banco de dados.
  

• Uma credencial errada foi usada.
  

• Um pacote de conexão com informações incorretas.
  

• Devido ao limite atingido para connect_timeout para se conectar.
  

A variável de status para Aborted_clients será incrementada pelo servidor caso um cliente consiga se conectar, mas seja desconectado ou finalizado de maneira inadequada. Além disso, o servidor também registrará uma mensagem de conexão Abortada no log de erros. Para esse tipo de erro, geralmente pode ser devido ao seguinte motivo:

• O cliente não fecha a conexão corretamente antes de sair (não chama mysql_close()).
  

• O cliente excedeu wait_timeout ou Interactive_timeout segundos.
  

• O programa cliente ou aplicativo terminou repentinamente no meio da transferência de dados.
  

Além dos motivos anteriores, outros motivos prováveis ​​para conexões abortadas e problemas de clientes abortados podem estar relacionados a qualquer um dos seguintes:

• Configuração TCP/IP errada.
  

• O valor da variável é muito pequeno para max_allowed_packet.
  

• Alocação de memória insuficiente para consultas.
  

• Hardware defeituoso como ethernets, switches, cabos, etc.
  

• Problemas com a biblioteca de threads.
  

• Problema de síndrome duplex em que a transferência ocorre no modo burst-pause-burst-pause (se você usar o protocolo ethernet com Linux, tanto half quanto full duplex).
  

Como corrigir erros de comunicação do MySQL

Agora que aprendemos muitas potencialidades que causavam erros de conexão do MySQL. Com base em nossa experiência, na maioria das vezes esse problema está relacionado a problemas de firewall ou rede. Também é justo dizer que não é fácil diagnosticar esse tipo de problema. No entanto, a solução a seguir pode ser útil para você resolver esse erro:

• Se seu aplicativo estiver contando com o wait_timeout para fechar a conexão, vale a pena alterar a lógica do aplicativo para que devidamente fechado no final de qualquer operação.
  

• Certificando-se de que o valor de max_allowed_packet esteja dentro do intervalo aceitável para que o cliente não receba nenhum erro relacionado a o “pacote muito grande”.
  

• Para problemas de atraso de conexão que podem ser devidos ao DNS, vale a pena verificar se você tem skip-name- resolução habilitada.
  

• Se você estiver usando um aplicativo PHP ou qualquer outra programação, o melhor é ter certeza de que não aborta as conexões que normalmente são definidas em max_execution_time.
  

• Se você notou muitas notificações TIME_WAIT do netstat, vale a pena confirmar que as conexões são bem gerenciadas no fim da aplicação.
  

• Se você estiver usando Linux e suspeitar que o problema é devido à rede, é melhor verificar a interface de rede usando o comando ifconfig-a e examine a saída no servidor MySQL para qualquer erro.
  

• Para usuários do ClusterControl, você pode habilitar o log de auditoria no cluster -> segurança -> log de auditoria. Ao ativar esse recurso, ele pode ajudá-lo a restringir a localização de qual consulta é a culpada.
  

• Ferramentas de rede como tcpdump e Wireshark podem ser úteis na identificação de possíveis problemas de rede, tempos limite e problemas de recursos para o MySQL.
  

• Verifique regularmente o hardware certificando-se de que não há dispositivos defeituosos, especialmente para ethernets, hubs, switches, cabos etc. Vale a pena substituir o aparelho defeituoso para garantir que a conexão esteja sempre boa.
  

Conclusão

Existem muitas razões que podem levar a problemas de pacotes de conexão do MySQL. Sempre que esse problema ocorrer, ele definitivamente afetará os negócios e as operações do dia a dia. Mesmo que esse tipo de problema não seja fácil de diagnosticar e na maioria das vezes seja devido à rede ou firewall, vale a pena levar em consideração todas as etapas sugeridas anteriormente para corrigir o problema. Nós realmente esperamos que esta postagem do blog possa ajudá-lo de alguma forma, especialmente quando você enfrenta esse problema.