**Reported in Launchpad by andreiip last update 17-07-2017 08:07:25
mysql Ver 14.14 Distrib 5.6.28-76.1, for debian-linux-gnu (x86_64) using 6.2
xtrabackup version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)
I try prepare percona backup and received:
InnoDB: End of page dump
InnoDB: Uncompressed page, stored checksum in field1 300180583, calculated checksums for field1: crc32 2232620153/2147590501, innodb 300180583, none 3735928559, stored checksum in field2 1565447105, calculated checksums for field2: crc32 2232620153/2147590501, innodb 1565447105, none 3735928559, page LSN 1715 4265470450, low 4 bytes of LSN at page end 4265470450, page number (if stored to page already) 6, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a freshly allocated page
[FATAL] InnoDB: Apparent corruption of an index page [page id: space=0, page number=6] to be written to data file. We intentionally crash the server to prevent corrupt data from ending up in data files.
2017-03-10 14:30:51 0x7f66a5309720 InnoDB: Assertion failure in thread 140078834816800 in file ut0ut.cc line 916
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.
06:30:51 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