MySQL Bugs: #44176: InnoDB Should Not Update Log Files When innodb_force

Bug #44176	InnoDB Should Not Update Log Files When innodb_force_recovery=6
Submitted:	9 Apr 2009 5:22	Modified:	12 Aug 2009 17:27
Reporter:	Mikiya Okuno	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:	Inaam Rana	CPU Architecture:	Any

Description:
When innodb_force_recovery=6 is set, InnoDB log files are updated improperly. InnoDB doesn't read anything from log files when innodb_force_recovery=6, but writes something to log files upon shutdown, thus corrupts log files.

In most cases, log files will be unnecessary because innodb_force_recovery=6 is used when logs are corrupted. But, sometimes users may leave the option not removed, then corrupts logs again.

When the logs are corrupted, the following error message appears in the error log:

090409 14:04:47  InnoDB: Error: page 49 log sequence number 0 46403
InnoDB: is in the future! Current system log sequence number 0 9205.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: for more information.

How to repeat:
1. Create some innodb tables, and insert some rows.

2. Restart MySQL Server with innodb_force_recovery=6

3. Restart MySQL Server without innodb_force_recovery

4. See some log corruption errors.

Suggested fix:
I can workaround the problem with innodb_fast_shutdown=2 when innodb_force_recovery=6.

logs_empty_and_mark_files_at_shutdown() in log0log.c and innobase_shutdown_for_mysql() in srv0start.c should return at the same point if(srv_fast_shutdown == 2) is specified when (srv_force_recovery >= SRV_FORCE_NO_LOG_REDO)as well.

So, change two sources from

if(srv_fast_shutdown == 2)

to

if(srv_fast_shutdown == 2 || srv_force_recovery >= SRV_FORCE_NO_LOG_REDO)

Bug #37987 was marked as a duplicate of this one. At least it is related (with innodb_force_recovery=3 logs may be read for redo, but still no changes to them should happen).

Mikiya,

Setting innodb_fast_shutdown = 2 is not a proper solution for this. When innodb_force_recovery = 6 the database comes online in an inconsistent state and InnoDB overwrites redo logs. Note that with innodb_force_recovery=6 we can still do CREATE/DROP TABLE which will generate redo logs.

I am not sure what is the advantage of using the same redo once you have started innodb with innodb_force_recovery=6.

Bug #37987 is not a duplicate of this one.

innodb_force_recovery =6 brings database online in inconsistent state and as such trying to use the same logfiles to reopen the database is not a supported behavior. Closing this down as 'not a bug'.