page dump, page corruption during prepare

  • Filter
  • Time
  • Show
Clear All
new posts

  • page dump, page corruption during prepare

    When I try to run prepare (I've tried with an new backup twice) on a backup made on Ubuntu 9.10 and run prepare on 10.04, I get the following error (does anyone know what this is?):

    root@client:~# xtrabackup --prepare --use-memory=24G --target-dir=/mysql/2011-02-18_05-54-38
    xtrabackup Ver 1.5 Rev 203 for 5.1.53 unknown-linux-gnu (x86_64)
    xtrabackup: cd to /mysql/2011-02-18_05-54-38
    xtrabackup: This target seems to be not prepared yet.
    110222 3:42:11 InnoDB: Operating system error number 2 in a file operation.
    InnoDB: The error means the system cannot find the path specified.
    xtrabackup: Warning: cannot open ./xtrabackup_logfile. will try to find.
    xtrabackup: 'ib_logfile0' seems to be 'xtrabackup_logfile'. will retry.
    xtrabackup: xtrabackup_logfile detected: size=3418193920, start_lsn=(1588924650071)
    xtrabackup: Temporary instance for recovery is set as followings.
    xtrabackup: innodb_data_home_dir = ./
    xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
    xtrabackup: innodb_log_group_home_dir = ./
    xtrabackup: innodb_log_files_in_group = 1
    xtrabackup: innodb_log_file_size = 3418193920
    xtrabackup: Starting InnoDB instance for recovery.
    xtrabackup: Using 25769803776 bytes for buffer pool (set by --use-memory parameter)
    InnoDB: The InnoDB memory heap is disabled
    InnoDB: Mutexes and rw_locks use GCC atomic builtins
    InnoDB: Compressed tables use zlib 1.2.3
    InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
    InnoDB: Database page corruption on disk or a failed
    InnoDB: file read of page 5.
    InnoDB: You may have to recover from a backup.
    110222 3:42:12 InnoDB: Page dump in ascii and hex (16384 bytes):
    len 16384; hex 26b54d6100000005000000000000000000000171f49bb68d00 0000000000 0000000000000000000000002e776200000000000000000200 f200000000 0000000600000000ffffffff

    P[ pK ;
    InnoDB: End of page dump
    110222 3:42:12 InnoDB: Page checksum 2533584674 (32bit_calc: 649416033), prior-to-4.0.14-form checksum 2591050710
    InnoDB: stored checksum 649416033, prior-to-4.0.14-form stored checksum 2591050710
    InnoDB: Page lsn 369 4103845517, low 4 bytes of lsn at page end 4103845517
    InnoDB: Page number (if stored to page already) 5,
    InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
    InnoDB: Page may be a freshly allocated page
    InnoDB: Database page corruption on disk or a failed
    InnoDB: file read of page 5.
    InnoDB: You may have to recover from a backup.
    InnoDB: It is also possible that your operating
    InnoDB: system has corrupted its own file cache
    InnoDB: and rebooting your computer removes the
    InnoDB: error.
    InnoDB: If the corrupt page is an index page
    InnoDB: you can also try to fix the corruption
    InnoDB: by dumping, dropping, and reimporting
    InnoDB: the corrupt table. You can use CHECK
    InnoDB: TABLE to scan your table for corruption.
    InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
    InnoDB: about forcing recovery.
    InnoDB: Ending processing because of a corrupt database page.

  • #2

    It turns out that the issue is that if the backup is made on a server with "innodb_fast_checksum=1" turned on, you will get this error if you try to use a restored (prepared) backup on a box NOT using innodb_fast_checksum. This also includes using the generated backup file "backup-my.cnf", which even if you make a backup on a server using fast checksum, this file will NOT have innodb_fast_checksum specified and starting MySQL with this file will result in the failure I had.


    • #3
      That's a really good catch, thanks for figuring out this problem. I will file a bug report.