Impossible de démarrer mysql - mysql respawning trop vite, arrêté
Aujourd'hui, j'ai effectué une nouvelle installation d'ubuntu 12.04 et je me suis occupé de la configuration de mon environnement de développement local. J'ai installé mysql et édité /etc/mysql/my.cnf pour optimiser InnoDB mais lorsque j'essaie de redémarrer mysql, il échoue avec une erreur:
[20:53][tom@Pochama:/var/www/website] (master) $ Sudo service mysql restart
start: Job failed to start
Le syslog révèle un problème avec le script init:
> tail -f /var/log/syslog
Apr 28 21:17:46 Pochama kernel: [11840.884524] type=1400 audit(1335644266.033:184): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=760 comm="apparmor_parser"
Apr 28 21:17:47 Pochama kernel: [11842.603773] init: mysql main process (764) terminated with status 7
Apr 28 21:17:47 Pochama kernel: [11842.603841] init: mysql main process ended, respawning
Apr 28 21:17:48 Pochama kernel: [11842.932462] init: mysql post-start process (765) terminated with status 1
Apr 28 21:17:48 Pochama kernel: [11842.950393] type=1400 audit(1335644268.101:185): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=811 comm="apparmor_parser"
Apr 28 21:17:49 Pochama kernel: [11844.656598] init: mysql main process (815) terminated with status 7
Apr 28 21:17:49 Pochama kernel: [11844.656665] init: mysql main process ended, respawning
Apr 28 21:17:50 Pochama kernel: [11845.004435] init: mysql post-start process (816) terminated with status 1
Apr 28 21:17:50 Pochama kernel: [11845.021777] type=1400 audit(1335644270.173:186): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=865 comm="apparmor_parser"
Apr 28 21:17:51 Pochama kernel: [11846.721982] init: mysql main process (871) terminated with status 7
Apr 28 21:17:51 Pochama kernel: [11846.722001] init: mysql respawning too fast, stopped
Des idées?
Choses que j'ai déjà essayées:
J'ai cherché sur Google et trouvé un bogue Ubuntu avec apparmor ( https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/970366 ), j'ai changé apparmor du mode d'application à la plainte. mode:
Sudo apt-get install apparmor-utils
Sudo aa-complain /usr/sbin/mysqld
Sudo /etc/init.d/apparmor reload
mais ça n'a pas aidé. Je ne peux toujours pas démarrer mysql.
Je pensais aussi que le problème était peut-être dû au fait que les fichiers journaux InnoDB avaient une taille différente de celle attendue par mysql. J'ai supprimé les fichiers journaux innodb avant de redémarrer en utilisant: Sudo mv /var/lib/mysql/ib_logfile* /tmp. Pas de chance cependant.
Solution de contournement: J'ai réinstallé la 12.04, en veillant à ne pas toucher /etc/mysql/my.cnf de quelque manière que ce soit. Mysql travaille pour que je puisse continuer avec ce que je dois faire. Mais j'aurai besoin de la modifier à un moment donné - j'espère que j'aurai trouvé une solution, sinon on aura répondu à cette question à ce moment-là ...
J'ai finalement compris le problème. Fondamentalement, la définition de certains paramètres a été supprimée de la version précédente de mysql et remplacée par des noms différents. Pour réparer, dans /etc/mysql/my.cnf, remplacez:
# Tom Added to ensure the server character set is set to utf8
default-character-set = utf8
default-collation = utf8_general_ci
avec:
# Tom Added to ensure the server character set is set to utf8
character_set_server = utf8
collation_server = utf8_general_ci
Voici le rapport de bogue du tableau de bord associé: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/95812 .
Ou facilement exécuter:
# Miraz added dpkg-reconfigure
dpkg-reconfigure mysql-server-5.5
Mais assurez-vous qu’il n’y ait pas d’ancienne installation de la version de MySQL installée, s'il y en avait une, supprimez-la:
# Miraz quick mysql package check
dpkg -l *mysql*
J'avais un problème similaire. C'était frustrant car je ne pouvais voir aucun journal d'erreur indiquant le problème.
Dans mon cas, la valeur que j'avais définie pour innodb_buffer_pool_size était trop grande pour la mémoire du serveur.
J'ai découvert cela en exécutant mysqld directement en tant qu'utilisateur mysql.
# su mysql
# mysqld
De cette façon, vous voyez réellement la sortie d'erreur.
Innodb a un paramètre par défaut (innodb_buffer_pool_size) qui est défini sur 128 Mo. Ce paramètre est peut-être trop volumineux pour votre serveur (surtout si vous utilisez une petite AMI Amazon EC2 - ce que j'étais). Le correctif qui a fonctionné pour moi a été d'ajouter ce qui suit: ligne à /etc/mysql/my.cnf
innodb_buffer_pool_size = 16M
J'ai écrit à propos de ce correctif ici http://www.mlynn.org/2012/07/mysql-5-5-on-ubuntu-12-04-job-failed-to-start
J'ai aussi eu un problème similaire. Les éléments ci-dessous indiquent qu'ils ont été supprimés de mysql server 5.5.
Si vous les avez dans votre my.cnf, il ne commencera pas. Commentez-les avec #.
(Informations dérivées de: http://dev.mysql.com/doc/refman/5.5/en/replication-options-slave.html )
Les options concernées apparaissent dans cette liste:
--master-Host
--master-user
--master-password
--master-port
--master-connect-retry
--master-ssl
--master-ssl-ca
--master-ssl-capath
--master-ssl-cert
--master-ssl-cipher
--master-ssl-key
Cela semble se résumer à des erreurs dans la configuration de MySQL, située dans /etc/mysql/my.cnf et dans des fichiers dans /etc/mysql/conf.d/.
Dans mon cas, il s'agissait d'une valeur bind-address incorrecte, car l'adresse IP de ma machine avait changé et MySQL ne pouvait plus se lier. N'hésitez pas à en savoir plus à ce sujet dans cet article de blog .
Un bon moyen de déboguer les échecs dans le processus de post-démarrage (/etc/init/mysql.conf) consiste à vérifier les journaux en amont:
Sudo tail -f /var/log/upstart/mysql.log
Cela m'a donné une erreur de socket:
erreur: 'Impossible de se connecter au serveur MySQL local via socket
Dans mon cas, cela est dû à un paramètre user manquant dans le groupe [mysqld] dans my.cnf
Vérifiez les autorisations /tmp. J'ai eu ce problème, après plusieurs recherches sur Google et redémarrages, j'ai découvert que /tmp permissions était de 755.
Je le change en 777 et mysql commence bien.
J'ai eu le même problème. Il s’est avéré qu’il s’agissait des réplications du maître mysql my.cnf. Vérifiez votre /var/log/mysql/error.log.
J'espère que c'est un peu d'aide. Vérifiez les paramètres de mysql avant de perdre deux heures avec apparmor, qui fonctionne parfaitement.
Lorsque j'avais une erreur MySQL similaire ("Job failed to start") après la mise à niveau de 11.10 à 12.04, commentez le commentaire 27 sur https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+ bug/573318? commentaires = all a parfaitement fonctionné pour moi. Citation:
Le problème pour moi était que le fichier /etc/apparmor.d/local/usr.sbin.mysqld n'existait pas après la mise à niveau. J’ai copié manuellement l’un des fichiers vides (c’est-à-dire qu’il n’avait que le commentaire en-tête), puis tout était prêt.
Pour moi, la solution était de supprimer la ligne ...
set-variable = max_connections=200
... qui est la syntaxe MySQL 3.x et doit être changé en
max_connections=200
Après une mise à jour automatique de mysqld-5.5.53 ubuntu 14.04.1, mysql ne pouvait pas démarrer. Ces lignes sont apparues dans mon syslog:
Oct 27 06:05:51 hostname kernel: [ 593.168925] init: mysql post-start process (4997) terminated with status 1
Oct 27 06:05:51 hostname kernel: [ 593.178241] type=1400 audit(1477562751.231:31): apparmor="STATUS" operation="profile_replace" profile="unconfined" name
Oct 27 06:05:51 hostname kernel: [ 593.204392] init: mysql main process (5032) terminated with status 1
Oct 27 06:05:51 hostname kernel: [ 593.204404] init: mysql respawning too fast, stopped
Le problème a été résolu en créant ce répertoire:
Sudo mkdir /var/lib/mysql-files
Sudo chmod 700 /var/lib/mysql-files
Sudo chown mysql:mysql /var/lib/mysql-files
Sudo /etc/init.d/mysql start
J'ai eu les mêmes problèmes, pour moi le bind-address a été mal défini dans mon fichier /etc/mysql/my.cnf. Il semble donc que tout ce qui ne va pas dans le fichier my.cnf peut causer ce problème. Je n'ai rien trouvé dans les journaux qui indique que c'est le problème.
Mon problème était 0% d'espace libre! Revérifier :-)
J'ai eu les mêmes messages d'erreur, mais la cause était différente. Mes tables InnoDB étaient corrompues, car tout le système de fichiers était en lecture seule. J'ai corrigé la corruption en ajoutant la ligne suivante à /etc/mysql/my.cf
innodb_force_recovery = 1
J'ai démarré MySQL:
Sudo service mysql start
MySQL a démarré et j'ai vidé/exporté toutes les tables. J'ai remplacé innodb_force_recovery par 0 (= valeur par défaut) et redémarré MySQL:
Sudo service mysql restart
J'utilise Ubuntu 12.04 avec MySQL 5.5. J'ai mis longtemps à trouver le problème et j'espère pouvoir aider quelqu'un avec cette réponse. Voir aussi http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Dans mon cas, le problème était l'autorisation du fichier /etc/mysql/my.cnf.
Je l’ai changé par cenvenience mais cela a causé des erreurs comme
kernel: [604528.290448] type=1400 audit(1424350956.727:193): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/mysqld" pid=15008 comm="apparmor_parser"
La permission my.cnf était de 766 et je l’ai changée en 744 et deux des trois erreurs ont disparu. Il y a toujours un message d'erreur similaire mais cela n'a pas empêché mysql de démarrer.
J'espère que cela t'aides...
Dans mon cas, j'avais une mauvaise déclaration bind-address. J'ai lancé ifconfig pour découvrir l'adresse IP privée de l'EC2 et l'ai mise à jour dans le fichier /etc/mysql/my.cnf.
Dans mon cas, j'ai trouvé un problème de permission sur/tmp. Je viens de définir l'autorisation du répertoire du tmp sur 766 et de redémarrer le service mysql. Fixé sur.
Vient de mettre à jour les versions de MySQL et AppArmor comme suggéré ici pour résoudre ce problème sous Ubuntu 12.04 exécuté sur une instance Amazon ec2. Je reçois toujours l'erreur quelques fois mais MySQL redémarre automatiquement.