xtrabackup 0.8 crashes during prepare after tar4ibd

Reported by Vadim Tkachenko on 2009-07-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup
High
Unassigned

Bug Description

   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):

Related branches

Changed in percona-xtrabackup:
assignee: nobody → Yasufumi Kinoshita (yasufumi-kinoshita)
importance: Undecided → High
status: New → Fix Committed
Changed in percona-xtrabackup:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers