[MDEV-13105] InnoDB fails to load a table with PAGE_COMPRESSION_LEVEL after upgrade from 10.1.20 Created: 2017-06-15  Updated: 2017-07-05  Resolved: 2017-07-05

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2
Fix Version/s: 10.1.26, 10.2.7, 10.3.1

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-11623 MariaDB 10.1 fails to start datadir c... Closed
relates to MDEV-13113 Server crashes in fil_load_single_tab... Closed

 Description    

2017-06-16  1:51:01 140690340212800 [Note] InnoDB: Completed initialization of buffer pool
 
2017-06-16  1:51:01 140689607849728 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
 
2017-06-16  1:51:01 140690340212800 [Note] InnoDB: Highest supported file format is Barracuda.
 
2017-06-16  1:51:01 140690340212800 [Note] InnoDB: Upgrading redo log: 2*3072 pages; LSN=1769605
 
2017-06-16  1:51:01 140690340212800 [Note] InnoDB: Starting to delete and rewrite log files.
 
2017-06-16  1:51:01 140690340212800 [Note] InnoDB: Setting log file ./ib_logfile101 size to 48 MB
 
2017-06-16  1:51:02 140690340212800 [Note] InnoDB: Setting log file ./ib_logfile1 size to 48 MB
 
2017-06-16  1:51:03 140690340212800 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
 
2017-06-16  1:51:03 140690340212800 [Note] InnoDB: New log files created, LSN=1769605
 
2017-06-16  1:51:03 140690340212800 [ERROR] InnoDB: Data file './test/t1.ibd' uses page size 65536, but the innodb_page_size start-up parameter is 16384
 
2017-06-16  1:51:03 140690340212800 [ERROR] InnoDB: Operating system error number 2 in a file operation.
 
2017-06-16  1:51:03 140690340212800 [ERROR] InnoDB: The error means the system cannot find the path specified.
 
2017-06-16  1:51:03 140690340212800 [ERROR] InnoDB: If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them.
 
2017-06-16  1:51:03 140690340212800 [ERROR] InnoDB: Could not find a valid tablespace file for `test/t1`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
 
2017-06-16  1:51:03 140690340212800 [Warning] InnoDB: Ignoring tablespace for `test`.`t1` because it could not be opened.
 
2017-06-16  1:51:03 140690340212800 [Note] InnoDB: 128 out of 128 rollback segments are active.
 
2017-06-16  1:51:03 140690340212800 [Note] InnoDB: Creating sys_virtual system tables.

To reproduce:

on 10.1.20 clean server started with all defaults

 
MariaDB [test]> SET GLOBAL innodb_file_format = Barracuda;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [test]> CREATE TABLE `t1` (`pk` BIGINT AUTO_INCREMENT PRIMARY KEY, `i` INT) ENGINE=InnoDB ROW_FORMAT=DYNAMIC PAGE_COMPRESSED=1 PAGE_COMPRESSION_LEVEL=3;
 
Query OK, 0 rows affected (0.67 sec)
 
 
 
MariaDB [test]> INSERT INTO t1 VALUES (NULL,1);
 
Query OK, 1 row affected (0.05 sec)
 
 
 
MariaDB [test]> shutdown;
 
Query OK, 0 rows affected (0.00 sec)

Then start 10.2 on the same datadir, observe errors in the error log and

on 10.2

 
MariaDB [test]> check table t1;
 
+---------+-------+----------+-------------------------------------------+
 
| Table   | Op    | Msg_type | Msg_text                                  |
 
+---------+-------+----------+-------------------------------------------+
 
| test.t1 | check | Warning  | Tablespace is missing for table 'test/t1' |
 
| test.t1 | check | Error    | Table 'test.t1' doesn't exist in engine   |
 
| test.t1 | check | status   | Operation failed                          |
 
+---------+-------+----------+-------------------------------------------+
 
3 rows in set (0.00 sec)

If you don't want to install 10.1.20, you can download the datadir prepared as described above from here:
ftp://ftp.askmonty.org/public/mdev13105_datadir.tar.gz
and start 10.2 on it.

 Comments   
Comment by Marko Mäkelä [ 2017-07-05 ]

The upgrade part of the previous fix MDEV-11623 for the FSP_SPACE_FLAGS incompatibility that was introduced in MariaDB 10.1.0 should be improved.

The problem is that the tablespace flags 0x1e1 appear valid in Datafile::read_first_page(). Why? The function fsp_flags_is_valid() is identical between 10.1 and 10.2.
Let us decompose the flags: 0x1e1 = 0x11 | 7 << 6. The 6 least significant bits (whose interpretation is the same in all MariaDB versions, including the buggy 10.1.0‥10.1.20) are 0x11, indicating ROW_FORMAT=DYNAMIC.

The remaining nonzero bits 7<<6 in the buggy MariaDB 10.1.0‥10.1.20 format indicate PAGE_COMPRESSED=1 PAGE_COMPRESSION_LEVEL=3, as expected.

In MariaDB 10.0 and 10.2, these bits would be interpreted as PAGE_SSIZE=7, indicating innodb_page_size=64k. The validity check for the PAGE_SSIZE was made as strict as possible, only allowing the values 0 (16k), 3 (4k), 4 (8k), 6 (32k), and 7 (64k).

It looks like PAGE_COMPRESSION_LEVEL=2 and PAGE_COMPRESSION_LEVEL=0 (if it is allowed) could create false page size matches as well.

We can make a special case for .ibd files and innodb_page_size=16k. When the PAGE_SSIZE bits are nonzero in this case, assume that the flags are in the buggy MariaDB 10.1.0 format. This should also fix MDEV-13113.

Generated at Thu Feb 08 08:02:56 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.