xtrabackup 0.8 crashes during prepare after tar4ibd

[Vadim Tkachenko]

   1.
      xtrabackup: cd to DIR
   2.
      xtrabackup: This target seems to be not prepared yet.
   3.
      xtrabackup: Temporary instance for recovery is set as followings.
   4.
      xtrabackup: innodb_data_home_dir = ./
   5.
      xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
   6.
      xtrabackup: innodb_log_group_home_dir = ./
   7.
      xtrabackup: innodb_log_files_in_group = 1
   8.
      xtrabackup: innodb_log_file_size = 120864768
   9.
      xtrabackup: Starting InnoDB instance for recovery.
  10.
      xtrabackup: Using 4294967296 bytes for buffer pool (set by --use-memory parameter)
  11.
      InnoDB: Log scan progressed past the checkpoint lsn 630 884555953
  12.
      090704 7:50:19 InnoDB: Database was not shut down normally!
  13.
      InnoDB: Starting crash recovery.
  14.
      InnoDB: Reading tablespace information from the .ibd files...
  15.
      InnoDB: Doing recovery: scanned up to log sequence number 630 889798656 (4 %)
  16.
      InnoDB: Doing recovery: scanned up to log sequence number 630 895041536 (9 %)
  17.
      InnoDB: Doing recovery: scanned up to log sequence number 630 900284416 (14 %)
  18.
      InnoDB: Doing recovery: scanned up to log sequence number 630 905527296 (19 %)
  19.
      InnoDB: Doing recovery: scanned up to log sequence number 630 910770176 (24 %)
  20.
      InnoDB: Doing recovery: scanned up to log sequence number 630 916013056 (29 %)
  21.
      InnoDB: Doing recovery: scanned up to log sequence number 630 921255936 (34 %)
  22.
      InnoDB: Doing recovery: scanned up to log sequence number 630 926498816 (39 %)
  23.
      InnoDB: Doing recovery: scanned up to log sequence number 630 931741696 (43 %)
  24.
      InnoDB: Doing recovery: scanned up to log sequence number 630 936984576 (48 %)
  25.
      InnoDB: Doing recovery: scanned up to log sequence number 630 942227456 (53 %)
  26.
      InnoDB: Doing recovery: scanned up to log sequence number 630 947470336 (58 %)
  27.
      InnoDB: Doing recovery: scanned up to log sequence number 630 952713216 (63 %)
  28.
      InnoDB: Doing recovery: scanned up to log sequence number 630 957956096 (68 %)
  29.
      InnoDB: Doing recovery: scanned up to log sequence number 630 963198976 (73 %)
  30.
      InnoDB: Doing recovery: scanned up to log sequence number 630 968441856 (78 %)
  31.
      InnoDB: Doing recovery: scanned up to log sequence number 630 973684736 (82 %)
  32.
      InnoDB: Doing recovery: scanned up to log sequence number 630 978927616 (87 %)
  33.
      InnoDB: Doing recovery: scanned up to log sequence number 630 984170496 (92 %)
  34.
      InnoDB: Doing recovery: scanned up to log sequence number 630 989413376 (97 %)
  35.
      InnoDB: Doing recovery: scanned up to log sequence number 630 991988545 (99 %)
  36.
      InnoDB: Page directory corruption: supremum not pointed to
  37.
      090704 7:50:41 InnoDB: Page dump in ascii and hex (16384 bytes):
  38.
       len 16384; hex 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  39.
      ....
  40.
      090704 7:50:41 InnoDB: Page checksum 1575996416, prior-to-4.0.14-form checksum 1371122432
  41.
      InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
  42.
      InnoDB: Page lsn 0 0, low 4 bytes of lsn at page end 0
  43.
      InnoDB: Page number (if stored to page already) 0,
  44.
      InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
  45.
      InnoDB: Page directory corruption: supremum not pointed to
  46.
      090704 7:50:41 InnoDB: Page dump in ascii and hex (16384 bytes):

[Yasufumi Kinoshita (yasufumi-kinoshita)]

The fix should solve the problem.

http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/74

Thank you.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-263