Percona XtraBackup moved to https://jira.percona.com/projects/PXB

Absolute paths in innodb_data_file_path are not supported

Bug #382742 reported by MarkD
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
Medium
Alexey Kopytov
Percona XtraBackup moved to https://jira.percona.com/projects/PXB 2.2.0
1.6
Won't Fix
Undecided
Unassigned
2.0
Won't Fix
Undecided
Unassigned
2.1
Fix Released
Medium
Alexey Kopytov
Percona XtraBackup moved to https://jira.percona.com/projects/PXB 2.1.6
2.2
Fix Released
Medium
Alexey Kopytov
Percona XtraBackup moved to https://jira.percona.com/projects/PXB 2.2.0

Bug Description

Hello,

if i specify a absolute path to a innodb data file, the file is not where is would expect it, when i use the --stream option (branch 0.7rc)...

cmd: ./innobackupex-1.5.1 --slave-info --stream=tar /mysql/backup |gzip -c >/mysql/backup/current.tar.gz

my.cnf:
innodb_data_home_dir = /
innodb_data_file_path = /mysql/data/ibdata1:128M:autoextend

If i use these parameters to make a tar stream, the result looks like this:

/mysql/backup/ (after extracting):
backup-my.cnf
mysql/data/ibdata1
mysql/columns_priv.frm
mysql/db.frm
...

> xtrabackup: cd to /mysql/data
> xtrabackup: Target instance is assumed as followings.
> xtrabackup: innodb_data_home_dir = /
> xtrabackup: innodb_data_file_path = /mysql/data/ibdata1:128M:autoextend
> xtrabackup: innodb_log_group_home_dir = /mysql/logs
> xtrabackup: innodb_log_files_in_group = 2
> xtrabackup: innodb_log_file_size = 134217728
> xtrabackup: use O_DIRECT
> xtrabackup: Stream mode.
> >> log scanned up to (109 1074543189)
>
> 090602 14:36:52 innobackupex: Continuing after ibbackup has suspended
>
> innobackupex: Starting to backup InnoDB tables and indexes
> innobackupex: from original InnoDB data directory '/'
> innobackupex: Backing up as tar stream '/mysql/data/ibdata1'

If i change the parameters in the my.cnf to:
innodb_data_home_dir = /mysql/data
innodb_data_file_path = ibdata1:128M:autoextend

> xtrabackup: cd to /mysql/data
> xtrabackup: Target instance is assumed as followings.
> xtrabackup: innodb_data_home_dir = /mysql/data
> xtrabackup: innodb_data_file_path = ibdata1:128M:autoextend
> xtrabackup: innodb_log_group_home_dir = /mysql/logs
> xtrabackup: innodb_log_files_in_group = 2
> xtrabackup: innodb_log_file_size = 134217728
> xtrabackup: use O_DIRECT
> xtrabackup: Stream mode.

/mysql/backup/ (after extracting):
backup-my.cnf
ibdata1
mysql/columns_priv.frm
mysql/db.frm
....

(as expected).

I guess, it might be related to tar converting absolute pathnames to relatives.

Greets
MarkD

See original description
Tags: pxc

Related branches

lp:~akopytov/percona-xtrabackup/bug1049291-2.1
Alexey Kopytov (community): Approve
Diff: 183 lines (+111/-9)
3 files modified
innobackupex.pl (+47/-9)
test/t/bug1049291.sh (+23/-0)
test/t/bug382742.sh (+41/-0)
lp:~akopytov/percona-xtrabackup/bug1049291-2.2
Alexey Kopytov (community): Approve
Diff: 183 lines (+111/-9)
3 files modified
xtrabackup/innobackupex.pl (+47/-9)
xtrabackup/test/t/bug1049291.sh (+23/-0)
xtrabackup/test/t/bug382742.sh (+41/-0)
MarkD (mark-davis-ewetel)
description: updated
MarkD (mark-davis-ewetel)
description: updated
Vadim Tkachenko (vadim-tk)
Changed in percona-xtrabackup:
assignee: nobody → Yasufumi Kinoshita (yasufumi-kinoshita)
importance: Undecided → High
Valentine Gostev (longbow)
Changed in percona-xtrabackup:
assignee: Yasufumi Kinoshita (yasufumi-kinoshita) → Valentine Gostev (core-longbow)
Valentine Gostev (longbow)
Changed in percona-xtrabackup:
importance: High → Undecided
Valentine Gostev (longbow)
Changed in percona-xtrabackup:
status: New → Confirmed
Revision history for this message
Stewart Smith (stewart) wrote :

