[MDEV-26762] Compressed table remains accessible without provider after unclean restart Created: 2021-10-04  Updated: 2021-10-09  Resolved: 2021-10-09

Status: Closed
Project: MariaDB Server
Component/s: Plugins, Storage Engine - InnoDB
Affects Version/s: N/A
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-12933 sort out the compression library chaos Closed
Relates
relates to MDEV-26773 MariaBackup backup does not work with... Closed

 Description   

It isn't clear yet whether this can cause a real problem, but it appears somewhat unexpected and vaguely disturbing in the context of provider plugins, so I think at least it is worth thinking what possible side effects it may have.

The test case is derived from plugins.compression, with only important difference that it sets shutdown_timeout to zero, thus disallowing the server to shut down normally.

Then, even though after the server is restarted without the provider at all, SELECT from the compressed table succeeds instead of failing with ER_NO_SUCH_TABLE_IN_ENGINE.

--source include/have_innodb.inc
 
 
 
let $restart_parameters = --plugin-load-add=provider_snappy;
 
source include/restart_mysqld.inc;
 
 
 
set global innodb_compression_algorithm = snappy;
 
create table t1 (a int, b text) engine=InnoDB page_compressed=1;
 
 
 
insert t1 (a, b) values (0, repeat("abc", 100));
 
 
 
let $restart_parameters =;
 
--let $shutdown_timeout= 0
 
source include/restart_mysqld.inc;
 
 
 
#error ER_NO_SUCH_TABLE_IN_ENGINE;
 
select a, left(b, 9), length(b) from t1;
 
 
 
drop table t1;

preview-10.7-MDEV-12933-provider-plugins 67a8fca9b

 
# restart
 
select a, left(b, 9), length(b) from t1;
 
a	left(b, 9)	length(b)
 
0	abcabcabc	300
 
drop table t1;
 
bug.t 'innodb'                           [ pass ]   2017
 
***Warnings generated in error logs during shutdown after running tests: bug.t
 
 
 
2021-10-04 21:46:14 0 [Warning] InnoDB: Page compression errors: 3

The warning on shutdown also hints that something has gone not quite as expected.

 Comments   
Comment by Elena Stepanova [ 2021-10-04 ]

I have no objections against demoting it and removing it from 10.7 RC scope once it has been looked at.

Comment by Sergei Golubchik [ 2021-10-08 ]

Likely it's the same thing that caused mariabackup tests to pass without mariabackup actually supporting compression (MDEV-26773). Perhaps fresh table data are read from the uncompressed log before they're written to a compressed table space.

I don't see what can we do about it

Comment by Marko Mäkelä [ 2021-10-08 ]

Crash recovery must read the first page of any .ibd file that is referred to by the redo log. At that point, if the file is in the innodb_checksum_algorithm=full_crc32 format, we will know the compression algorithm. If the compression library is not available, we can (and in my opinion should) refuse to start up the server unless innodb_force_recovery has been set to a nonzero value.

Comment by Sergei Golubchik [ 2021-10-08 ]

I don't think it even needs to be fixed, if InnoDB reads uncompressed pages from the redo log — well good for them, why should we introduce artificial limitations and prevent it from doing that?

Comment by Sergei Golubchik [ 2021-10-08 ]

on a related matter, we can do a warning on purge, to make the user aware that some pages are lost.

Comment by Marko Mäkelä [ 2021-10-08 ]

I do not think that it is easy to issue a meaningful warning for tables that are unaccessible to purge. We cannot add a table to cache if we cannot load the tablespace. If we do not cache the table, how can we avoid issuing umpteen warnings, one per to-be-purged undo log record?

It is not ‘some pages are lost’ but ‘some history was not purged‘. That is, some garbage may remain in the table, should the table be made available at some later point. The situation could be rectified by executing OPTIMIZE TABLE or ALTER TABLE…FORCE. It is only a matter of failing to reclaim some space, or failing to reset transaction identifiers (MDEV-12288). Purging undo log records without cleaning up the index pages should not affect correctness, only performance.

Comment by Sergei Golubchik [ 2021-10-09 ]

It's not a bug that InnoDB can read some pages of the compressed table even if the compression isn't available. Recently modified pages reside in the uncompressed redo log, it's normal that that are accessible even if compression is disabled.

Generated at Thu Feb 08 09:47:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.