Reinicio automático de mysql cuando muere

Tengo un servidor de espacio en bastidor que he estado alquilando para ejecutar mis proyectos personales. Como soy barato, tiene 256Mb de RAM y honestamente no puedo manejar mucho. De vez en cuando, cuando hay un aumento brusco en el tráfico, el servidor decide comenzar a matar procesos y parece que mysqld es popular para matar. Intento visitar mi sitio y me recibe el mensaje de que hubo un error al establecer la conexión de la base de datos. La inspección de los registros revela que mysqld fue asesinado debido a la falta de memoria.

Dado que todavía soy tan pobre como era ayer y no quiero actualizar la RAM de mi VM en el espacio de bastidor, ¿hay alguna forma de decirle que reinicie automáticamente mysqld cuando muera?

Tengo la intención de usar algo como crontab, pero, por desgracia, tampoco sé exactamente qué hacer allí. Supongo que soy producto de la generación "Linux en su escritorio", ya que puedo hacer la mayoría de las cosas en mi computadora de escritorio y portátil (que ejecutan Linux casi exclusivamente), pero aún me faltan muchas habilidades de administración de servidores para Linux.

El servidor ejecuta CentOS 6.3

Esta no es una solución limpia, obviamente sería mejor evitar el problema en primer lugar. De todos modos, no estoy seguro de cómo CentOS gestiona los servicios, pero creo que los usa service. Si es así, puede verificar si el mysqlservicio se está ejecutando con

/sbin/service mysql status

Este comando saldrá correctamente si se mysqlestá ejecutando y devolverá un estado de salida que no sea 0 si no lo estoy. Por lo tanto, puede iniciar el servicio si no se ejecuta con este comando:

/sbin/service mysql status || service mysql start

Puede agregar esta línea /etc/crontabpara iniciar el comando thes cada minuto:

* * * * * /sbin/service mysql status || service mysql start

Esto es un poco inquietante.

mysqld siempre es reiniciado por mysqld_safe porque hay un bucle infinito en la parte inferiormysqld_safepara verificar si hay paradas anormales. Si el error es demasiado grave, ni siquieramysqld_safepodría reiniciarsemysqlden intentos posteriores.

Dada esa situación para la que mysqld_safeestá diseñada, puede que no sea una buena idea forzar el mysqldinicio si la mysqld_saferechaza de todos modos.

Necesita localizar el registro de errores en my.cnf, estará debajo

[mysqld]
log-error=log-filename

o

[mysqld_safe]
log-error=log-filename

Lea el archivo de texto (probablemente ejecutando tail -30 log-filename) y encuentre la fuente del proceso mysqld que se está cerrando.

En un intento de fuerza bruta para mantener las cosas funcionando en un VPS con poca memoria, utilicé una modificación de la respuesta de terdom para verificar y reiniciar MySQL.

/sbin/service mysqld status || service mysqld restart

Necesitaba cambiarme mysqlpara mysqldque funcionara. Sin él, obtendría el error " ERROR! MySQL is running but PID file could not be found".

En mi sistema CentOS 7.2, /sbin/serviceredirige a /bin/systemctl status, por lo que el siguiente comando es más rápido de ejecutar.

/bin/systemctl status  mysqld.service || /bin/systemctl start  mysqld.service

Terminé agregando la siguiente línea al crontab raíz del sistema. Comprueba cada minuto si MySQL se está ejecutando y redirige stdout a nulo. Iniciar el servicio no generará nada a menos que algo salga mal, por lo que no es necesario agregar la redirección nula en el último comando.

* * * * * /bin/systemctl status mysqld.service > /dev/null || /bin/systemctl start  mysqld.service

La doble tubería ||significa ORy ejecutará el segundo comando si el primer comando falla de alguna manera. (Devuelve un código de salida mayor que cero).

Es como decir: "Ejecute el primer comando o , si el primer comando falla de alguna manera, ejecute el segundo comando".

Esto es diferente al doble ampersand, &&que es como decir: "Ejecute el primer comando y , solo si el primer comando fue exitoso, ejecute el segundo comando".

Lo siguiente es de jonnyreeves.co.uk :

¡Y el culpable es php-fpm! Un rápido google encontró a otro cliente de Wordpress que sufría síntomas similares; el consejo fue ajustar la configuración del grupo php-fpm (/etc/php-fpm.d/www.conf) y ajustar la configuración pm. El cambio principal fue pasar de pm = dynamica pm = ondemandcon un pm.max_childrenvalor de 5(basado en la observación de ~ 5% de uso de memoria por trabajador). Después de cambiar la configuración, reinicié todos los servicios y verifiqué el uso de la memoria.

service php-fpm restart
service nginx restart
service mariadb restart

Después de reiniciar el uso de memoria fue dramáticamente menor.