I'm obviously not seeing something here... everything looks to be how I'd expect it to behave...

Changed in percona-xtrabackup:
assignee: Valentine Gostev (longbow) → nobody
status: Confirmed → Incomplete
Revision history for this message
Alexey Kopytov (akopytov) wrote :

The problem is that when innodb_data_file_path was an absolute path, ibdata1 ended up in the mysql DB in the resulting tarball. This has to be verified with the latest version, but the problem is clear.

Changed in percona-xtrabackup:
status: Incomplete → New
Revision history for this message
Valentine Gostev (longbow) wrote :

The behaviour verified on current version of xtrabackup.
If we specify absolute path to ibdata file - it will be put into a relative directory, since tar removes a leading slash. But backuped config files does not reflect it.

Current workaround is to use config where innodb_data_home_dir has the full path to dir where ibdata1 is kept and innodb_data_file_path just says ibdata1:.....

Changed in percona-xtrabackup:
assignee: nobody → Valentine Gostev (longbow)
status: New → Confirmed
importance: Undecided → Medium
Stewart Smith (stewart)
Changed in percona-xtrabackup:
status: Confirmed → Triaged
Stewart Smith (stewart)
Changed in percona-xtrabackup:
assignee: Valentine Gostev (longbow) → nobody
Revision history for this message
Vlad Lesin (vlad-lesin) wrote :

The bug affects only 1.6.

Changed in percona-xtrabackup:
assignee: nobody → Vladislav Lesin (vlad-lesin)
Revision history for this message
Alexey Kopytov (akopytov) wrote :

If it only affects 1.6, then I think it should be Won't Fix. Though I'd like to get some explanation why it is not relevant for 2.0.

Revision history for this message
Vlad Lesin (vlad-lesin) wrote :

The explanation why this bug affects only 1.6 the following.

The difference between the ways of tar streaming in 1.6 and 2.0 is 1.6 use external "tar4ibd" command which is invoked from "start_ibbackup" subroutine in innobackupex while 2.0 use libarchive functions("archive_entry_new()", "archive_entry_set_pathname()" from "stream_open()" for creating "file" in stream and "archive_write_data()" from "stream_write()" for writing data to stream) to work with tar stream.

I think tar from "libtar-1.2.11" just converts absolute path to relative because innobackupex pass absolute path of ibdata file to tar4ibd but we get relative path in the output stream. As we patch tar for using it in innobackupex the solution may be in including this bug fixing in tar4ibd_libtar-1.2.11.patch.

Vlad Lesin (vlad-lesin)
Changed in percona-xtrabackup:
milestone: none → 1.6.7
milestone: 1.6.7 → none
status: Triaged → Won't Fix
Vlad Lesin (vlad-lesin)
Changed in percona-xtrabackup:
status: Won't Fix → Triaged
Revision history for this message
Alexey Kopytov (akopytov) wrote :

OK, libarchive doesn't strip leading slashes from path names, but that's irrelevant, because xtrabackup strips all directories (including the leading slash) from ibdata1 before passing it to libarchive. So, for example, "/mysql/data/ibdata1" will be stored in the resulting stream with the path "ibdata1".

That will be prepared correctly, because even though innodb_data_file_path stored in backup-my.cnf will contain an absolute path, xtrabackup will strip the directory part from it before executing --prepare (see innodb_init_param()).

However, innobase --copy-back will fail to copy ibdata1 to an absolute path location. I could not test it, because there's a separate issue, see bug #1049291, but from code audit in copy_back() it looks like it would test if the file "<backup_directory>/mysql/data/ibdata1", which of course does not exist, and fail with an error.

Let's keep this report to track that problem. I have also updated the summary accordingly.

summary: - Problem parsing innodb_data_file_path in stream mode
+ Absolute paths in innodb_data_file_path are not supported
Raghavendra D Prabhu (raghavendra-prabhu)
tags: added: pxc
Revision history for this message
Alexey Kopytov (akopytov) wrote :

This bug has is fully fixed by the combination of fixes for bug #856400 and bug #1049291. The linked branch contains no specific changes to fix this bug, but adds a test case.

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/PXB-60

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

Other bug subscribers

Remote bug watches

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