Bug #78410 Datadir is not portable due to path separators not normalized during recovery

Submitted: 11 Sep 2015 14:42 Modified: 2 Oct 2015 11:35
Reporter: Rahul Sisondia Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.7.9 OS:Any
Assigned to: CPU Architecture:Any

[11 Sep 2015 14:42] Rahul Sisondia
Description:
1. Crash server on Windows while heavy DMLs going on
2. Copy datadir on non-windows platform. 
3. Try to start server. 

Observation - InnoDB crash recovery fails with following error message - 

2015-09-11T14:38:37.941969Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 1316941
2015-09-11T14:38:37.942197Z 0 [ERROR] InnoDB: ############### CORRUPT LOG RECORD FOUND ##################
2015-09-11T14:38:37.942227Z 0 [Note] InnoDB: Log record type 55, page 13:0. Log parsing proceeded successfully up to 1319057. Previous log record type 38, is multi 1 Recv offset 2140, prev 2052
2015-09-11T14:38:37.942236Z 0 [Note] InnoDB: Hex dump starting 100 bytes before and ending 100 bytes after the corrupted record:
 len 288; hex 08170300420000000029041703000cf0ffffffff0417030008f0ffffffff04000b0945031f82008117003802180081180000000504020081180028811002008118002a811002008118006881101f9400811800100b001b047465737407757365725f3130260d03000800028000800080068007800480088008800800c1770007000704000020ff7274657374757365725f3130000000000504a400000118011055f2d7d0000000000000000000000000000000010000000000000000370d00001f2e5c6d7973716c5c696e6e6f64625f7461626c655f73746174732e696264001f82008118003802180081190000000505020081190028811002008119002a811002008119006881101f94008119002d0b001c047465737407757365725f3130; asc     B    )                        E       8               (       *       h             test user_10&                        w         rtestuser_10             U                           7    .\mysql\innodb_table_stats.ibd       8               (       *       h        -    test user_10;

This issue happens because tablespace paths are not normalized while reading them from MLOG_FILE_NAME record. Therefore, 
last method call sets the corrupt flag to true. 

	bool corrupt = is_predefined_tablespace(space_id)
		|| first_page_no != 0 // TODO: multi-file user tablespaces
		|| len < sizeof "/a.ibd\0"
		|| memcmp(ptr + len - 5, DOT_IBD, 5) != 0
		|| memchr(ptr, OS_PATH_SEPARATOR, len) == NULL;

How to repeat:
See above

Suggested fix:
Call os_normalize_path(ptr); after reading the file name from redo log in fil_name_parse() method
[2 Oct 2015 11:35] Daniel Price
Posted by developer:
 
Fixed as of the upcoming 5.7.10, 5.8.0 release, and here's the changelog entry:

On Windows, the server exited during crash recovery when started on a
data directory copied form a non-Windows platform. The failure was due to
a file path separator conversion issue. 

Thank you for the bug report.
[2 Oct 2015 16:56] Daniel Price
The changelog entry was revised as follows:

After a crash on Windows, copying the data directory to a non-Windows
platform to perform the restore caused a crash recovery failure on
startup. The code did not convert file path separators from \ to / in the
redo log.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.039 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.