Absolute paths in innodb_data_file_path are not supported

Reported by MarkD on 2009-06-02
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup
Status tracked in 2.2
1.6
Undecided
Unassigned
2.0
Undecided
Unassigned
2.1
Medium
Alexey Kopytov
2.2
Medium
Alexey Kopytov

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

Tags: pxc Edit Tag help
description: updated
description: updated
Changed in percona-xtrabackup:
assignee: nobody → Yasufumi Kinoshita (yasufumi-kinoshita)
importance: Undecided → High
Changed in percona-xtrabackup:
assignee: Yasufumi Kinoshita (yasufumi-kinoshita) → Valentine Gostev (core-longbow)
Changed in percona-xtrabackup:
importance: High → Undecided
Changed in percona-xtrabackup:
status: New → Confirmed
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
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
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) on 2012-06-15
Changed in percona-xtrabackup:
status: Confirmed → Triaged
Stewart Smith (stewart) on 2012-09-04
Changed in percona-xtrabackup:
assignee: Valentine Gostev (longbow) → nobody
Vlad Lesin (vlad-lesin) wrote :

The bug affects only 1.6.

Changed in percona-xtrabackup:
assignee: nobody → Vladislav Lesin (vlad-lesin)
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.

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) on 2012-09-11
Changed in percona-xtrabackup:
milestone: none → 1.6.7
milestone: 1.6.7 → none
status: Triaged → Won't Fix
Vlad Lesin (vlad-lesin) on 2012-09-11
Changed in percona-xtrabackup:
status: Won't Fix → Triaged
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
tags: added: pxc
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.

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

Other bug subscribers