[MDEV-25507] CHECK on encrypted Aria table complains about "Wrong LSN" Created: 2021-04-24  Updated: 2021-05-01  Resolved: 2021-05-01

Status: Closed
Project: MariaDB Server
Component/s: Encryption, Storage Engine - Aria
Affects Version/s: 10.5, 10.6
Fix Version/s: 10.5.10

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-17913 Encrypted transactional Aria tables r... Closed

 Description   

Note:
I've set affected version tentatively to 10.5-10.6, because the problem is visible there. But the diagnostic was only added in the 10.5 part of MDEV-17913. So, it can be a false positive in 10.5 if CHECK reports a non-existing issue, or it can be a real problem which is not visible in 10.4 due to the absence of diagnostics (or, of course it can also be a 10.5-only issue).

--source suite/encryption/include/have_file_key_management_plugin.inc
 
SET @aria_encrypt= @@aria_encrypt_tables;
SET GLOBAL aria_encrypt_tables= 1;
 
CREATE TABLE t1 (f DATE PRIMARY KEY) ENGINE=Aria;
INSERT INTO t1 (f) VALUES ('1995-01-01'),('2000-01-01');
DELETE FROM t1 WHERE f = '2000-01-01';
OPTIMIZE TABLE t1;
CHECK TABLE t1 EXTENDED;
 
# Cleanup
DROP TABLE t1;
SET GLOBAL aria_encrypt_tables= @aria_encrypt;

10.5 b8fad8c6

CHECK TABLE t1 EXTENDED;
Table	Op	Msg_type	Msg_text
test.t1	check	error	Page 1:  Wrong LSN (3885152,0x70806be8). Current LSN is (1,0x9574)
test.t1	check	error	Table is probably from another system and must be zerofilled or repaired ('REPAIR TABLE table_name') to be usable on this system
test.t1	check	error	Corrupt

The printout was added by this commit:

commit 81258f14323e1d1ad0203bae93bc55a30d47c1b3
Author: Monty
Date:   Fri Apr 2 22:00:36 2021 +0300
 
    MDEV-17913 Encrypted transactional Aria tables remain corrupt after crash recovery, automatic repairment does not work



 Comments   
Comment by Michael Widenius [ 2021-04-30 ]

This happens because during repair we create a temporary table opened
with HA_OPEN_COPY, which reset 'share->born_transactional', which
the encryption code did not like.

Fixed by resetting just share->now_transactional.

Comment by Michael Widenius [ 2021-05-01 ]

Rerunning tests, trying to figure out why galera & rpl.rpl_semi_sync_slave_compressed_protocol fails

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