La primera parte de la respuesta es la buena noticia... que mysqlcheck -o no es más probable que dañe su base de datos que ejecutar OPTIMIZE TABLE en cada mesa, porque eso es todo lo que hace. Es una utilidad de conveniencia que inicia sesión en el servidor, obtiene una lista de las tablas y las itera, enviando un OPTIMIZE TABLE consulta al servidor para una mesa a la vez, hasta que esté hecho.
Ahora, algunas malas noticias. Si tiene daños latentes en sus espacios de tabla, OPTIMIZE TABLE podría encontrarse con él, por lo que debe asegurarse de estar preparado para esa posibilidad, con copias de seguridad y un plan de recuperación. Las posibilidades de que esto ocurra son bastante remotas, pero es un resultado posible.
Peores noticias:es casi seguro que están ladrando al árbol equivocado.
Ejecutar Apache y MySQL juntos en la misma máquina con un tráfico significativo, o una variación significativa del tráfico, va en contra de las mejores prácticas y es una receta para los problemas, porque ambos servicios tienden a aumentar su consumo de memoria bajo carga, y si la base de datos es el respaldo. store para los datos del sitio web, entonces tiende a ocurrir una mayor carga en ambos servicios al mismo tiempo.
Vea mi respuesta a InnoDB Crash Post Mortem en administradores de bases de datos Stack Exchange y ¿Por qué Apache se está ejecutando salvajemente y matando a MySQL? en falla del servidor para una cobertura completa de este problema bastante común, donde MySQL es la víctima, más que nada.
Tenga en cuenta que no importa si está utilizando InnoDB o no. Las entradas de recuperación de la base de datos en el registro de errores de MySQL serán un poco diferentes, pero el indicio claro es este:precedido por nada sospechoso en absoluto, el registro de errores de MySQL dice:
mysqld_safe Number of processes running now: 0
Los mensajes que siguen a ese a menudo se malinterpretan como "fallos" de MySQL, pero eso no es lo que está sucediendo... Ha sido cancelado. MySQL puede incluso negarse a reiniciar, hasta que Apache se calme o se reinicie, o se reinicie el servidor. Una vez más, desde el registro de errores, puede o no ver algo como esto:
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
Comprobando /var/log/syslog o /var/log/messages (según la distribución que ejecute) le mostrará el problema real.
$ sudo egrep 'kernel|oom' /var/log/syslog
...o mensajes... deberían revelar una serie de entradas que comienzan de la siguiente manera:
kernel: pcscd invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0
Apache tiene tanta hambre de memoria que el sistema corre el riesgo de inestabilidad general, por lo que se sacrifica "algo". Es probable que ese "algo" sea el demonio del servidor MySQL, mysqld .
kernel: Out of memory: Killed process 3044, UID 27, (mysqld)
Por lo general, MySQL intentará reiniciarse por sí solo y, por lo que sabe, esto también puede suceder ocasionalmente... pero a menos que la memoria de Apache exija una caída rápida, MySQL no podrá solicitar suficiente memoria del sistema y lo hará. rendirse.
Optimizar las mesas tiene sus aplicaciones válidas... pero, en este caso, si he identificado su problema correctamente, sería muy comparable a reorganizar las sillas de cubierta en el barco que se hunde Titanic. Puede ahorrarle algo de espacio en disco, pero también le costará algo de espacio libre en disco mientras se ejecuta, ya que algunos motores de almacenamiento hacen una copia completamente nueva de la tabla, luego cambian el nombre de la copia y eliminan la tabla anterior. En cualquier caso, es poco probable que tenga un impacto significativo en el consumo de memoria.
