La première partie de la réponse est la bonne nouvelle... que mysqlcheck -o n'est pas plus susceptible d'endommager votre base de données que l'exécution de OPTIMIZE TABLE sur chaque table, parce que c'est tout ce qu'il fait. C'est un utilitaire pratique qui se connecte au serveur, récupère une liste des tables et les parcourt en envoyant un OPTIMIZE TABLE requête au serveur pour une table à la fois, jusqu'à ce qu'elle soit terminée.
Maintenant, quelques mauvaises nouvelles. Si vous avez une corruption latente dans vos espaces de table, OPTIMIZE TABLE pourrait s'y heurter, vous devez donc être certain d'être préparé à cette éventualité, avec des sauvegardes et un plan de récupération. Les chances que cela se produise sont assez faibles, mais c'est l'est un résultat possible.
Pire nouvelle :ils aboient presque certainement le mauvais arbre.
Exécuter Apache et MySQL ensemble sur la même machine avec un trafic important - ou une variation de trafic importante - va à l'encontre des meilleures pratiques et est source de problèmes, car les deux services ont tendance à augmenter leur consommation de mémoire sous charge, et si la base de données est le support stocker les données du site Web, une charge accrue a tendance à se produire sur les deux services en même temps.
Voir ma réponse à InnoDB Crash Post Mortem sur Database Administrators Stack Exchange et Pourquoi Apache se déchaîne et tue MySQL en cas de panne du serveur pour une couverture complète de ce problème assez courant, dont MySQL est la victime, plus que tout.
Notez que peu importe que vous utilisiez InnoDB ou non. Les entrées de récupération de base de données dans le journal des erreurs MySQL seront un peu différentes, mais le résultat est le suivant :précédé de rien de suspect, le journal des erreurs MySQL indique :
mysqld_safe Number of processes running now: 0
Les messages qui suivent celui-ci sont souvent interprétés à tort comme un "crash" de MySQL, mais ce n'est pas ce qui se passe... Il a été tué. MySQL peut même refuser de redémarrer, jusqu'à ce qu'Apache se calme ou soit redémarré, ou que le serveur soit redémarré. Encore une fois, à partir du journal des erreurs, vous pouvez ou non voir quelque chose comme ceci :
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
Vérification de /var/log/syslog ou /var/log/messages (selon la distribution que vous utilisez) vous montrera le vrai problème.
$ sudo egrep 'kernel|oom' /var/log/syslog
...ou messages... devrait révéler un certain nombre d'entrées commençant par ceci :
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache est tellement gourmand en mémoire que le système risque d'être globalement instable, donc "quelque chose" est sacrifié. Ce "quelque chose" est probablement le démon du serveur MySQL, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
MySQL essaiera généralement de redémarrer tout seul, et pour autant que vous le sachiez, cela peut aussi se produire occasionnellement ... mais à moins que les demandes de mémoire d'Apache ne diminuent rapidement, MySQL ne sera pas autorisé à demander suffisamment de mémoire au système et abandonner.
L'optimisation des tables a ses applications valables... mais, dans ce cas, si j'ai correctement identifié votre problème, ce serait tout à fait comparable à la réorganisation des chaises longues sur le navire en perdition Titanic. Cela peut vous faire économiser de l'espace disque, mais cela vous coûtera également de l'espace disque disponible pendant l'exécution, car certains moteurs de stockage créent une copie entièrement nouvelle de la table, puis renommez la copie et supprimez l'ancienne table. Dans tous les cas, il est peu probable qu'il ait un impact significatif sur la consommation de mémoire.
