I've got some very big trouble with my innodb database since friday. The mysql server crashes whenever I do some operations on a specific table which is about 22GB. inserting data works, all other operations on other tables are also working properly.

According to 'innochecksum' all pages are okay. I already tried to use force_innodb_recovery <= 4 but the server passes away and I get a lost connection error when dumping table at row '6199219'. Even on some normal queries a crash occur. Row number is always the same.

Here is what my errorlog says about the crash:

sr@kirk:~$ sudo mysqld --console --verbose
150215 19:20:15 [Note] Plugin 'FEDERATED' is disabled.
150215 19:20:15 InnoDB: The InnoDB memory heap is disabled
150215 19:20:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150215 19:20:15 InnoDB: Compressed tables use zlib
150215 19:20:15 InnoDB: Initializing buffer pool, size = 20.0G
150215 19:20:18 InnoDB: Completed initialization of buffer pool
150215 19:20:18 InnoDB: highest supported file format is Barracuda.
150215 19:20:22  InnoDB: Waiting for the background threads to start
150215 19:20:23 InnoDB: 5.5.41 started; log sequence number 80382959696
150215 19:20:23 [Note] Server hostname (bind-address): ''; port: 3306
150215 19:20:23 [Note]   - '' resolves to '';
150215 19:20:23 [Note] Server socket created on IP: ''.
150215 19:20:23 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=mysqld-relay-bin' to avoid this problem.
150215 19:20:23 [ERROR] Server id not set, will not start slave
150215 19:20:23 [ERROR] Failed to create slave threads
150215 19:20:23 [Note] Event Scheduler: Loaded 0 events
150215 19:20:23 [Note] mysqld: ready for connections.
Version: '5.5.41-0ubuntu0.12.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
150215 19:22:28  InnoDB: Assertion failure in thread 140612062639872 in file btr0pcur.c line 428
InnoDB: Failing assertion: page_is_comp(next_page) == page_is_comp(page)
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
18:22:28 UTC - 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.
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.

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1274444 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fe83528e930
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 = 7fe2cc0b6e60 thread_stack 0x30000

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fe268004b60): is an invalid pointer
Connection ID (thread ID): 14

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.

My system is a ubuntu 12.04 with 32GB RAM

Do you have any idea what I can try to solve the problem? I made a backup of all my data.

Thank you very much in advanced and sorry for my poor english.

  • Did you try to file a bug report as suggested in the log?
    – kasperd
    Feb 15, 2015 at 20:51
  • No, I didn't. I don't know if it's really a bug or a corrupted innodb file. This is why is asked here first.
    – Rausch
    Feb 16, 2015 at 8:30
  • Probably it is both. Given your symptoms, the file is most likely corrupted. Whether the initial corruption happened due to a software bug or a hardware fault may be impossible to tell. However software crashing on a corrupted input file would be regarded as a bug. The process should stay up and respond to queries for those parts of the data unaffected by the corruption, or shut down with a proper error message if the corruption is so bad that it cannot do anything meaningful with the data. It may be considered a low priority bug, but it is still a bug.
    – kasperd
    Feb 16, 2015 at 8:43

1 Answer 1


It's a corruption.

See the failed assertion - page_is_comp(next_page) == page_is_comp(page). It checks if a next page is in the same format (COMPACT or REDUNDANT) as the current one.

InnoDB index can be in either format, but the mix is impossible.

So, go ahead with innodb_force_recovery=1,2,3,4,5,6 (try each value until MySQL starts), dump databases and re-create InnoDB tablespace from scratch.

If MySQL doesn't start even with innodb_force_recovery=6 or crashes when you query it (btw, add option --skip-lock-tables to mysqldump, it helps sometimes) then check out https://twindb.com/recover-corrupt-mysql-database/

  • Thank you!! Your tool helped me a lot and I got my data back. :-)
    – Rausch
    Feb 19, 2015 at 15:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .