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


43

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?


Et quelle version de MySQL est-ce?
Michael Hampton

Je ne comprends pas - cette partie du fichier journal parle d’un problème rencontré avec MySQL et non d’une cause d’erreur. La meilleure chose à faire est de supprimer la source du problème.
Krzysztof Księżyk

@MichaelHampton La publication a été modifiée (MySQL version 5.5.9 et augmentation du journal).
Devator

1
Avez-vous vérifié qu'il n'y avait aucune exécution de mysqld avant de le démarrer? Comment?
symcbean

Réponses:


32

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


1
service mysql restartne montrait pas déjà de processus en cours, mais lsofje l' ai trouvé. Tué service mysql start, et maintenant, le flot de processus échoué, les emails peuvent cesser. Merci beaucoup.
Doyle Lewis

28

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 

1
Merci, ça m'a aidé. Mais pourquoi?
trop


@too, si vous avez à la fois un script init.d à l'ancienne et une configuration upstart pour un travail, vous devez l'utiliser service job start, sinon, si vous le démarrez avec le script init.d, Upstart ne le saura pas et il pourrait tenter pour démarrer une autre instance. (Au moins , c'est le cas par défaut de MySQL scripts d' initialisation.)
câbleur

@wireman: cela explique pourquoi d'autres paquets, y compris knot (serveur DNS), ont des problèmes similaires. Quand ont-ils décidé de l'appliquer? Je pense que /etc/init.d est supérieur dans la mesure où il permet la complétion du shell, ce qui soulage l’utilisateur des saisies excessives. Progrès à la puissance de -1 :)
aussi le

La complétion de l'onglet @too Bash est personnalisable. Vous n'avez rien d'Ubuntu à portée de main, mais cela semble étrange que personne n'ait pensé à compléter les servicenoms par des tabulations . Vous pouvez peut-être envoyer une demande de fonctionnalité à Canonical via son traqueur de bogues?
un CVn

18

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.


however the mySQL server keeps crashing- Je ne redémarre pas MySQL. Il se bloque tout seul, après quoi je dois le redémarrer évidemment. ;-)
Devator

@ MichaelHampton pouvez-vous donner un peu plus d'informations sur «World of bless» et «démarrer MySQL manuellement»? Merci)
Serge Kvashnin

11

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


comme par magie m'a aidé.
Nils Petersohn

à quoi sert cp -a?, j'ai déjà lu la page de manuel
Ilja

2
Merci beaucoup, ça a aidé. Mais pourquoi?
DaviAragao

J'ai eu ce problème après un échec de redémarrage sur une base de données s'exécutant dans un conteneur Docker. Je suis en train de faire une supposition éclairée quant à la raison pour laquelle cela fonctionne et certaines métadonnées sont stockées dans le fichier. le déplacer et le copier à son emplacement d'origine supprime les métadonnées déterminant son verrouillage. L'opération -a conserve les attributs de fichier, y compris les attributs liés à SELinux, mais pas les métadonnées, pendant la copie.
JDL

2

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

En parcourant les réponses utiles, j'ai pensé que cela fonctionnerait sûrement, car l'erreur consiste à se plaindre de ne pas pouvoir verrouiller ce fichier. Après avoir déménagé, mysql les a recréés mais se plaint toujours ... de fou!
Kyle Burkett

1

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.


Vous pouvez également l'ajouter à /etc/apparmor.d/local/usr.sbin.mysqld. Créez le fichier s'il n'existe pas. Pour plus de détails, veuillez consulter/etc/apparmor.d/local/README
knb

1

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.


La réponse concerne un effet secondaire surprenant, je ne suis absolument pas d'accord pour dire qu'il s'agirait d'un QL.
Peter dit rétablir Monica le

0

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.


0

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

  1. 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)

  1. mv /var/lib/mysql /var/lib/mysql2

Renommer datadir en un nouveau nom

  1. service mysql start

Préparez votre tambourin


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.