Home / server / Questions / 477448
In Process
Devator
Asked: 2013-02-11 14:01:18 +0800 CST

MySQL keeps crashing: InnoDB: Unable to lock ./ibdata1, error: 11

  • 772

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.

/var/log/mysql-error.log output:

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.

I have found a topic on the mySQL website here however there's no solution for it.

Any ideas anyone?

mysql

11 Answers

  1. another approach from one comment in the same blog:

    this helped me:

    lsof -i:3306

    Then kill it (the process number)

    kill -9 PROCESS

    e.g. kill -9 13498

    Then try to restart MySQL again.

    via http://www.webhostingtalk.com/archive/index.php/t-1070293.html

    • 47

  2. with ubuntu 14.04. I'm experiencing this problem when I try to restart via

    /etc/init.d/mysql restart

    Instead try

    service mysql restart
    • 30

  3. Solution

    make a copy of the original files (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

    • 27

  4. 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.

    • 22

  5. This helped me to solve it:

    Delete all ibdata files and let mysql create them.

    stop mysql:

    service mysql stop

    go to mysql library:

    cd /var/lib/mysql/

    move innodb files somewhere in case you need it:

    mv ib* /root/

    start mysql:

    service mysql start
    • 6

  6. Check space to make sure it is 100%

    df -h

    As if its full it wont create .sock file.

    • 3

  7. As other users are reporting, this is usually due to MySQL not being properly terminated upon systemctl stop mysql.service .

    I noticed on Ubuntu 18.04 that filling in the root password twice in /etc/mysql/debian.cnf made systemctl stop and start the MySQL server process properly which eliminated the problem.

    • 2

  8. 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):

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

    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.

    Hope this help someone.

    • 1

  9. Please check that you have pid-file parameter in the [mysql] section of my.cnf file. If it is not present, the unable to lock ...ibdata1.. error:1 will occur.

    • 0

  10. Simple, but faster than the way with "cp -a". And helped when "cp -a" and everything other couldn't.

    1. service mysql stop && pkill -f mysql

    Get rid of all mysql processes

    1. vi /etc/mysql/my.cnf

    Change parameter datadir=/var/lib/mysql to datadir=/var/lib/mysql2 (or just add if you don't have)

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

    Rename datadir to a new name

    1. service mysql start

    Prepare your tambourine

    • 0