Bug #78275 Implement an InnoDB redo log format version identifier
Submitted: 30 Aug 2015 12:04 Modified: 7 Oct 2015 11:08
Reporter: Marko Mäkelä Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S4 (Feature request)
Version:5.7.8 OS:Any
Assigned to: CPU Architecture:Any

[30 Aug 2015 12:04] Marko Mäkelä
Description:
InnoDB has several times changed its redo log format by introducing new redo log record types. Format changes would lead to misleading reports of redo log corruption.

How to repeat:
Kill a MySQL 5.6 server and try crash recovery with MySQL 5.7.8.
Or, kill a MySQL 5.7.8 server and try crash recovery with MySQL 5.6.

Suggested fix:
In the redo log header (start of the ib_logfile1 file), introduce a format version identifier and textual representation of the software version that created the redo log files.

Furthermore, change the checksum of redo log checkpoint pages, so that older versions of MySQL will refuse to start up on redo log files that were created with a MySQL server that includes this fix.
[11 Sep 2015 9:44] Marko Mäkelä
Posted by developer:
 
This was implemented in MySQL 5.7.9 in
WL#8845 InnoDB: Redo log format version identifier
[7 Oct 2015 11:08] Daniel Price
Posted by developer:
 
Two entries. One for the 5.7.9 release notes and one for 5.8.0 release notes:

Fixed as of the upcoming 5.7.9 release, and here's the changelog entry:

To better manage redo log format changes, the redo log header of the
first redo log file (ib_logfile0) now includes a format version identifier
and a text string that identifies the MySQL version that created the redo
log files. 

A new boolean configuration option,
innodb_log_checksums, replaces the innodb_log_checksum_algorithm option.
innodb_log_checksums=ON enables a CRC-32C checksum, making it the only
supported checksum for redo log pages. 

This patch also removes unused fields from the redo log header and 
checkpoint pages.

Due to redo log format changes introduced by this patch,
upgrading to or downgrading from MySQL 5.7.9 and higher requires a clean
shutdown and, in some cases, removal of existing redo log files. For
instructions related to this change, see <xref
linkend="upgrading-from-previous-series"/>, and <xref
linkend="downgrading-to-previous-series"/>. 

Fixed as of the upcoming 5.8.0 release, and here's the changelog entry:

Due to redo log format differences in MySQL 5.8.0, upgrading to or
downgrading from MySQL 5.8 and higher requires a clean shutdown and, in
some cases, removal of existing redo log files. For more information, see
<xref linkend="upgrading-from-previous-series"/>, and <xref
linkend="downgrading-to-previous-series"/>.