У меня есть простой веб-сервер (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
Затем убейте его (номер процесса)
kill -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
Пришел сюда из поиска той же повторяющейся ошибки, но с кодом ошибки 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,
Основные отличия между частыми решениями: два правила (для самого каталога и для всех файлов внутри, обратите внимание на двойной **) и k опция, позволяющая mysql блокировать файлы.
Надеюсь, это кому-то поможет.
Проверьте место, чтобы убедиться, что оно на 100%
df -h
Как будто он заполнен, он не создает файл .sock.
Пожалуйста, проверьте, что у вас есть pid-file параметр в [mysql] раздел my.cnf файл. Если его нет, unable to lock ...ibdata1.. error:1 произойдет.
Просто, но быстрее, чем с помощью "cp -a". И помогло, когда "cp -a" и все остальное не смогли.
service mysql stop && pkill -f mysqlИзбавьтесь от всех процессов mysql
vi /etc/mysql/my.cnf Измените параметр datadir = / var / lib / mysql на datadir = / var / lib / mysql2 (или просто добавьте, если у вас его нет)
mv /var/lib/mysql /var/lib/mysql2Переименуйте datadir на новое имя
service mysql start Подготовьте бубен
Если ни одно из других решений не работает, проблема, вероятно, связана с неправильной конфигурацией AppArmor.
Так что просто сделай:
$ apt install apparmor-profiles
а затем перезапустите MySQL (обратите внимание, как быстро он перезапустится).
Я заметил, что отсутствует файл, связанный с AppArmor, когда я делал:
$ systemctl status mysql.service
Вот почему я подумал, что с конфигурацией AppArmor что-то не так.