Hi Alexey,

Thank you for the update.

Best wishes,
Bob Gu

2011/11/25 Alexey Kopytov <email address hidden>

> Hi Bob,
>
> Thanks for clarifications. So the actual problem was that xtrabackup was
> using an incorrect InnoDB data files configuration.
>
> When innobackupex is used to create backups, the server's
> innodb_data_file_path value is written to backup-my.cnf, but that file
> is not automatically used at prepare, it has to be specified explicitly
> via --defaults-file. And when innobackupex is not used, we simply don't
> have any information about data files configuration at prepare. Which
> causes  problems like the one in this bug when there are multiple data
> files configured with innodb_data_file_path.
>
> There is a blueprint targeting this specific problem:
> https://blueprints.launchpad.net/percona-xtrabackup/+spec/backup-config-
> in-xtrabackup
>
> Until that BP is implemented, the workaround is to either use
> --defaults-file=backup-my.cnf (if that file is available), or specify
> innodb_data_file_path on the xtrabackup command line explicitly (when
> backup was taken without innobackupex) using the same value as it was on
> the server where the backup was taken.
>
> ** Changed in: percona-xtrabackup
>       Status: Incomplete => Confirmed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/839306
>
> Title:
>  Failing assertion: addr.page == FIL_NULL || addr.boffset >=
>  FIL_PAGE_DATA
>
> Status in Percona XtraBackup:
>   Confirmed
>
> Bug description:
>  When runing the prepare command line, it will ran into a "Failing
> assertion".
>  $  ~/local/bin/xtrabackup_55 --prepare --target-dir=`pwd` --tmpdir=/tmp
>  /export/home/mysql/local/bin/xtrabackup_55  Ver 1.6 Rev undefined for
> 5.5.9 Linux (x86_64)
>  xtrabackup: cd to /data/backup/full/2011-09-01_06-27-55
>  xtrabackup: This target seems to be not prepared yet.
>  110901 22:58:41  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=6089359360,
> start_lsn=(1336207695220)
>  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 = 6089359360
>  110901 22:58:42 InnoDB: Using Linux native AIO
>  xtrabackup: Starting InnoDB instance for recovery.
>  xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory
> parameter)
>  110901 22:58:42 InnoDB: The InnoDB memory heap is disabled
>  110901 22:58:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
>  110901 22:58:42 InnoDB: Compressed tables use zlib 1.2.3
>  110901 22:58:42 InnoDB: Using Linux native AIO
>  110901 22:58:42 InnoDB: Warning: innodb_file_io_threads is deprecated.
> Please use innodb_read_io_threads and innodb_write_io_threads instead
>  110901 22:58:42 InnoDB: Initializing buffer pool, size = 100.0M
>  110901 22:58:42 InnoDB: Completed initialization of buffer pool
>  110901 22:58:42 InnoDB: highest supported file format is Barracuda.
>  InnoDB: Log scan progressed past the checkpoint lsn 1336207695220
>  110901 22:58:42  InnoDB: Database was not shut down normally!
>  InnoDB: Starting crash recovery.
>  InnoDB: Reading tablespace information from the .ibd files...
>  InnoDB: Doing recovery: scanned up to log sequence number 1336212937728
> (0 %)
>  InnoDB: Doing recovery: scanned up to log sequence number 1336218180608
> (0 %)
>  InnoDB: Doing recovery: scanned up to log sequence number 1336223423488
> (0 %)
>  InnoDB: Doing recovery: scanned up to log sequence number 1336228666368
> (0 %)
>  InnoDB: Doing recovery: scanned up to log sequence number 1336233909248
> (0 %)
>  InnoDB: Doing recovery: scanned up to log sequence number 1336234756658
> (0 %)
>  110901 22:58:52  InnoDB: Assertion failure in thread 47344695498128 in
> file
> /home/buildbot/slaves/percona-server-51-12/TGZ_CentOS_5_x86_64/work/xtrabackup-1.6/Percona-Server-5.5/storage/innobase/include/fut0lst.ic
> line 83
>  InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >=
> FIL_PAGE_DATA
>  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.5/en/forcing-innodb-recovery.html
>  InnoDB: about forcing recovery.
>  Aborted
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/percona-xtrabackup/+bug/839306/+subscriptions
>