MySQL continue de planter: InnoDB: impossible de verrouiller ./ibdata1, erreur: 11
J'ai un serveur Web simple (Debian 6.0 x86, DirectAdmin avec 1 Go de mémoire et encore 10 Go d'espace libre, mySQl version 5.5.9), mais le serveur mySQL continue de planter et je dois tuer tous les processus mySQL pour pouvoir le redémarrer encore.
/var/log/mysql-error.log production:
130210 21:04:26 InnoDB: Using Linux native AIO
130210 21:04:34 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:05:42 InnoDB: Completed initialization of buffer pool
130210 21:05:48 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:22 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:27 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:06:29 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:07:22 InnoDB: Completed initialization of buffer pool
130210 21:07:51 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:08:33 InnoDB: Completed initialization of buffer pool
130210 21:12:03 [Note] Plugin 'FEDERATED' is disabled.
130210 21:12:47 InnoDB: The InnoDB memory heap is disabled
130210 21:12:47 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
130210 21:12:47 InnoDB: Compressed tables use zlib 1.2.3
130210 21:12:47 InnoDB: Using Linux native AIO
130210 21:13:11 InnoDB: highest supported file format is Barracuda.
130210 21:13:23 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130210 21:14:05 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
130210 21:17:53 InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
130210 21:17:53 InnoDB: Operating system error number 11 in a file operation.
J'ai trouvé un sujet sur le site Web mySQL ici mais il n'y a pas de solution.
Des idées n'importe qui?
une autre approche d'un commentaire dans le même blog:
cela m'a aidé:
lsof -i: 3306
Ensuite, tuez-le (le numéro de processus)
kill -9 PROCESS
par exemple. tuer -9 13498
Essayez ensuite de redémarrer MySQL à nouveau.
via http://www.webhostingtalk.com/archive/index.php/t-1070293.html
avec ubuntu 14.04. Je rencontre ce problème lorsque j'essaie de redémarrer via
/etc/init.d/mysql restart
Essayez plutôt
service mysql restart
La cause la plus courante de ce problème est d'essayer de démarrer MySQL lorsqu'il est déjà en cours d'exécution.
Pour le résoudre, supprimez toutes les instances en cours de MySQL, puis redémarrez-le à l'aide de vos scripts de démarrage normaux, par exemple service mysql start.
N'essayez pas de démarrer MySQL manuellement lorsque vous utilisez des versions distribuées, sauf si vous êtes prêt pour un monde de blessures.
Solution
faire une copie des fichiers originaux (ibdata1, ib_logfile0, ib_logfile1 ...).
mv ibdata1 ibdata1.bak
cp -a ibdata1.bak ibdata1
http://cglreport.zhenhua.info/2008/08/mysql-error-unable-to-lock-ibdata1.html
Cela m'a aidé à le résoudre:
Supprimez tous les fichiers ibdata et laissez mysql les créer.
arrêtez mysql:
service mysql stop
allez dans la bibliothèque mysql:
cd /var/lib/mysql/
déplacez les fichiers innodb quelque part au cas où vous en auriez besoin:
mv ib* /root/
démarrer mysql:
service mysql start
Entré ici de googler de la même erreur de répétition mais avec le code d'erreur 13 (InnoDB: Unable to lock ./ibdata1, error: 13). Après avoir essayé beaucoup de solutions sur Internet, j'en ai inventé une qui m'a aidé (apparmor!)
Ajoutez ces lignes à la configuration /etc/apparmor.d/usr.sbin.mysqld (et rechargez apparmor et mysql bien sûr):
/path/to/mysql/data/ r,
/path/to/mysql/data/** rwk,
Les principales différences entre souvent des solutions: deux règles (pour dir lui-même et pour tous les fichiers à l'intérieur, notez le double **) et k option pour permettre à mysql de verrouiller les fichiers.
J'espère que cela aidera quelqu'un.
Vérifiez l'espace pour vous assurer qu'il est à 100%
df -h
Comme s'il était plein, il ne créera pas de fichier .sock.
Si aucune des autres solutions ne fonctionne, le problème provient probablement d'une mauvaise configuration d'AppArmor.
Alors faites juste:
$ apt install apparmor-profiles
puis redémarrez MySQL (remarquez à quelle vitesse il va redémarrer).
J'ai remarqué un fichier manquant lié à AppArmor en faisant:
$ systemctl status mysql.service
C'est pourquoi j'ai pensé que quelque chose n'allait pas avec la configuration d'AppArmor.
Simple, mais plus rapide que le chemin avec "cp -a". Et aidé quand "cp -a" et tout ce que les autres ne pouvaient pas.
service mysql stop && pkill -f mysql
Débarrassez-vous de tous les processus mysql
vi /etc/mysql/my.cnf
Modifiez le paramètre datadir =/var/lib/mysql en datadir =/var/lib/mysql2 (ou ajoutez-le simplement si vous n'en avez pas)
mv /var/lib/mysql /var/lib/mysql2
Renommez datadir en un nouveau nom
service mysql start
Préparez votre tambourin
Veuillez vérifier que vous avez pid-file paramètre dans le [mysql] section de my.cnf fichier. S'il n'est pas présent, le unable to lock ...ibdata1.. error:1 arrivera.