I think the root cause here is that xb_data_files_init() (i.e. loading tablespaces into fil_system) is performed before log copying is started.
Consider the following scenario:
When the full backup is started:
- the server starts to execute CREATE/ALTER TABLE
- xb_data_files_init() is called from xtrabackup_backup_func()
- if the file for the newly created tablespace already exists (i.e. is seen by fil_load_single_tablespaces()), but the first page has not been initialized/flushed yet, xtrabackup complains about tablespace ID being nonsensical and omits the table from the full backup
- the server writes MLOG_FILE_CREATE (and possibly other records corresponding to that tablespace) to the log and performs a checkpoint
- xtrabackup starts copying the log later in xtrabackup_backup_func(), so it will not write MLOG_FILE_CREATE to xtrabackup_logfile
When the incremental backup is started:
- if the corresponding page updates in the tablespace have not been flushed yet, we generate an empty delta for it
- and copy the corresponding updates to the incremental log file
When the full backup is prepared:
- we ignore all possible log records corresponding to the tablespace, because it doesn't exist (and there's no MLOG_FILE_CREATE in the log, so it is not created on prepare)
When the incremental backup is applied:
- xb_delta_open_matching_space() creates a new tablespace assuming the table was created between the full and incremental backups
- xtrabackup then starts to apply log records to uninitialized pages
I think the root cause here is that xb_data_ files_init( ) (i.e. loading tablespaces into fil_system) is performed before log copying is started.
Consider the following scenario:
When the full backup is started:
- the server starts to execute CREATE/ALTER TABLE files_init( ) is called from xtrabackup_ backup_ func() single_ tablespaces( )), but the first page has not been initialized/flushed yet, xtrabackup complains about tablespace ID being nonsensical and omits the table from the full backup backup_ func(), so it will not write MLOG_FILE_CREATE to xtrabackup_logfile
- xb_data_
- if the file for the newly created tablespace already exists (i.e. is seen by fil_load_
- the server writes MLOG_FILE_CREATE (and possibly other records corresponding to that tablespace) to the log and performs a checkpoint
- xtrabackup starts copying the log later in xtrabackup_
When the incremental backup is started:
- if the corresponding page updates in the tablespace have not been flushed yet, we generate an empty delta for it
- and copy the corresponding updates to the incremental log file
When the full backup is prepared:
- we ignore all possible log records corresponding to the tablespace, because it doesn't exist (and there's no MLOG_FILE_CREATE in the log, so it is not created on prepare)
When the incremental backup is applied:
- xb_delta_ open_matching_ space() creates a new tablespace assuming the table was created between the full and incremental backups
- xtrabackup then starts to apply log records to uninitialized pages