2016-03-14 02:30:29 58150 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 35 2016-03-14 02:30:29 58150 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
3 Answers 3
First, list MySQL processes using the ps command:
And then kill the process
Believe it or not, the solution is elsewhere. The problem stems from AppArmor misconfiguration apparently.
and then restart MySQL (notice how fast it’ll restart).
I noticed a file missing related to AppArmor when doing:
На одном сервере часто работают сайты использующие базы данных таблицы которых имеют различный тип: MyISAM и InnoDB. Таблицы InnoDB гораздо более эффективны с точки зрения оптимизации приложений, но работать с ними на уровне сервера баз данных сложнее. В частности, восстановление таблиц при их повреждении является довольно трудозатратной процедурой.
Лог всех данных касающихся работы MySQL пишется в один файл, в нем иногда можно видеть записи следующего типа:
Как исправить ошибку InnoDB: Unable to lock ./ibdata1, error: 11
Часто обозначенные выше ошибки можно увидеть в логе когда сервер баз данных не запускается — часто после перезагрузки или сбоя питания.
Из записи Check that you not already have another mysqld process явно следует, что, вероятно, на сервере по какой-то причине запущены или пытаются запуститься 2 процесса MySQL.
Проверяем так ли это
Если обнаружен какой-либо процесс можно отледить его используя strace или завершить стандартным способом или через kill.
Ошибка InnoDB: Unable to lock /path/to/ibdata1, error: 11 обычно соседствует с первой — ее причина в невреных правах на некоторые InnoDB таблицы в /var/lib/mysql или другом каталоге являющемся docdir для сервера баз данных
Исправить ошибку можно выполнив несколько простых команд.
Останавливаем MySQL — часто он уже остановлен и не запускается.
Перемещаем файл ibdata1, в котором хранятся все данные и индексы InnoDB в сторонний каталог делая бэкап
mv /var/lib/mysql/ibdata1 /var/lib/mysql/ibdata1.bak
Копируем файл обратно восстанавливая права.
cp -a /var/lib/mysql/ibdata1.bak /var/lib/mysql/ibdata1
Также скорректировать права на таблицы можно вручную перейдя в /var/lib/mysql и выполнив chown mysql: на все базы данных и таблицы, для которых установлен другой пользователь (часто это root, такое случается когда разработчики редактируют таблицы от имени root). Таблицы с некорректными правами могут успешно обрабатываться, проблемы обычно дают о себе знать после перезапуска MySQL.
MySQL после корректировки прав должен корректно запуститься, также при этом необходимо проверить логи на предмет поврежденных таблиц, при их наличии — восстановить.
I have a simple webserver (Debian 6.0 x86, DirectAdmin with 1 GB of memory and still 10 GB free space, mySQl version 5.5.9), however the mySQL server keeps crashing and I need to kill all mySQL processes to be able to restart it again.
I have found a topic on the mySQL website here however there’s no solution for it.
Any ideas anyone?
10 Answers 10
another approach from one comment in the same blog:
Then kill it (the process number)
e.g. kill -9 13498
Then try to restart MySQL again.
with ubuntu 14.04. I’m experiencing this problem when I try to restart via
The most common cause of this problem is trying to start MySQL when it is already running.
To resolve it, kill off any running instances of MySQL and then restart it using your normal startup scripts, e.g. service mysql start .
Don’t attempt to start MySQL manually when using distribution-packaged versions unless you are prepared for a world of hurt.
Solution
make a copy of the original files (ibdata1, ib_logfile0, ib_logfile1. ).
This helped me to solve it:
Delete all ibdata files and let mysql create them.
go to mysql library:
move innodb files somewhere in case you need it:
Came here from googling of the same repeating error but with error code 13 ( InnoDB: Unable to lock ./ibdata1, error: 13 ). After trying lot of solutions around the internet, invented one that helped me (apparmor!)
Add these lines to the config /etc/apparmor.d/usr.sbin.mysqld (and reload apparmor and mysql of course):
The main differences between often solutions: two rules (for dir itself and for all files inside, note the double ** ) and k option to allow mysql to lock files.