innobackupex dies if a directory is not readable. i.e.: lost+found

Bug #1272329 reported by maxadamo
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Status tracked in 2.4
2.1
Won't Fix
Low
Unassigned
2.2
Won't Fix
Low
Unassigned
2.3
Fix Released
Low
Vasily Nemkov
2.4
Fix Released
Low
Vasily Nemkov

Bug Description

I am using percona-xtrabackup-2.1.6-702.rhel6.x86_64 in conjunction with Galera Replication and Percona XtraDB Engine.

MySQL uses innobackupex to perform SST (State Snapshot Tranfer) from one node to the others, and innobackupex is run as user mysql (we don't want to run mysql as root).
If a directory under the MySQL "datadir" is not accessible by the user, innobackupex will die.
A common case, is the 'lost+found' directory which is owned by root and has permissions 0700

I don't have the logs with me, but it's just easy to reproduce:
1) install -g root -o root -m 0700 -d ~mysql/blahblah
2) run innobackupex as user mysql

Of course, there should not be such a weird directory, but in the case of 'lost+found' there should be an exception.

The fix that makes much more sense to me, is to have an exception for such directory (nobody will call a schema with such name).
It would be acceptable to have an option to exclude a specific directory, but this option should be understandable by Galera, and writable to MySQL configuration file.

description: updated
description: updated
Revision history for this message
Alexey Kopytov (akopytov) wrote :

Note there's a very similar bug reported against MySQL: http://bugs.mysql.com/bug.php?id=22615

I.e. the server treats any directory as a database and that may cause issues if some directories (such as lost+found, .Trashes, etc.) are created by OS utilities rather than the server.

The suggested workaround for lost+found mentioned in that bug report would also eliminate the problem for XtraBackup. I.e. just make datadir a subdirectory of a mount rather than the top-level directory.

That bug was fixed only in 5.6 by introducing another server option, --ignore-db-dir.

I see 2 ways to fix this for XtraBackup:

1) Provide a way to exclude certain directories from the backup. Which has already been requested in bug #688717.
2) Read ignore_db_dir from my.cnf in server versions 5.6 and higher, and automatically exclude them from the backup.

Which makes this report essentially a request to implement #2.

Revision history for this message
maxadamo (massimilianoadamo) wrote :

Hello Alex.
I agree your proposal.
Furthermore, I am already using the option ignore_db_dir, which seems to work with MariaDB 5.5.xx + Percona XtraDB Tables.
In fact, when I have put this option, "show databases" does not show ".ssh" and "lost+found" anymore.
Anyway, if it doesn't work with some version of MySQL, it will probably be ignored (it just a variable declaration) by the DB, but it will be taken into consideration from Innobackupex.

The change is anyway up to you; but if you add extra optiont it would be better to not involve another change from Galera side.... I mean that in my opinion Galera should not see anything different to make life easier for everybody and get things working smoother... without the need to file another issue against Galera.

Revision history for this message
maxadamo (massimilianoadamo) wrote :

p.s.: I tend to use clean RPM packages. For this reason I am not using a subdirectory.

description: updated
tags: added: low-hanging-fruit
Revision history for this message
Alexey Kopytov (akopytov) wrote :

Bug #1272329 is a duplicate of this one.

Revision history for this message
maxadamo (massimilianoadamo) wrote :

is anybody willing to fix this issue?
Is it so hard to have innobackup reading a list of exclusion (i.e.: ignore_db_dir from my.cnf)?

Revision history for this message
Vasily Nemkov (vasily.nemkov) wrote :
Revision history for this message
Vasily Nemkov (vasily.nemkov) wrote :
Revision history for this message
Vasily Nemkov (vasily.nemkov) wrote :
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-907

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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