innodb_auto_lru_dump crashes if ib_lru_dump doesn't exist
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Fix Released
|
High
|
Alexey Kopytov |
Bug Description
It is impossible to set innodb_
101219 9:24:43 [Note] Flashcache bypass: disabled
101219 9:24:43 [Note] Flashcache setup error is : open flash device failed
101219 9:24:43 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use InnoDB's own implementation
InnoDB: Compressed tables use zlib 1.2.3
101219 9:24:44 InnoDB: highest supported file format is Barracuda.
101219 9:24:44 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: cannot open ib_lru_dump
101219 9:24:44 - mysqld got signal 11 ;
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.
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.
key_buffer_
read_buffer_
max_used_
max_threads=151
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 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 = (nil) thread_stack 0x30000
./libexec/
./libexec/
[0xefa400]
./libexec/
101219 9:24:44 Percona XtraDB (http://
./libexec/
/lib/libpthread
/lib/libc.
The manual page at http://
information that should help you find out what is causing the crash.
Related branches
- Vadim Tkachenko: Approve
-
Diff: 53 lines (+35/-1)1 file modifiedinnodb_lru_dump_restore.patch (+35/-1)
Changed in percona-server: | |
importance: | Undecided → High |
milestone: | none → release-5.1.54-12.5 |
status: | New → Confirmed |
assignee: | nobody → Alexey Kopytov (akopytov) |
Changed in percona-server: | |
status: | Incomplete → In Progress |
Changed in percona-server: | |
status: | In Progress → Fix Committed |
Changed in percona-server: | |
status: | Fix Committed → Fix Released |
Baron,
I cannot repeat the crash. This is what I get after starting with --innodb_ auto_lru_ dump=5 and no ib_lru_dump in the data dir:
$ ./mysqld --innodb_ auto_lru_ dump=5 table_names= 2 because file system for /usr/local/ mysql/var/ is case insensitive www.percona. com) 1.0.13-12.4 started; log sequence number 527792833
101221 0:58:56 [Warning] Setting lower_case_
101221 0:58:56 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use InnoDB's own implementation
InnoDB: Compressed tables use zlib 1.2.5
101221 0:58:56 InnoDB: highest supported file format is Barracuda.
101221 0:58:56 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: cannot open ib_lru_dump
101221 0:58:56 Percona XtraDB (http://
101221 0:58:56 [Note] Event Scheduler: Loaded 0 events
101221 0:58:56 [Note] ./mysqld: ready for connections.
Version: '5.1.53-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
Unfortunately, stack traces in the error log are useless for plugins, as addresses are not resolved. Can you run mysqld under gdb and get a gdb stack trace for the crash?