xtrabackup behavior during import changed

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

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`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE
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)
Revision history for this message
Yasufumi Kinoshita (yasufumi-kinoshita) wrote :

The expand_import should accept
(size_bytes < free_limit_bytes)
for
<1MB (size_bytes < FSP_EXTENT_SIZE * UNIV_PAGE_SIZE)
and
file_per_table .ibd file (!trx_sys_sys_space(space_id))

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

Revision history for this message
Yasufumi Kinoshita (yasufumi-kinoshita) wrote :

Sorry, I missed

Please use >1MB file for now.

Changed in percona-server:
status: Triaged → Fix Committed
Revision history for this message
Vadim Tkachenko (vadim-tk) wrote :

Was it commited to 5.5 also ?

Revision history for this message
Yasufumi Kinoshita (yasufumi-kinoshita) wrote :

Vadim,

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
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.