Comment 6 for bug 839306

Hi Alexey,

Actually, there were two seperate problems.
1. xtrabackup cannot read the parameter values from my.cnf correcty for
either pass while preparing. By providing the parameter value on the
command line, the problem can be workaround. However, not all parameters
are supported by the command line.
2. In our case, there was something corrupted in ibdata1. According to our
test, the datafile corrupted before the backup was taken. (The source
database failed to be started after a clean shutdown.) In order to fix the
problem, we had to dump all data and rebuilt the whole database. After
that, xtrabackup works as expected.

Best wishes,
Bob Gu

2011/10/21 Alexey Kopytov <email address hidden>

> That's expected behavior. On the first pass XtraBackup wants to replay
> the backup log, so it modifies log files configuration to match
> xtrabackup_logfile parameters. The second pass is used to pre-create
> InnoDB log files, so it uses real values read from configuration file.
>
> So I'm not sure what specific problem we are chasing here. You mentioned
> that xtrabackup failed to get the correct innodb_data_file_path value
> from my.cnf. So does the crash occur with xtrabackup is doing recovery
> with a wrong value?
>
> Can you paste the output of "xtrabackup_55 --print-param"? Does
> specifying --innodb-data-file-path explictly on the xtrabackup command
> line solve the problem?
>
> --
> 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:
> Incomplete
>
> 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
>