Português
English
É das mensagens mais enganadoras que existem, porque parece dizer que o servidor de base de dados se foi abaixo. Quase nunca é isso. Ao pé da letra, o que ela diz é que a ligação que o seu programa tinha aberta deixou de existir a meio, e que o programa só deu por isso quando a tentou usar outra vez.
São quatro causas com peso. Estão aqui por ordem de probabilidade, e as três primeiras têm um número por trás, que fica dito em cada uma.
1. Mandou um pedido maior do que o permitido
É a causa número um numa importação, e a menos suspeitada. Cada instrução que chega ao motor tem um tamanho máximo, e aqui esse máximo é de 256 MB (o valor guardado é 268435456 bytes). Se uma única instrução passar disso, o motor não devolve um erro explicado: fecha a ligação. Do lado de cá lê-se «gone away».
Repare bem no que conta: é o tamanho de uma instrução, e não o do ficheiro. Uma exportação de vários gigabytes entra sem problema nenhum se estiver partida em linhas normais. Um ficheiro muito mais pequeno rebenta se tiver lá dentro uma única instrução gigante, ou uma imagem guardada dentro de uma coluna.
| Se a importação morre sempre no mesmo ponto, o problema prova-se em dois minutos: abra o ficheiro e veja o tamanho da linha onde ela pára. Se for enorme, está encontrado. A cura é voltar a exportar a base de origem em instruções mais pequenas, opção que quase todas as ferramentas de exportação têm. Para ficheiros grandes, o caminho fiável é importar por SSH. |
2. O servidor esperou 30 segundos por si e desistiu
Aceite a ligação, o motor dá 30 segundos para receber o que vem a seguir. É o net_read_timeout. Trinta segundos é uma eternidade para uma consulta normal, e é pouquíssimo para um ficheiro a subir por uma ligação fraca.
Dá-se em dois casos, e são reconhecíveis. O primeiro é uma importação feita a partir do seu computador por uma ligação lenta: o ficheiro vai a caminho, o motor cansa-se de esperar e desliga. O segundo é um programa que abre a ligação no princípio, vai buscar qualquer coisa a outro sítio da internet, e só depois é que manda a consulta.
| Abra a ligação quando precisar dela, e não à cabeça do programa. É uma linha de código mudada de sítio e faz desaparecer esta causa inteira. E se a importação é que é lenta, ponha primeiro o ficheiro no servidor e importe-o de lá: aí não há rede pelo meio. |
3. A ligação ficou parada oito horas
É a causa que toda a gente culpa e é a mais rara das quatro. Uma ligação aberta e sem uso é fechada ao fim de 28 800 segundos, que são 8 horas certas. São os valores do wait_timeout e do interactive_timeout, iguais nos dois.
Oito horas é muito tempo. Uma página web abre e fecha a ligação em frações de segundo, por isso, se o erro aparece num site normal, não é isto. Onde isto morde mesmo é num programa que fica a correr o dia inteiro: um processo de fila de espera, um serviço próprio que liga uma vez ao arrancar, uma sincronização que acorda de vez em quando. Esses têm de saber que a ligação pode ter morrido, e voltar a ligá-la.
4. A consulta foi cortada por consumo
Nos servidores partilhados há um travão, o MySQL Governor do CloudLinux, que impede uma conta de ocupar a base de dados de toda a gente. Quando uma conta passa do que lhe cabe, o que ela está a fazer é segurado e pode ser cortado a meio. Vista do lado da aplicação, uma consulta cortada a meio é exactamente isto: a ligação que estava ali deixou de estar. O travão é do servidor e não tem ecrã no seu painel; o que o painel lhe dá é a página de consumo de recursos da conta.
Reconhece-se pelo comportamento: acontece às horas de mais visitas, nas páginas mais pesadas, e passa sozinho quando o movimento baixa. Para descobrir o que está a gastar, veja o que consome CPU num site e ver o consumo em tempo real por SSH.
A tabela para decidir depressa
| A situação | A causa provável |
| Numa importação, sempre no mesmo ponto do ficheiro | O tamanho de uma instrução, contra os 256 MB. Causa 1. |
| Numa importação, num ponto diferente de cada vez | A espera de 30 segundos, se o ficheiro está a subir pela rede. Causa 2. |
| Num programa que corre o dia todo, ao fim de umas horas | A ligação parada oito horas. Causa 3. |
| Num site normal, só nas horas de ponta, e passa sozinho | Consumo. Causa 4. |
| Num site normal, sempre na mesma página | Uma consulta pesada de mais nessa página, que acaba cortada. Ainda a causa 4, mas com culpado certo. |
| Em tudo ao mesmo tempo, e o phpMyAdmin também não abre | Aí sim, alguma coisa do nosso lado. Não mude nada e avise-nos. |
| Não confunda com o erro de bloqueio. Se a mensagem falar em lock wait timeout, é outra história: duas operações a quererem mexer na mesma linha ao mesmo tempo, e uma delas desiste ao fim de 50 segundos (innodb_lock_wait_timeout). A ligação não caiu; foi a operação que foi recusada. A cura está no código que segura a linha durante tanto tempo, e não na configuração do motor. |
Seja qual for a causa, a linha com a hora e o ficheiro está no registo de erros do PHP da sua conta, e é por aí que se começa: onde está o registo de erros do PHP. Se o erro for outro, e o site não ligar de todo, a lista é esta: erro de ligação à base de dados.
|
Diga-nos em que passo aparece e o que estava a fazer. Com a hora, vemos o que aconteceu do lado do servidor. Abrir um pedido de suporte |
|
VEJA TAMBÉM |
PRODUTO RECOMENDADO Alojamento de sites com cPanel Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 9.000,00 Kz/mês Ver planos |
- 0 Utilizadores acharam útil
