MySQL n'arrête pas de planter: InnoDB: impossible de verrouiller ./ibdata1, erreur: 11

J'ai un simple serveur Web (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 n'arrête pas de planter et j'ai besoin de tuer tous les processus mySQL pour pouvoir le redémarrer. encore.

/var/log/mysql-error.log sortie:

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 de MySQL ici, mais il n'y a pas de solution.

Des idées quelqu'un?

une autre approche d'un commentaire dans le même blog:

cela m'a aidé:

lsof-i: 3306

Puis tuez-le (le numéro de processus)

kill -9 PROCESS

par exemple tuer -9 13498

Puis essayez 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

Au lieu d'essayer

service mysql restart 

La cause la plus courante de ce problème est d'essayer de démarrer MySQL alors qu'il est déjà en cours d'exécution.

Pour le résoudre, supprimez toutes les instances actives 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 fournies avec la distribution, à moins d'être préparé à 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

aller à 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émarrez mysql:

service mysql start

Venu ici de googler de la même erreur répétée, 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 les solutions: deux règles (pour dir lui-même et pour tous les fichiers à l'intérieur, notez le double **) et l' koption permettant à 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 si sa pleine, il ne créera pas de fichier .sock.

Veuillez vérifier que vous avez un pid-fileparamètre dans la [mysql]section du my.cnffichier. S'il n'est pas présent, unable to lock ...ibdata1.. error:1cela se produira.

Simple, mais plus rapide que le chemin avec "cp -a". Et aidé quand "cp -a" et tout ce qui ne pouvait pas.

1. service mysql stop && pkill -f mysql

Débarrassez-vous de tous les processus mysql

2. vi /etc/mysql/my.cnf

Remplacez le paramètre datadir = / var / lib / mysql par datadir = / var / lib / mysql2 (ou ajoutez-le si vous n'en avez pas)

3. mv /var/lib/mysql /var/lib/mysql2

Renommer datadir en un nouveau nom

4. service mysql start

Préparez votre tambourin

Si aucune des autres solutions ne fonctionne, le problème provient probablement d'une mauvaise configuration d'AppArmor.

Alors faites:

$ apt install apparmor-profiles

puis redémarrez MySQL (remarquez à quelle vitesse il redémarrera).

J'ai remarqué qu'il manquait un fichier lié à AppArmor lorsque:

$ systemctl status mysql.service

C'est pourquoi j'ai pensé que quelque chose n'allait pas avec la configuration d'AppArmor.