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

з ubuntu 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

Прийшов сюди з googling тієї ж повторюваної помилки, але з кодом помилки 13 ( InnoDB: Unable to lock ./ibdata1, error: 13). Спробувавши багато рішень в Інтернеті, винайшов таке, яке мені допомогло (прихильність!)

Додайте ці рядки до конфігурації /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

Перейменуйте datadir на нове ім’я

4. service mysql start

Підготуйте свій бубен

Якщо жодне з інших рішень не працює, проблема, ймовірно, випливає з неправильної конфігурації AppArmor.

Тож просто роби:

$ apt install apparmor-profiles

а потім перезапустіть MySQL (зауважте, як швидко він перезапуститься).

Я помітив файл, який відсутній, пов’язаний із AppArmor:

$ systemctl status mysql.service

Тому я подумав, що з конфігурацією AppArmor щось не так.