Hello,
I want to do incremental backups of a partial backup containing only one of the MySQL’s database. I have the innodb_file_per_table setting enabled.
In [URL=“http://www.percona.com/doc/percona-xtrabackup/1.6/innobackupex/importing_exporting_tables_ibk.html”]http://www.percona.com/doc/percona-x...ables_ibk.html[/URL] is written that to prepare the backup for the restore, you must run:
$ innobackupex --apply-log --export /path/to/backup
I am assuming that this is done after applying the log of all the incremental backups. It is in this first step when I get the failure. I use the following command but I have also tested it without the --redo-only and without both ‘–redo-only’ and --export’.
[INDENT]innobackupex --user root --password 8n8UZIih --apply-log --redo-only --export /tmp/bp/2013-05-27T18-46-15.d/full
[/INDENT]
The full output of the command is:
[INDENT]xtrabackup_55 version 2.1.3 for Percona Server 5.5.16 Linux (i686) (revision id: 608)
xtrabackup: auto-enabling --innodb-file-per-table due to the --export option
xtrabackup: cd to /tmp/bp/2013-05-27T18-46-15.d/2013-05-27_20-46-15
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2359296, start_lsn=(2113775)
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 = -4643641983856541696
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 = -4643641983856541696
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
130510 17:13:09 InnoDB: The InnoDB memory heap is disabled
130510 17:13:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130510 17:13:09 InnoDB: Compressed tables use zlib 1.2.3
130510 17:13:09 InnoDB: Initializing buffer pool, size = 100.0M
130510 17:13:09 InnoDB: Completed initialization of buffer pool
130510 17:13:09 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130510 17:13:09 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files…
130510 17:13:10 InnoDB: Assertion failure in thread 3074922176 in file fsp0fsp.c line 2949
InnoDB: Failing assertion: space != 0
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: [url]http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html[/url]
InnoDB: about forcing recovery.
Aborted
innobackupex: Error:
innobackupex: ibbackup failed at /usr/bin/innobackupex line 389.[/INDENT]
Someone could give me a pointer about this problem?. Regards, Javier