InnoDB: Assertion failure in thread <n> in file log0recv.cc line 2008
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Expired
|
Undecided
|
Unassigned |
Bug Description
https:/
https:/
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: !page || (ibool)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://
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://
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
terribly wrong...
stack_bottom = 0 thread_stack 0x10000
innobackupex(
innobackupex(
/lib/x86_
/lib/x86_
/lib/x86_
innobackupex[
innobackupex[
innobackupex(
innobackupex(
innobackupex(
innobackupex(
/lib/x86_
/lib/x86_
Please report a bug at https:/
---------------
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-
---------------
backup-my.cnf
[mysqld]
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_
innodb_
server_id=167772931
redo_log_version=1
---------------
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)
summary: |
- Assertion failure in log0recv.cc during apply-log + InnoDB: Assertion failure in thread <n> in file log0recv.cc line 2008 |
Ceri,
Have you been able to reproduce it?