xtrabackup behavior during import changed

Bug #716575 reported by Valentine Gostev on 2011-02-10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released

Bug Description

On 5.1.54-12.5.188 to perform import we had to run "xtrabackup --prepare --export" against backup once

With percona server built from trunk it is now necessary to perform additional step: before running "xtrabackup --prepare --export" we should run just "xtrabackup --prepare", otherwise import will fail stating that ibd file we want to import is corrupted.

What happens if we run only "xtrabackup --prepare --export" like it was working before:

2011-02-10 21:24:57: xb_export.sh: ===> /root/distr/test/var/trunk/bin/mysql --no-defaults --socket=/tmp/xtrabackup.mysql.sock --user=root -e alter table test discard tablespace; incremental_sample
2011-02-10 21:24:57: xb_export.sh: ===> xtrabackup --datadir=/root/distr/test/var/mysql --prepare --export --target-dir=/tmp/xb_export_backup
xtrabackup: cd to /tmp/xb_export_backup
xtrabackup: This target seems to be not prepared yet.
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 = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 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
110210 21:24:57 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 38470
110210 21:24:57 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 58034 (1 %)
110210 21:24:57 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
110210 21:24:57 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; log sequence number 58034
xtrabackup: starting shutdown with innodb_fast_shutdown = 0
110210 21:24:57 InnoDB: Starting shutdown...
110210 21:24:58 InnoDB: Shutdown completed; log sequence number 58034
xtrabackup Ver 1.5 Rev 203 for 5.1.53 unknown-linux-gnu (x86_64)
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(38470)
xtrabackup: export option is specified.
xtrabackup: export metadata of table 'incremental_sample/test' to file `./incremental_sample/test.exp` (1 indexes)
xtrabackup: name=GEN_CLUST_INDEX, id.low=15, page=3

[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:

2011-02-10 21:24:58: xb_export.sh: ===> cp /tmp/xb_export_backup/incremental_sample/test.exp /tmp/xb_export_backup/incremental_sample/test.ibd /root/distr/test/var/mysql/incremental_sample/
2011-02-10 21:24:58: xb_export.sh: ===> ls -lah /root/distr/test/var/mysql/incremental_sample/
total 140K
drwx------ 2 root root 4.0K Feb 10 21:24 .
drwxr-xr-x 5 root root 4.0K Feb 10 21:24 ..
-rw-rw---- 1 root root 65 Feb 10 21:24 db.opt
-rw-r--r-- 1 root root 16K Feb 10 21:24 test.exp
-rw-rw---- 1 root root 8.4K Feb 10 21:24 test.frm
-rw-r--r-- 1 root root 96K Feb 10 21:24 test.ibd
2011-02-10 21:24:58: xb_export.sh: ===> /root/distr/test/var/trunk/bin/mysql --no-defaults --socket=/tmp/xtrabackup.mysql.sock --user=root -e alter table test import tablespace incremental_sample
InnoDB: free limit of ./incremental_sample/test.ibd is larger than its real size.
InnoDB: import: extended import of incremental_sample/test is started.
InnoDB: import: 1 indexes are detected.
InnoDB: Progress in %: 16 33 50 66 83 100 done.
110210 21:24:58 InnoDB: Error: file './incremental_sample/test.ibd' seems to be corrupt.
InnoDB: anyway, all not corrupt pages were tried to be converted to salvage.
InnoDB: ##### CAUTION #####
InnoDB: ## The .ibd must cause to crash InnoDB, though re-import would seem to be succeeded.
InnoDB: ## If you don't have knowledge about salvaging data from .ibd, you should not use the file.
InnoDB: ###################
110210 21:24:58 InnoDB: cannot find or open in the database directory the .ibd file of
InnoDB: table `incremental_sample`.`test`
ERROR 1030 (HY000) at line 1: Got error -1 from storage engine
2011-02-10 21:24:58: xb_export.sh: ===> mysql failed with exit code 0

Related branches

affects: percona-xtrabackup → percona-server
Changed in percona-server:
importance: Undecided → High
status: New → Triaged
assignee: nobody → Yasufumi Kinoshita (yasufumi-kinoshita)

The expand_import should accept
(size_bytes < free_limit_bytes)
file_per_table .ibd file (!trx_sys_sys_space(space_id))

I will fix later. Please use <1MB file for now.

Sorry, I missed

Please use >1MB file for now.

Changed in percona-server:
status: Triaged → Fix Committed
Vadim Tkachenko (vadim-tk) wrote :

Was it commited to 5.5 also ?


No, but

5.5 was fixed already. the bug was only for 5.1

I seemed to fix already, though I don't remember.
The fix suggestion to merge for 5.1 at the time might be lost or something.

Changed in percona-server:
milestone: none → 5.1.56-12.7
status: Fix Committed → Fix Released

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-465

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers