A primeira parte da resposta é a boa notícia... que
mysqlcheck -o não é mais provável que danifique seu banco de dados do que está executando OPTIMIZE TABLE em todas as mesas, porque é tudo o que faz. É um utilitário de conveniência que faz login no servidor, busca uma lista das tabelas e itera através delas, enviando um OPTIMIZE TABLE consulta ao servidor para uma tabela de cada vez, até que seja feito. Agora, algumas más notícias. Se você tiver corrupção latente em seus tablespaces,
OPTIMIZE TABLE pode se deparar com ele, então você deve ter certeza de que está preparado para essa possibilidade, com backups e um plano de recuperação. As chances disso são bastante remotas, mas é um resultado possível. Pior notícia:quase certamente estão latindo na árvore errada.
Executar Apache e MySQL juntos na mesma máquina com tráfego significativo - ou variação de tráfego significativa - é contra as práticas recomendadas e é uma receita para problemas, porque ambos os serviços tendem a aumentar seu consumo de memória sob carga e se o banco de dados for o suporte armazenar dados do site, o aumento da carga tende a ocorrer em ambos os serviços ao mesmo tempo.
Veja minha resposta para InnoDB Crash Post Mortem no Database Administrators Stack Exchange e Por que o Apache está executando o Wild and Killing MySQL na falha do servidor para uma cobertura completa deste problema bastante comum, onde o MySQL é a vítima, mais do que tudo.
Observe que não importa se você está usando o InnoDB ou não. As entradas de recuperação de banco de dados no log de erros do MySQL serão um pouco diferentes, mas a oferta inoperante é esta:precedida por nada suspeito, o log de erros do MySQL diz:
mysqld_safe Number of processes running now: 0
As mensagens seguintes são muitas vezes mal interpretadas como MySQL "travando", mas não é isso que está acontecendo... Ele foi morto. O MySQL pode até se recusar a reiniciar, até que o Apache se acalme ou seja reiniciado, ou o servidor seja reinicializado. Novamente, no log de erros, você pode ou não ver algo assim:
InnoDB: Initializing buffer pool, size = 4.0G
InnoDB: mmap(4395630592 bytes) failed; errno 12
InnoDB: Completed initialization of buffer pool
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Aborting
[Note] /usr/libexec/mysqld: Shutdown complete
mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Verificando
/var/log/syslog ou /var/log/messages (dependendo de qual distro você executa) mostrará o problema real. $ sudo egrep 'kernel|oom' /var/log/syslog
...ou mensagens... devem revelar um número de entradas começando algo assim:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
O Apache fica tão faminto de memória que o sistema corre o risco de instabilidade geral, então "algo" é sacrificado. Esse "algo" provavelmente é o daemon do MySQL Server,
mysqld . kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
O MySQL normalmente tentará reiniciar por conta própria, e até onde você sabe, isso pode acontecer ocasionalmente também... mas a menos que as demandas de memória do Apache caiam rapidamente, o MySQL não poderá desistir.
Otimizar as mesas tem suas aplicações válidas... mas, neste caso, se eu tiver identificado seu problema corretamente, seria muito comparável a reorganizar as cadeiras do convés no navio afundando Titanic. Isso pode economizar algum espaço em disco, mas também custará algum espaço em disco sobressalente durante a execução, pois alguns mecanismos de armazenamento fazem uma cópia totalmente nova da tabela, renomeiam a cópia e excluem a tabela antiga. De qualquer forma, é improvável que tenha algum impacto significativo no consumo de memória.
