Impossible de démarrer mysql - mysql réapparaît trop vite, arrêté

32

Aujourd'hui, j'ai effectué une nouvelle installation d'ubuntu 12.04 et j'ai commencé à configurer mon environnement de développement local. J'ai installé mysql et modifié /etc/mysql/my.cnf pour optimiser InnoDB mais lorsque j'essaye de redémarrer mysql, cela échoue avec une erreur:

[20:53][[email protected]:/var/www/website] (master) $ sudo service mysql restart
start: Job failed to start

Le syslog révèle un problème avec le script d'initialisation:

> 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?

Ce que j'ai déjà essayé:

J'ai googlé et trouvé un bug Ubuntu avec apparmor ( lien ), J'ai changé d'apparmor du mode forcé pour plaquer le mode:

sudo apt-get install apparmor-utils
sudo aa-complain /usr/sbin/mysqld
sudo /etc/init.d/apparmor reload

mais cela n'a pas aidé. Je ne peux toujours pas démarrer mysql.

Je pensais aussi que le problème était 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 si.

Solution de contournement: J'ai réinstallé 12.04, en veillant à ne pas toucher /etc/mysql/my.cnf de quelque manière que ce soit. Mysql fonctionne pour que je puisse faire ce que je dois faire. Mais je devrai le modifier à un moment donné - J'espère que j'aurai trouvé une solution, ou que cette question aura été résolue à ce stade ...

    
posée Tom 28.04.2012 - 22:23
la source

18 réponses

28

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 a été remplacée par des noms différents. Pour corriger, 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

Ceci est le rapport de bogue associé au tableau de bord: lien .

Ou exécuter facilement:

# Miraz added dpkg-reconfigure
dpkg-reconfigure mysql-server-5.5

Mais assurez-vous qu’il n’ya pas d’ancienne installation de la version de mysql installée, s'il y en avait, veuillez supprimer:

# Miraz quick mysql package check
dpkg -l *mysql*
    
réponse donnée Tom 01.05.2012 - 09:28
la source
10

Innodb a un paramètre par défaut (innodb_buffer_pool_size) qui est défini sur 128M - cela peut être trop important pour votre serveur (surtout si vous utilisez une petite AMI Amazon EC2 - ce que j'étais). Le correctif pour moi était de Ajoutez la ligne suivante à /etc/mysql/my.cnf

innodb_buffer_pool_size = 16M

J'ai écrit à propos de ce correctif ici lien

    
réponse donnée Mike Lynn 23.07.2012 - 10:19
la source
10

J'ai eu un problème similaire. C'était frustrant parce que je ne pouvais pas voir de journal d'erreur indiquant quel était 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 lançant mysqld directement en tant qu'utilisateur mysql.

# su mysql
# mysqld

De cette façon, vous voyez réellement la sortie d'erreur.

    
réponse donnée Joel 13.01.2013 - 13:24
la source
3

J'ai aussi eu un problème similaire. Les éléments ci-dessous indiquent qu'ils ont été supprimés du serveur mysql 5.5.
Si vous les avez dans votre my.cnf , cela ne démarrera pas. Commentez-les avec # .
(Informations dérivées de: lien )

Les options concernées sont affichées 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
    
réponse donnée Michael Salamon 02.05.2012 - 05:38
la source
3

Cela semble se résumer à des erreurs dans la configuration de MySQL, situées dans /etc/mysql/my.cnf et dans les fichiers dans /etc/mysql/conf.d/ .

Dans mon cas, la valeur de bind-address était incorrecte, car l'adresse IP de ma machine avait changé et MySQL ne pouvait plus se lier. N'hésitez pas à en parler davantage dans cet article de blog .

    
réponse donnée boteeka 04.12.2012 - 10:44
la source
2

Un bon moyen de déboguer les échecs dans le processus de post-démarrage ( /etc/init/mysql.conf ) consiste à vérifier les journaux de démarrage:

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 était dû à un paramètre user manquant sous le groupe [mysqld] dans my.cnf

    
réponse donnée prusswan 13.11.2013 - 07:48
la source
1

Lorsque j'ai eu une erreur MySQL similaire ("Job a échoué à démarrer") après une mise à niveau de 11.10 à 12.04, commentez # 27 sur lien 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 un exemplaire de l’un des vides (c’est-à-dire qu’il n’y avait que des commentaires d’entête) et puis tout allait bien.

    
réponse donnée marcvangend 03.05.2012 - 00:16
la source
1

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
    
réponse donnée Ken West 24.05.2012 - 02:05
la source
1

J'ai eu le même problème. Il s’est avéré que ce sont les 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 d'abord les paramètres de mysql avant de perdre deux heures avec apparmor, qui fonctionne correctement.

    
réponse donnée shadowdroid 30.04.2012 - 15:45
la source
1

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 . Donc, il semble 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 indiquant que cela était le problème.

    
réponse donnée Chris 20.06.2013 - 18:43
la source
1

Mon problème était 0% d'espace libre! Double vérification: -)

    
réponse donnée moamahi 26.07.2013 - 13:50
la source
1

Vérifiez les autorisations /tmp . J'ai eu ce problème, après plusieurs fois googleing et redémarre, j'ai découvert que /tmp autorisations était 755.

Je le change à 777 et mysql commence bien.

    
réponse donnée shgnInc 15.02.2014 - 08:23
la source
1

Après une mise à jour automatique vers mysqld-5.5.53 ubuntu 14.04.1, mysql ne démarre pas. Ces lignes apparaissaient 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
    
réponse donnée Yapsr 27.10.2016 - 12:39
la source
0

Nous venons de mettre à jour la version de MySQL et d’AppArmor comme il est suggéré ici pour corriger ce problème sur Ubuntu 12.04 s'exécute sur l'instance Amazon ec2. Je reçois toujours l'erreur quelques fois mais MySQL redémarre automatiquement.

    
réponse donnée Jay Prakash 23.11.2012 - 14:13
la source
0

J'avais les mêmes messages d'erreur, mais la cause était différente. Mes tables InnoDB étaient corrompues, car tout le système de fichiers passait en mode 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 exporté / exporté toutes les tables. J'ai changé le innodb_force_recovery à 0 (= par défaut) et redémarré MySQL:

sudo service mysql restart

J'utilise Ubuntu 12.04 avec MySQL 5.5. Il m'a fallu beaucoup de temps avant de trouver le problème et j'espère pouvoir aider quelqu'un avec cette réponse. Voir aussi lien

    
réponse donnée Coanda 31.12.2013 - 16:22
la source
0

Dans mon cas, le problème était l’autorisation de fichier /etc/mysql/my.cnf .

Je l'ai changé pour la commodité, 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 766 et je l'ai changée à 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 ça aide ...

    
réponse donnée Marcelo_nnn 19.02.2015 - 14:36
la source
0

Dans mon cas, j'avais une fausse déclaration de 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 .

    
réponse donnée Ralph 26.12.2016 - 11:58
la source
0

Dans mon cas, j'ai trouvé un problème de permission sur / tmp. Je viens de régler la permission du répertoire tmp sur 766 et de redémarrer le service mysql. Corrigé.

    
réponse donnée Fernando Luis Barbosa 29.05.2017 - 14:44
la source

Lire d'autres questions sur les étiquettes