added 10.2 to version list, still relevant in current 10.1

The following test case repeats the reported scenario:

--source include/have_file_key_management.inc

CREATE TABLE t1(c VARCHAR(128)) ENGINE INNODB, encrypted=yes;

insert into t1 select repeat('a',100);

let $MYSQLD_DATADIR=`select @@datadir`;

let t1_IBD = $MYSQLD_DATADIR/test/t1.ibd;

--source include/shutdown_mysqld.inc

--echo # Corrupt the table

perl;

use strict;

use warnings;

use Fcntl qw(:DEFAULT :seek);

my $ibd_file = $ENV{'t1_IBD'};

my $chunk;

my $len;

sysopen IBD_FILE, $ibd_file, O_RDWR || die "Unable to open $ibd_file";

sysseek IBD_FILE, 16384 * 3, SEEK_CUR;

$chunk = '\xAA\xAA\xAA\xAA';

syswrite IBD_FILE, $chunk, 4;

close IBD_FILE;

EOF

#--exec $INNOCHECKSUM $MYSQLD_DATADIR/test/t1.ibd

--source include/start_mysqld.inc

echo # xtrabackup backup;

let $targetdir=$MYSQLTEST_VARDIR/tmp/backup;

let $backuplog=$MYSQLTEST_VARDIR/tmp/backup.log;

--disable_result_log

exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir > $backuplog;

--enable_result_log

Problem is that mariabackup always read the encrypted pages and checks the post-encryption checksum only and copies the page even though
the above case corrupted the pre-encryption checksum.

Patch is in bb-10.2-23578

I cleaned up thiru’s fix, backported to 10.1 and merged all the way up to 10.4.

Based on more work from thiru, I pushed a follow-up fix to 10.1.

It turns out that page_compressed=1 pages are not being checked for consistency. That was filed as MDEV-18025.

As part of a follow-up fix to MDEV-18025, I improved the test case so that it computes a valid checksum for the ‘encrypted’ page and writes it to all 3 locations. That is, by the old rules, this page would look like a valid encrypted page as well as a valid unencrypted page. Only by decrypting and checking the ‘before-encryption’ checksum we will detect the page as corrupted.

This test (and the extra decrypt step in mariabackup --backup) was motivated by a support case where a seemingly corrupted page has the same checksum in all 3 locations.

For page_compressed=1 pages (encrypted or not), the only way to validate the page checksum is to attempt to (optionally decrypt and) decompress the data and to compute the checksum.