mariadb/extra/mariabackup
Vlad Lesin 985ede9203 MDEV-20755 InnoDB: Database page corruption on disk or a failed file read of tablespace upon prepare of mariabackup incremental backup
The problem:

When incremental backup is taken, delta files are created for innodb tables
which are marked as new tables during innodb ddl tracking. When such
tablespace is tried to be opened during prepare in
xb_delta_open_matching_space(), it is "created", i.e.
xb_space_create_file() is invoked, instead of opening, even if
a tablespace with the same name exists in the base backup directory.

xb_space_create_file() writes page 0 header the tablespace.
This header does not contain crypt data, as mariabackup does not have
any information about crypt data in delta file metadata for
tablespaces.

After delta file is applied, recovery process is started. As the
sequence of recovery for different pages is not defined, there can be
the situation when crypt data redo log event is executed after some
other page is read for recovery. When some page is read for recovery, it's
decrypted using crypt data stored in tablespace header in page 0, if
there is no crypt data, the page is not decryped and does not pass corruption
test.

This causes error for incremental backup --prepare for encrypted
tablespaces.

The error is not stable because crypt data redo log event updates crypt
data on page 0, and recovery for different pages can be executed in
undefined order.

The fix:

When delta file is created, the corresponding write filter copies only
the pages which LSN is greater then some incremental LSN. When new file
is created during incremental backup, the LSN of all it's pages must be
greater then incremental LSN, so there is no need to create delta for
such table, we can just copy it completely.

The fix is to copy the whole file which was tracked during incremental backup
with innodb ddl tracker, and copy it to base directory during --prepare
instead of delta applying.

There is also DBUG_EXECUTE_IF() in innodb code to avoid writing redo log
record for crypt data updating on page 0 to make the test case stable.

Note:

The issue is not reproducible in 10.5 as optimized DDL's are deprecated
in 10.5. But the fix is still useful because it allows to decrease
data copy size during backup, as delta file contains some extra info.
The test case should be removed for 10.5 as it will always pass.
2020-10-23 11:02:25 +03:00
..
crc Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
quicklz MDEV-9566 Add Percona Xtrabackup 2.3.7 2017-04-27 19:12:39 +02:00
backup_copy.cc Fix GCC 10.2.0 -Og -Wmaybe-uninitialized 2020-08-11 15:58:16 +03:00
backup_copy.h MDEV-13575 On failure, Mariabackup --backup --safe-slave-backup may forget to START SLAVE SQL_THREAD 2017-08-18 21:42:33 +03:00
backup_mysql.cc MDEV-19264 Better support MariaDB GTID for Mariabackup's --slave-info option 2020-09-14 11:14:50 +03:00
backup_mysql.h MDEV-18438 Don't stream xtrabackup_info of extra-lsndir 2019-09-19 17:47:54 +03:00
backup_wsrep.h Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
changed_page_bitmap.cc Merge 10.1 to 10.2 2019-11-06 10:18:51 +02:00
changed_page_bitmap.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
CMakeLists.txt Merge branch '10.1' into 10.2 2020-01-24 13:46:49 +01:00
common.h Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
datasink.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
datasink.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
ds_archive.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
ds_archive.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
ds_buffer.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
ds_buffer.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
ds_compress.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
ds_compress.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
ds_local.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
ds_local.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
ds_stdout.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
ds_stdout.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
ds_tmpfile.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
ds_tmpfile.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
ds_xbstream.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
ds_xbstream.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
encryption_plugin.cc Merge 10.1 into 10.2 2019-03-06 15:15:59 +02:00
encryption_plugin.h MDEV-9566 Port Percona Xtrabackup to MariaDB as mariabackup 2017-04-27 19:12:40 +02:00
fil_cur.cc MDEV-19335 Remove buf_page_t::encrypted 2019-10-09 13:13:12 +03:00
fil_cur.h Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
innobackupex.cc Merge branch '10.1' into 10.2 2020-01-24 13:46:49 +01:00
innobackupex.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
read_filt.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
read_filt.h Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
write_filt.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
write_filt.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
wsrep.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
xb0xb.h Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
xb_regex.h Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
xbcloud.cc Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
xbstream.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
xbstream.h Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
xbstream_read.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
xbstream_write.cc Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
xtrabackup.cc MDEV-20755 InnoDB: Database page corruption on disk or a failed file read of tablespace upon prepare of mariabackup incremental backup 2020-10-23 11:02:25 +03:00
xtrabackup.h MDEV-19347: Mariabackup does not honor ignore_db_dirs from server 2020-04-21 10:34:37 +03:00