Andrii Nikitin (Inactive) added a comment - 2017-10-28 00:39 added 10.2 to version list, still relevant in current 10.1

Thirunarayanan Balathandayuthapani added a comment - 2018-12-13 13:04 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.

Thirunarayanan Balathandayuthapani added a comment - 2018-12-14 09:11 Patch is in bb-10.2-23578

Marko Mäkelä added a comment - 2018-12-14 14:25 I cleaned up thiru ’s fix, backported to 10.1 and merged all the way up to 10.4.

Marko Mäkelä added a comment - 2018-12-17 18:19 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 .

Marko Mäkelä added a comment - 2018-12-19 14:10 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.