Redémarrer automatiquement mysql à sa mort

J'ai un serveur rackspace que j'ai loué pour gérer mes projets personnels. Étant donné que je suis bon marché, il dispose de 256 Mo de RAM et ne peut honnêtement pas gérer beaucoup. De temps en temps, quand il y a une forte augmentation du trafic, le serveur décide de commencer à tuer les processus et il semble que mysqld soit populaire pour qu'il tue. J'essaie de visiter mon site et je suis accueilli par le message selon lequel une erreur s'est produite lors de l'établissement de la connexion à la base de données. L'inspection des journaux révèle que mysqld a été tué par manque de mémoire.

Étant donné que je suis toujours aussi pauvre qu'hier et que je ne souhaite pas mettre à niveau la RAM de ma machine virtuelle rackspace, existe-t-il un moyen de lui dire de redémarrer automagiquement mysqld lorsqu'il meurt?

J'ai une idée d'utiliser quelque chose comme crontab, mais hélas, je ne sais pas exactement quoi faire là non plus. Je suppose que je suis le produit de la génération "Linux sur votre bureau" car je peux faire la plupart des choses sur mon ordinateur de bureau et mon ordinateur portable (qui exécutent Linux presque exclusivement), mais je manque toujours de beaucoup de compétences en administration de serveur pour Linux.

Le serveur exécute CentOS 6.3

Ce n'est pas une solution propre, il serait évidemment préférable d'éviter le problème en premier lieu. Quoi qu'il en soit, je ne sais pas comment CentOS gère les services, mais je pense qu'il utilise service. Si oui, vous pouvez vérifier si le mysqlservice fonctionne avec

/sbin/service mysql status

Cette commande se terminera avec succès si mysqlest en cours d'exécution et retournera un état de sortie différent de 0 si i ne l'est pas. Vous pouvez donc démarrer le service s'il ne s'exécute pas avec cette commande:

/sbin/service mysql status || service mysql start

Vous pouvez ajouter cette ligne à /etc/crontabpour lancer la commande toutes les minutes:

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

C'est un peu dérangeant.

mysqld est toujours redémarré par mysqld_safe car il y a une boucle infinie en bas demysqld_safepour vérifier les arrêts anormaux. Si l'erreur est trop grave, mêmemysqld_safene pourra pas redémarrermysqldlors des tentatives suivantes.

Compte tenu de cette situation qui mysqld_safeest conçue pour, ce n'est peut-être pas une bonne idée de forcer mysqldà démarrer si mysqld_safele rejettera de toute façon.

Vous devez localiser le journal des erreurs dans my.cnf, il se trouve sous

[mysqld]
log-error=log-filename

ou

[mysqld_safe]
log-error=log-filename

Lisez le fichier texte (probablement en exécutant tail -30 log-filename) et recherchez la source de l'arrêt du traitement mysqld.

Dans une tentative de force brute pour maintenir les choses sur un VPS à faible mémoire, j'ai utilisé une modification de la réponse de terdom pour vérifier et redémarrer MySQL.

/sbin/service mysqld status || service mysqld restart

Je devais changer mysqlpour mysqldle faire fonctionner. Sans cela, j'obtiendrais l'erreur " ERROR! MySQL is running but PID file could not be found".

Sur mon système CentOS 7.2, /sbin/serviceredirige vers /bin/systemctl status, de sorte que la commande suivante est plus rapide à exécuter.

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

J'ai fini par ajouter la ligne suivante à la crontab racine du système. Il vérifie toutes les minutes si MySQL est en cours d'exécution et redirige stdout vers null. Le démarrage du service ne produira rien sauf en cas de problème, il n'est donc pas nécessaire d'ajouter la redirection nulle sur la dernière commande.

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

Le double tuyau ||signifie ORet exécutera la 2e commande si la première commande échoue d'une manière ou d'une autre. (Renvoie un code de sortie supérieur à zéro.)

C'est comme dire: "Exécutez la 1ère commande, ou , si la 1ère commande échoue d'une manière ou d'une autre, exécutez la 2ème commande".

C'est différent du double esperluette &&qui revient à dire: "Exécutez la 1ère commande, et , seulement si la 1ère commande a réussi, exécutez la 2ème commande".

Ce qui suit est de jonnyreeves.co.uk :

Et le coupable est php-fpm! Un rapide google a trouvé un autre client Wordpress souffrant de symptômes similaires; le conseil était de modifier la configuration du pool php-fpm (/etc/php-fpm.d/www.conf) et de modifier la configuration pm. Le principal changement consistait à passer de pm = dynamicà pm = ondemandavec une pm.max_childrenvaleur de 5(basé sur l'observation de ~ 5% d'utilisation de la mémoire par travailleur). Après avoir changé la configuration, j'ai redémarré tous les services et vérifié l'utilisation de la mémoire.

service php-fpm restart
service nginx restart
service mariadb restart

Après le redémarrage, l'utilisation de la mémoire était considérablement inférieure.