Skip navigation links

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


Advanced Search

Unable to lock ./ibdata1, error: 11
Posted by: Prashant Tekriwal ()
Date: April 16, 2013 12:00AM

Hi,

I am a newbie as far as mysql administration is concerned.

Let me first explain the background of how we are using mysqld and then I will explain the issue.

Background:

We have a tool using which QA engineers run their tests by specifying their test scripts. This each run is called a 'job'.

Now we start a new mysql server for each job and when the job finishes we shut it down, which means we don't have a persistent server.

Issue:

Recently one of our users faced an issue where he has hit an error just twice so far, on two different machines i.e. the issue is intermittent but not reproducible at will.

The error we get is 'Unable to lock ./ibdata1, error: 11'. I have pasted the whole mysqld log at end of the post.



The solution that I have found till now around this error is moving the ibdata file, but in our case first of all the ibdata file is newly created and since we don't use persistent server moving ibdata files is of no use because the error is coming when starting a new server on totally new set of mysql files.

I am not able to find any help around this and it will be great if somebody can give some insight to help me fix this.

Here are some of the details you might be interested in:

OS : CentOS release 5.5
Arch : 64 bit
Mysql Version : Mariadb Distribution Version 5.3.5
Engine used : xtradb (Mariadb's varient for innodb)

Let me know if more information is needed.

Here is the output of mysqld.log
===============================================================================

InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
130319 16:28:02 InnoDB: Initializing buffer pool, size = 128.0M
130319 16:28:02 InnoDB: Completed initialization of buffer pool
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
130319 16:28:02 InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
130319 16:28:03 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
130319 16:28:03 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
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.
130319 16:28:04 InnoDB: Assertion failure in thread 47644993965344 in file fil/fil0fil.c line 796
InnoDB: Failing assertion: ret
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2d2d2d d:2d:2d [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 5.3.5-MariaDB-ga
key_buffer_size=134213632
read_buffer_size=131072
max_used_connections=0
max_threads=10001
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 22022775 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x48000
.../mariadb/5.3.5a/libexec/mysqld(my_print_stacktrace+0x24) [0x868d44]
/usr/software/test/share/mariadb/5.3.5a/libexec/mysqld(handle_fatal_signal+0x426) [0x710f26]
/lib64/libpthread.so.0 [0x341fc0eb10]
/lib64/libc.so.6(gsignal+0x35) [0x341f030265]
/lib64/libc.so.6(abort+0x110) [0x341f031d10]
.../mariadb/5.3.5a/lib/mysql/plugin/ha_xtradb.so [0x2aaabbd0792e]
.../mariadb/5.3.5a/lib/mysql/plugin/ha_xtradb.so [0x2aaabbd0a902]
.../mariadb/5.3.5a/lib/mysql/plugin/ha_xtradb.so [0x2aaabbda4d1c]
.../mariadb/5.3.5a/lib/mysql/plugin/ha_xtradb.so [0x2aaabbd27305]
.../mariadb/5.3.5a/libexec/mysqld(ha_initialize_handlerton(st_plugin_int*)+0x31) [0x70a691]
.../mariadb/5.3.5a/libexec/mysqld [0x791d4d]
.../mariadb/5.3.5a/libexec/mysqld(plugin_init(int*, char**, int)+0x6a2) [0x795562]
.../mariadb/5.3.5a/libexec/mysqld [0x5da787]
.../mariadb/5.3.5a/libexec/mysqld(main+0x3a5) [0x5dcc35]
/lib64/libc.so.6(__libc_start_main+0xf4) [0x341f01d994]
.../mariadb/5.3.5a/libexec/mysqld [0x4f2639]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
=================================================================================

Options: ReplyQuote


Subject Views Written By Posted
Unable to lock ./ibdata1, error: 11 11646 Prashant Tekriwal 04/16/2013 12:00AM
Re: Unable to lock ./ibdata1, error: 11 4673 Rick James 04/18/2013 08:33PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.