Activity log for bug #1671722

Date Who What changed Old value New value Message
2017-03-10 07:21:43 andreiip bug added bug
2017-03-10 09:35:58 andreiip information type Public Private Security
2017-03-10 09:37:24 andreiip description Hello everybody. 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: xtrabackupreparepare --target-dir=/backups/mysqlbackups ........................................................................ 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: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html 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 terribly wrong... Hello everybody. 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: xtrabackupreparepare --target-dir=/backups/mysqlbackups ........................................................................ 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: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html 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 terribly wrong...
2017-06-30 05:14:14 Sergei Glushchenko summary I can't prepare percona 6th page isn't initialized
2017-06-30 05:14:33 Sergei Glushchenko information type Private Security Public
2017-06-30 05:15:13 Sergei Glushchenko nominated for series percona-xtrabackup/2.4
2017-06-30 05:15:13 Sergei Glushchenko bug task added percona-xtrabackup/2.4
2017-06-30 05:15:18 Sergei Glushchenko percona-xtrabackup/2.4: status New Fix Released
2017-06-30 05:15:21 Sergei Glushchenko percona-xtrabackup/2.4: importance Undecided High
2017-06-30 05:15:24 Sergei Glushchenko percona-xtrabackup/2.4: assignee Sergei Glushchenko (sergei.glushchenko)
2017-06-30 05:15:28 Sergei Glushchenko percona-xtrabackup/2.4: milestone future-2.4-releases
2017-07-17 08:07:24 Sergei Glushchenko percona-xtrabackup/2.4: milestone future-2.4-releases 2.4.8