O que poderia causar falha repentina na instalação do MySQL 5.0.67?

O que poderia causar falha repentina na instalação do MySQL 5.0.67?

Eu tenho um antigo Ubuntu 8.10 de 32 bits com MySQL 5.0.67.

Contém 5,7 GB de dados e aumenta cerca de 100 MB todos os dias.

Cerca de 3 dias atrás, a instância do MySQL começou a morrer repentina e silenciosamente (sem entrada de log) durante o mysqldump noturno.

O que poderia estar causando isso?

Atualizar o MySQL é um projeto de longo prazo para mim, a menos que haja um bug específico no 5.0.67, então acho que só precisarei priorizar novamente.

Espero que alguém esteja familiarizado com esse problema, já que esta é uma versão bastante popular que acompanha o Ubuntu 8.10.

Obrigado

Responder1

Há uma mesa muito grande que está sendo descartada ou um monte de mesas de tamanho médio? você está usando a opção -q com mysqldump? Existe uma tabela grande que você está descartando e na qual está sendo gravada? Nesse caso, bloquear uma tabela grande impedirá a execução de qualquer outro thread devido ao bloqueio mantido, o que pode fazer com que seu servidor web/scripts esperem até que a máquina fique sem recursos.

É possível que você esteja usando toda a memória disponível no processo mysql ou mysqldump, fazendo com que o killer OOM (falta de memória) no kernel termine o processo. Para isso, você pode dar uma olhada em kern.log, syslog, mensagens para a string OOM ou algo semelhante a:

Mar 29 16:51:10 xxxxxx kernel: 160688 total pagecache pages
Mar 29 16:51:10 xxxxxx kernel: 2048 pages in swap cache
Mar 29 16:51:10 xxxxxx kernel: Swap cache stats: add 25966, delete 23918, find 150791/151181
Mar 29 16:51:10 xxxxxx kernel: Free swap  = 8228916kB
Mar 29 16:51:10 xxxxxx kernel: Total swap = 8297564kB
Mar 29 16:51:10 xxxxxx kernel: 2228208 pages RAM
Mar 29 16:51:10 xxxxxx kernel: 183093 pages reserved
Mar 29 16:51:10 xxxxxx kernel: 2208385 pages shared
Mar 29 16:51:10 xxxxxx kernel: 1864656 pages non-shared
Mar 29 16:51:10 xxxxxx kernel: mysqld: page allocation failure. order:1, mode:0x20

Responder2

Se não houver nenhuma entrada nos logs, recomendo que você tente rastrear o mysqldump.

strace -f -o strace.output mysqldump your_mysqldump_options

Então dê uma olhada nas últimas linhas do arquivo strace.output. Isso normalmente ilumina o caminho e é uma ótima maneira de começar a depurar esses problemas.

Por outro lado, um aplicativo de tendências como Cacti, Ganglia ou Munin também é útil neste tipo de problemas, pois você pode observar o comportamento do servidor em relação a métricas importantes como conexões TCP, CPU, memória e swap, por exemplo.

Espero que isto ajude.

informação relacionada