MySQL продолжает падать: InnoDB: невозможно заблокировать ./ibdata1, ошибка: 11

У меня есть простой веб-сервер (Debian 6.0 x86, DirectAdmin с 1 ГБ памяти и 10 ГБ свободного места, mySQl версии 5.5.9), однако сервер mySQL продолжает падать, и мне нужно убить все процессы mySQL, чтобы иметь возможность перезапустить его опять таки.

/var/log/mysql-error.log выход:

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.

Я нашел тему на веб-сайте mySQL здесь, но нет никакого решения для этого.

Любые идеи кто-нибудь?

другой подход из одного комментария в том же блоге:

это помогло мне:

lsof -i: 3306

Тогда убей его (номер процесса)

убить -9 ПРОЦЕСС

например, убить -9 13498

Затем попробуйте перезапустить MySQL снова.

через http://www.webhostingtalk.com/archive/index.php/t-1070293.html

с убунту 14.04. Я испытываю эту проблему, когда пытаюсь перезапустить через

/etc/init.d/mysql restart

Вместо этого попробуйте

service mysql restart 

Наиболее распространенная причина этой проблемы - попытка запустить MySQL, когда он уже запущен.

Чтобы решить эту проблему, убейте все запущенные экземпляры MySQL, а затем перезапустите его, используя обычные сценарии запуска, например service mysql start.

Не пытайтесь запустить MySQL вручную при использовании дистрибутивных версий, если вы не готовы к серьезным последствиям.

Решение

сделать копию оригинальных файлов (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

Это помогло мне решить это:

Удалите все файлы ibdata и позвольте mysql создать их.

остановите mysql:

service mysql stop

перейдите в библиотеку mysql:

cd /var/lib/mysql/

Переместите куда-нибудь файлы innodb, если вам это нужно:

mv ib* /root/

начать MySQL:

service mysql start

Пришел сюда из поисковика той же повторяющейся ошибки, но с кодом ошибки 13 ( InnoDB: Unable to lock ./ibdata1, error: 13). Перепробовав множество решений в интернете, изобрел одно, которое помогло мне (apparmor!)

Добавьте эти строки в конфигурацию /etc/apparmor.d/usr.sbin.mysqld(и перезагрузите apparmor и mysql, конечно):

/path/to/mysql/data/ r,
/path/to/mysql/data/** rwk,

Основные различия между часто встречающимися решениями: два правила (для самого dir и для всех файлов внутри, обратите внимание на двойное **) и kопция, позволяющая mysql блокировать файлы.

Надеюсь, это поможет кому-то.

Проверьте место, чтобы убедиться, что это 100%

df -h

Как будто его полный он не будет создавать файл .sock.

Пожалуйста, проверьте, что у вас есть pid-fileпараметр в [mysql]разделе my.cnfфайла. Если его нет, то unable to lock ...ibdata1.. error:1произойдет.

Просто, но быстрее, чем с "cp -a". И помогло, когда "cp -a" и все остальные не смогли.

1. service mysql stop && pkill -f mysql

Избавьтесь от всех процессов MySQL

2. vi /etc/mysql/my.cnf

Измените параметр datadir = / var / lib / mysql на datadir = / var / lib / mysql2 (или просто добавьте, если у вас его нет)

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

Переименуйте датадир в новое имя

4. service mysql start

Приготовь свой бубен

Если ни одно из других решений не работает, проблема, вероятно, связана с неправильной настройкой AppArmor.

Так что просто сделайте:

$ apt install apparmor-profiles

и затем перезапустите MySQL (обратите внимание, как быстро он будет перезагружен).

Я заметил, что отсутствует файл, связанный с AppArmor при выполнении:

$ systemctl status mysql.service

Поэтому я подумал, что что-то не так с конфигурацией AppArmor.