Bug #71420 innodb_force_recovery=6 seems to cause more problems(4,5 can corrupt sec index)
Submitted: 19 Jan 2014 18:48 Modified: 30 Jan 2014 17:41
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Documentation Severity:S2 (Serious)
Version:5.5.35 OS:Any
Assigned to: Daniel Price CPU Architecture:Any

[19 Jan 2014 18:48] Shane Bester
Seen many times that users tried innodb_force_recovery=6 in a desperate situation..

At least two typical mistakes:

o. Forgot to turn off applications and/or change socket/port number in my.cnf
o. Directly try innodb_force_recovery=6 before trying to 
   startup and shutdown using 1,2,3,4,5 level.

A classic example is seeing this when trying to mysqldump a table:

InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
Version: '5.5.35' MySQL Community Server (GPL)

InnoDB: Assertion failure in thread 6820 in file btr0pcur.c line 430
InnoDB: Failing assertion: btr_page_get_prev(next_page, mtr) == buf_block_get_page_no(btr_pcur_get_block(cursor))


How to repeat:
Very easy to repeat on 5.5.35.

Run any workload with some DML statements on innodb.
Crash server or shutdown with innodb_fast_shutdown=2

Startup server with innodb_force_recovery=6 and try to dump the data, or
just keeping running your working with innodb_force_recovery enabled is enough to crash.

After using level 6 of recovery, it is possible that you will not be able to start the database at all anymore.

Suggested fix:
BEWARE of level 6 recovery. It is documented, but not too clearly imho:


"A value of 6 is more drastic because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures."

See commentary in bug also, and perhaps make bigger warnings in docs about how/when to use innodb_force_recovery=6 ?

[19 Jan 2014 19:23] MySQL Verification Team
At least make it hard to set innodb_force_recovery=6.  Add some undocumented option maybe. It's far too easy to not realize that you shouldn't actually start the instance of your production database with innodb_force_recovery=6 when reading http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

A separate physical copy should be used otherwise it'll get ruined.
[20 Jan 2014 8:16] MySQL Verification Team
From Marko:
yes, anything beyond 3 can permanently corrupt the database
4 can corrupt secondary indexes
5 can cause inconsistent results, also corrupt sec indexes (even if 4 did not have any effect)
[30 Jan 2014 17:41] Daniel Price
A warning has been added and content revisions made to the "Starting InnoDB on a Corrupted Database" section:


The latest revisions should appear soon, with the next published documentation build.

Please note that as of 5.6.15 and 5.7.3 that an innodb_force_recovery setting of 4 or greater places InnoDB in read-only mode.
[11 Feb 2016 10:49] Martin Mokrejs
Please fix the code generating stack dumps NOT to advice users to go straight for level 6 (refer to "You can try to recover the database with the my.cnf" below).

It is the right place to warn users from using levels above 3 as I learned now (too late for my case).

In summary, do not give destructive advices.

Below is an output from mysql-5.6.27.

InnoDB: End of page dump
2016-02-11 11:14:46 7fcbbb0f7740 InnoDB: uncompressed page, stored checksum in field1 2215800878, calculated checksums for field1: crc32 2024863159, innodb 27310463, none 3735928559, stored checksum in field2 537144060, calculated checksums for field2: crc32 2024863159, innodb 662309313, none 3735928559, page LSN 0 2035626805, low 4 bytes of LSN at page end 2036257994, page number (if stored to page already) 325, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an 'inode' page
InnoDB: Also the page in the doublewrite buffer is corrupt.
InnoDB: Cannot continue operation.
InnoDB: You can try to recover the database with the my.cnf
InnoDB: option:
InnoDB: innodb_force_recovery=6
2016-02-11 11:14:46 7fcbbb0f7740  InnoDB: Assertion failure in thread 140512993441600 in file buf0dblwr.cc line 559
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:14:46 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 = 134280 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 0x40000
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.