[MDEV-19695] Import tablespace doesn't work with ROW_FORMAT=compressed encrypted tablespace Created: 2019-06-05  Updated: 2020-08-25  Resolved: 2019-06-06

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.15, 10.3.6, 10.4.0
Fix Version/s: 10.2.25, 10.3.16, 10.4.6

Type: Bug Priority: Major
Reporter: Thirunarayanan Balathandayuthapani Assignee: Thirunarayanan Balathandayuthapani
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-12632 Source and destination overlap in mem... Closed

 Description   

The compressed encrypted table doesn't work with import tablespace. The following test case
demonstrated the issue:

CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY, a VARCHAR(255)) ENGINE=InnoDB row_format=compressed encrypted=yes;
insert into t1 values(1, repeat('Nesamani', 10));
select count(*) from t1;
count(*)
1
show create table t1;
Table	Create Table
t1	CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  `a` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED `encrypted`=yes
# Wait max 10 min for key encryption threads to encrypt all spaces
--let $wait_timeout= 600
--let $wait_condition=SELECT COUNT(*) = 0 FROM INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION WHERE MIN_KEY_VERSION = 0 AND ROTATING_OR_FLUSHING <> 0
--source include/wait_condition.inc
 
--source include/shutdown_mysqld.inc
 
--source include/start_mysqld.inc
let MYSQLD_DATADIR =`SELECT @@datadir`;
 
--list_files $MYSQLD_DATADIR/test
FLUSH TABLES t1 FOR EXPORT;
perl;
do "$ENV{MTR_SUITE_DIR}/include/innodb-util.pl";
ib_backup_tablespaces("test", "t1");
EOF
--list_files $MYSQLD_DATADIR/test
UNLOCK TABLES;
 
DROP TABLE t1;
create table t1(id INT NOT NULL PRIMARY KEY, a VARCHAR(255)) ENGINE=InnoDB row_format=compressed encrypted=yes;
 
alter table t1 discard tablespace;
perl;
do "$ENV{MTR_SUITE_DIR}/include/innodb-util.pl";
ib_discard_tablespaces("test", "t1");
ib_restore_tablespaces("test", "t1");
EOF
 
ALTER TABLE t1 IMPORT TABLESPACE;

It fails with the following error:

failed: 1296: Got error 39 'Data structure corruption' from ./test/t1.ibd
2019-06-05 13:35:01 139993520764672 [Note] InnoDB: Importing tablespace for table 'test/t1' that was exported from host 'thiru-Lenovo-Y520-15IKBN'
2019-06-05 13:35:01 139993520764672 [Note] InnoDB: Phase I - Update all pages
2019-06-05 13:35:01 139993520764672 [Note] InnoDB: Sync to disk
2019-06-05 13:35:01 139993520764672 [Note] InnoDB: Sync to disk - done!
2019-06-05 13:35:01 139993520764672 [ERROR] InnoDB: Refusing to load './test/t1.ibd' (id=4, flags=0x29); dictionary contains id=5, flags=0x29
2019-06-05 13:35:01 139993520764672 [ERROR] InnoDB: Operating system error number 2 in a file operation.
2019-06-05 13:35:01 139993520764672 [ERROR] InnoDB: The error means the system cannot find the path specified.
2019-06-05 13:35:01 139993520764672 [ERROR] InnoDB: Could not find a valid tablespace file for `test/t1`. Please refer to https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue.
2019-06-05 13:35:01 139993520764672 [Note] InnoDB: Discarding tablespace of table `test`.`t1`: Data structure corruption
2019-06-05 13:35:01 139993520764672 [ERROR] mysqld: Index for table 't1' is corrupt; try to repair it

I think the problem is that fil_iterate() does write old space id to 0th page during import.
I suspect the following optimization in fil_iterate() :

                        /* When tablespace is encrypted or compressed its
                        first page (i.e. page 0) is not encrypted or
                        compressed and there is no need to copy frame. */
                        if (encrypted && block->page.id.page_no() != 0) {
                                byte *local_frame = callback.get_frame(block);
                                ut_ad((writeptr + (i * size)) != local_frame);
                                memcpy((writeptr + (i * size)), local_frame, size);
                        }



 Comments   
Comment by Thirunarayanan Balathandayuthapani [ 2019-06-06 ]

It is a regression of MDEV-12632. So it should be in 10.1 too. But in 10.1 has the different problem.
It doesn't even detect the page->zip.data is not null. So I will debug the problem in 10.1 and put as a different patch. 10.2 patch is present in bb-10.2-MDEV-19695

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