Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
N/A
-
None
Description
--source include/have_innodb.inc
|
|
INSTALL SONAME 'provider_lzo'; |
SET GLOBAL innodb_compression_algorithm= lzo; |
CREATE TABLE t (a INT) ENGINE=InnoDB page_compressed=1; |
INSERT INTO t VALUES (1),(2); |
--source include/restart_mysqld.inc
|
|
--exec grep -i "failed to read" $MYSQLTEST_VARDIR/log/mysqld.1.err
|
SELECT * FROM t; |
|
DROP TABLE t; |
In the test case above, upon restart InnoDB writes "failed to read" error messages into the log:
2021-10-10 1:50:25 0 [ERROR] InnoDB: Background Page read failed to read or decrypt [page id: space=5, page number=1]
|
2021-10-10 1:50:25 0 [ERROR] InnoDB: Failed to read page 2 from file './test/t.ibd': Table is encrypted but decrypt failed.
|
2021-10-10 1:50:25 0 [ERROR] InnoDB: Failed to read page 3 from file './test/t.ibd': Table is encrypted but decrypt failed.
|
However, the table is readable.
The effect is not necessarily limited to MTR. These are the elements of the use case which I couldn't get rid of while reproducing outside MTR:
- server had to be bootstrapped without InnoDB;
- server had to be run with performance schema;
- provider had to be installed into mysql.plugin rather than loaded via a startup option.
I'm not sure how important each factor is, possibly they just cause a "lucky" timing or sequence of events upon startup. But this way it happens to me nearly deterministically. In rare cases only the first error message is written.
The specific provider is not important.
Attachments
Issue Links
- is caused by
-
MDEV-12933 sort out the compression library chaos
- Closed
-
MDEV-26800 mysql.plugin violates plugin_type_initialization_order
- Open