Affects Version/s: None
Fix Version/s: None
**Reported in Launchpad by Ceri WIlliams last update 11-06-2017 04:17:25
2 similar bugs (based on the assertion error) exist but refer to incremental backups. They also relate to earlier versions.
The following was seen whilst preparing a backup:
2017-03-27 04:32:41 0x7f1e406f4700 InnoDB: Assertion failure in thread 139767906780928 in file log0recv.cc line 2008
InnoDB: Failing assertion: Unable to render embedded object: File (page ) not found.!page_is_comp(page) == dict_table_is_comp(index->table)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: about forcing recovery.
11:32:41 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
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
stack_bottom = 0 thread_stack 0x10000
Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
This backup was restored on 3 other machines without an issue and was successful on the same machine on the second run.
PS 5.7.17 - 2.4.6-2.xenial (both are the same version as the source server)
innobackupex --defaults-file=./backup-my.cnf --use-memory=20G --apply-log ./
Unfortunately the full output was not captured at the time.
The only known difference was that the first decompress happened with an earlier version of innobackupex (2.3.7-2.xenial)