Comment 8 for bug 839306

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
>