O balcão 02 perde a conexão com o banco algumas vezes por dia, e a consulta seguinte costuma funcionar. O ping contínuo não mostra perdas, e o caso mostra por que uma falha intermitente pede a evidência da própria conexão que caiu.
O relato
Na filial 01, o balcão 02 perde a conexão com o banco algumas vezes ao dia, e a consulta seguinte costuma funcionar. O usuário relaciona as falhas aos períodos sem atendimento, mas não anotou os horários, e o caixa 01 não tem a mesma queixa. No dia 1º de outubro, o suporte acompanha um ping do balcão 02 para o servidor da loja, entre 13:50 e 14:40, sem nenhuma perda. Às 14:35, o usuário avisa que a consulta falhou de novo, e o registro local mostra uma conexão perdida, sem dizer se a conexão era nova ou reutilizada.
O ping sem perdas não exclui a rede, porque o ICMP não testa a conexão do MySQL e não enxerga uma interrupção entre duas sondagens. A investigação precisa da operação, do erro completo, do destino e do histórico da conexão que falhou, comparados com o servidor no mesmo período. Um teste de porta feito depois da recuperação só mostra que o serviço estava disponível naquele momento.
A falha e a recuperação
O registro do balcão 02 mostra a sequência:
2026-10-01T14:35:10-03:00 balcao=02 operacao=CONS-0068 erro=20062026-10-01T14:35:12-03:00 balcao=02 conexao=nova destino=192.168.1.10:33062026-10-01T14:35:13-03:00 balcao=02 operacao=CONS-0069 resultado=consulta_concluida
O erro 2006 indica que o programa perdeu a conexão com o servidor. Em seguida, o programa abriu uma conexão nova, e a consulta seguinte terminou. As duas operações são consultas, sem gravação de vendas. Os registros coletados não mostram parada do MySQL nem reinício do Windows nesse período.
A recuperação não explica a queda. Antes de aumentar prazos ou de trocar cabos, o próximo passo é conferir como aquela conexão vinha sendo usada, porque a hipótese de uma conexão encerrada por ficar ociosa combina com o relato do usuário. Se a falha acontecesse em uma conexão recém-aberta, essa hipótese perderia força.
A conexão ociosa
O diagnóstico do programa associa a falha à conexão 42, cuja última consulta foi às 14:00:02, cerca de 35 minutos antes, sem comandos no intervalo. A conexão nova, às 14:35:12, recebeu outro identificador. O administrador informa que a variável wait_timeout do servidor está em 1800 segundos, ou 30 minutos, o tempo que o MySQL espera antes de encerrar uma conexão sem atividade.
O valor torna o limite de ociosidade uma hipótese concreta, mas não prova o valor que valia para a conexão 42, porque uma sessão pode ser criada com outro valor. O log do MySQL também traz um aviso de conexão abortada, sem nada que o ligue à conexão 42, e o horário parecido, sozinho, não basta para essa ligação. O encerramento pelo servidor, pelo programa ou por um equipamento no caminho ainda precisa de evidência própria.
A reprodução
O suporte combina uma janela de testes com consultas de leitura e registra o destino, a conexão, o último uso e o resultado, com o log do servidor no mesmo intervalo. Uma conexão com consultas periódicas continua funcionando. Outra, depois de 35 minutos sem consultas, falha no primeiro uso e é substituída por uma conexão nova, que responde, sem nenhum reinício registrado.
O resultado reproduz a ligação entre a ociosidade e a falha, mas ainda não mostra qual componente encerrou a conexão, porque o servidor e os equipamentos do caminho podem ter regras próprias. O próximo material é o registro do encerramento daquela sessão no servidor ou, se ele não bastar, uma captura do tráfego TCP na janela combinada, feita com o responsável técnico e sem conteúdo sensível. A mudança de prazos fica para depois dessa evidência.
O registro do atendimento
O registro separa o que foi confirmado do que ainda é hipótese:
- Ocorrência: a consulta CONS-0068 do balcão 02 falhou às 14:35:10 com o erro 2006, depois de cerca de 35 minutos sem comandos na conexão 42;
- Evidências: o ping não teve perdas entre 13:50 e 14:40, e os registros não mostram parada do MySQL nem reinício do servidor;
- Reprodução: a conexão ociosa falhou no primeiro uso, e a conexão ativa continuou respondendo;
- Hipótese: o encerramento por ociosidade, compatível com o wait_timeout de 1800 segundos, ainda sem a confirmação do componente que encerrou a conexão;
- Próximo passo: a ligação do encerramento à sessão no servidor e, se preciso, a captura do tráfego na janela combinada.
No suporte
Diante de uma falha intermitente, a coleta precisa incluir a própria falha e o que veio antes dela. A recuperação seguinte e o ping sem perdas não explicam a queda anterior.
Para guardar
- O ping sem perdas não exclui uma queda da conexão do banco entre as sondagens.
- O erro 2006 indica que o programa perdeu a conexão, sem dizer quem a encerrou.
- A comparação entre a conexão que caiu e a que funcionou orienta a investigação.
- O tempo de ociosidade e um limite configurado formam uma hipótese, e não uma conclusão.
- O registro separa a reprodução obtida da evidência que ainda falta.
Se a conexão 42 tivesse feito uma consulta segundos antes da falha, o que mudaria?
A ociosidade deixaria de explicar a queda, porque a conexão estava em uso. A investigação seguiria para outras causas, como uma interrupção no caminho, um equipamento de rede ou uma falha no servidor durante o uso, com a comparação dos horários das falhas e dos registros dos dois lados.
Aumentar o wait_timeout do servidor resolve o caso?
Ainda não há base para essa mudança. O limite do servidor é uma hipótese, e o encerramento pode ter vindo de um equipamento do caminho. A evidência do encerramento daquela sessão vem antes de qualquer mudança de prazo.