Configuring innodb_force_recovery to troubleshoot InnoDB page corruption

MinervaDB Corporation — Sun, 08 Apr 2018 09:06:36 +0000

I personally don’t encourage my readers to follow this post in production without clearly understanding about InnoDB page corruption error troubleshooting, Setting innodb_force_recovery is done only when there is innodb page corruption emergency. By default innodb_force_recovery is 0 (normal startup without forced recovery). You can set values from 1 to 6, The larger values includes the functionality of smaller ones. For example, value 4 will include functionality of 1, 2 and 3. If you are able to dump your tables with an innodb_force_recovery value of 3 or less, then you are relatively safe and only some limited data on corrupt individual pages are lost. A value of 4 or higher is considered dangerous because data files can be permanently corrupted. A value of 6 is considered extreme step because database pages are left in an obsolete state, causing corrupted database structure and B-tree indexes. InnoDB prevents INSERT, UPDATE and DELETE operations once innodb_force_recovery variable is set greater than 0. InnoDB will be on read-only mode, when innodb_force_recovery setting is 4 or greater.

How innodb_force_recovery values (InnoDB recovery mode) influence MySQL operations

0 (Default InnoDB recovery mode)
1 (SRV_FORCE_IGNORE_CORRUPT) – Server runs even if it detects a corrupt page, This makes query SELECT * FROM TABLE_NAME jump over corrupt index records and pages, helping in dumping tables.
2 (SRV_FORCE_NO_BACKGROUND) – Stops master thread and any purge threads from running, preventing a crash that occurs during a purge, So no purge will be performed and undo logs will keep growing.
3 (SRV_FORCE_NO_TRX_UNDO) – Doest not rollback the transaction after the crash recovery, This will not affect pending rollback of active transactions. This will result in a lock wait due to recovered incomplete transaction whose rollback is being prevented.
4 (SRV_FORCE_NO_IBUF_MERGE) – This value can permanently corrupt data files. You may have to be prepared to drop and recreate all secondary indexes, Eventually it does not calculate table statistics and prevents insert buffer merges.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN) – InnoDB even consider incomplete transactions as committed and this value can permanently corrupt InnoDB data files, sets InnoDB to read-only and does not refer to undo logs when starting MySQL.
6 (SRV_FORCE_NO_LOG_REDO) – This value can permanently corrupt data files, It will not perform redo log roll-forward as part of the recovery, leaving database pages in an obsolete state, which eventually corrupt B-tree and other database structures. Running queries that require indexes are likely to fail with this mode active. If table dump still causes a crash, You can try using SELECT * FROM table1 ORDER BY PRIMARY_KEY DESC to dump all the data portion after the corrupted part.

The post Configuring innodb_force_recovery to troubleshoot InnoDB page corruption appeared first on The WebScale Database Infrastructure Operations Experts.