when prepare --apply-log-only for a incremental backup, xtrabackup print logs:
Apply batch completed!
Apply batch completed!
Using undo tablespace './undo_001'.
Using undo tablespace './undo_001'.
Using undo tablespace './undo_002'.
Using undo tablespace './undo_002'.
Opened 2 existing undo tablespaces.
Opened 2 existing undo tablespaces.
GTID recovery trx_no: 472302919
GTID recovery trx_no: 472302919
InnoDB: Assertion failure: fut0lst.ic:85:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: thread 140144673801984InnoDB: Assertion failure: fut0lst.ic:85:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: thread 140144673801984InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:04:23 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
33394,1 99%
GTID recovery trx_no: 472302919
GTID recovery trx_no: 472302919
InnoDB: Assertion failure: fut0lst.ic:85:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: thread 140144673801984InnoDB: Assertion failure: fut0lst.ic:85:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: thread 140144673801984InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:04:23 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
14:04:23 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x100000
stack_bottom = 0 thread_stack 0x100000
innobackupex(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x238fe0e]
innobackupex(handle_fatal_signal+0x2f3) [0x122bc43]
/lib64/libpthread.so.0() [0x38fe00f710]
/lib64/libc.so.6(gsignal+0x35) [0x38fdc32925]
/lib64/libc.so.6(abort+0x175) [0x38fdc34105]
innobackupex(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0xe8) [0x16bb9b8]
innobackupex(trx_undo_lists_init(trx_rseg_t*)+0xbb0) [0x16bb330]
innobackupex(trx_rseg_init_thread(void*, unsigned long)+0x27f) [0x16a181f]
our operation is:
step 1. do a full backup with xtrabackup8.0.13 for a mysql8.0.20；
step 2. do a incremental backup base on 1;
step 3. do full backup prepare step with option --apply-log-only; use xtrabackup8.0.27
step 4. do a incremental prepare step with option --apply-log-only base on 3;
in step 4, we meet the error.
it just like the undo tablespace file has a stoarge error with
InnoDB: Assertion failure: fut0lst.ic:85:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
log print. and the backtrace from trx_undo_lists_init() function.
But if there any similar bugs cause this error?
Other relation:
we use --close-file options for backup and found some logs in step 3 (fullbackup prepare)like:
Doing recovery: scanned up to log sequence number 49112274327040
Doing recovery: scanned up to log sequence number 49112274327040
Rename failed. Cannot find './dbname/xxx.ibd'!
Delete './dbname/#sql-ib104630-3424801962.ibd' failed!
....
....
Apply batch completed!
Could not find any file associated with the tablespace ID: 102990
Could not find any file associated with the tablespace ID: 103477
Could not find any file associated with the tablespace ID: 102990
Could not find any file associated with the tablespace ID: 103477