O MySQL ainda pode não registrar nada, porque o que provavelmente está acontecendo é que ele está sendo morto sem cerimônia pelo sistema devido à pressão da memória do sistema dos filhos do apache. Deve haver uma trilha disso em / var / log / syslog.
O MySQL deve tentar se reinicializar em um travamento ou terminação forçada, mas a menos que haja memória suficiente disponível, ele não pode fazer isso ... e essa segunda falha não é vista pelo mysqld_safe como um "travamento", mas como um "recusa em começar", por isso não vai continuar tentando. A tentativa de reinicialização com falha é muitas vezes mal interpretada pelos administradores como "falha", já que a natureza da falha original fica oculta atrás de uma mensagem facilmente ignorada no log de erros do MySQL:
mysqld_safe Number of processes running now: 0
Veja InnoDB Crash Post Mortem por uma circunstância que eu suspeito que seja semelhante à sua.
A resposta aparentemente simples para "por que" é que entre o Apache e o MySQL, a carga que você tem e suas configurações atuais, você não tem memória suficiente na máquina e há algum ponto de inflexão relacionado à carga de tráfego que traz esta condição para fora.
O Apache atende a cada solicitação de navegador simultânea de um processo filho, de modo que o número de conexões simultâneas aumenta, o número de filhos aumentará. Primeiro você precisa limitar esse valor na configuração do apache para que você possa entender o que realmente está causando o aumento nas conexões simultâneas ... será simplesmente um pico de tráfego pesado, mas legítimo? Algum tipo de negação de serviço? Consultas de banco de dados que atrasam solicitações porque elas são executadas por muito tempo? Algo precisando otimizar?
Limitar processos do Apache simultâneos deve ajudar a evitar isso, mas, para ser claro, é ingênuo pensar que essa é a solução completa, então não quero implicar isso. Quando os processos são limitados a um nível razoável ou pelo menos mais seguro, você pode identificar o que está realmente acontecendo. (Existem outros controles de restrição no Apache, mas essa não é minha área de especialização.)
A "melhor prática" é, obviamente, executar seu banco de dados em hardware diferente, para que o aplicativo não possa eliminá-lo. Embora pareça mais eficiente, na superfície, "maximizar a utilização" de uma máquina compartilhando-a, isso é uma falsa economia. A maioria da memória usada pelo MySQL, em uma carga de trabalho típica, é alocada no tempo de inicialização e mantida pelo tempo em que o MySQL Server está em execução. As demandas da CPU provavelmente compartilharão horários de pico para o MySQL e o Apache, já que eles estão, em última análise, atendendo a mesma carga. Você pode realmente estar melhor com duas máquinas m1.large em vez da única m1.xlarge, e o custo seria o mesmo, já que a menor é exatamente a metade do preço da maior ... mesmo se você já pagou antecipadamente para o desconto adicional, essa alteração pode ser realizada .