MDEV-18129 Backup fails for encrypted tables: mariabackup: Database page...
MDEV-18129 Backup fails for encrypted tables: mariabackup: Database page corruption detected at page 1 If an encrypted table is created during backup, then mariabackup --backup could wrongly fail. This caused a failure of the test mariabackup.huge_lsn once on buildbot. This is due to the way how InnoDB creates .ibd files. It would first write a dummy page 0 with no encryption information. Due to this, xb_fil_cur_open() could wrongly interpret that the table is not encrypted. Subsequently, page_is_corrupted() would compare the computed page checksum to the wrong checksum. (There are both "before" and "after" checksums for encrypted pages.) To work around this problem, we introduce a Boolean option --backup-encrypted that is enabled by default. With this option, Mariabackup will assume that a nonzero key_version implies that the page is encrypted. We need this option in order to be able to copy encrypted tables from MariaDB 10.1 or 10.2, because unencrypted pages that were originally created before MySQL 5.1.48 could contain nonzero garbage in the fields that were repurposed for encryption. Later, MDEV-18128 would clean up the way how .ibd files are created, to remove the need for this option. page_is_corrupted(): Add missing const qualifiers, and do not check space->crypt_data unless --skip-backup-encrypted has been specified. xb_fil_cur_read(): After a failed page read, output a page dump.
Showing
Please register or sign in to comment