directory premission and backup failure
Bug #664986 reported by
SingerWang
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
High
|
Alexey Kopytov | ||
2.0 |
Fix Released
|
High
|
Alexey Kopytov | ||
2.1 |
Fix Released
|
High
|
Alexey Kopytov |
Bug Description
Consider the following case on a RHEL System
- MySQL is running as mysql:mysql
- backup is running as bacula user (bacula:bacula but also part of the mysql group)
- the is a new database created and the corresponding directory is set as 0700 for premissions and mysql:mysql for ownership
- inside the new database the there are both MyISAM and InnoDB Tables (file per table is set)
- when innobackex/
- the output of innobackex/
Related branches
lp://staging/~longbow/percona-xtrabackup/bug664986
Rejected
for merging
into
lp://staging/percona-xtrabackup/2.0
- Alexey Kopytov (community): Needs Resubmitting
-
Diff: 59 lines (+50/-0)2 files modifiedtest/t/ib_permissions.sh (+25/-0)
test/t/xb_permissions.sh (+25/-0)
lp://staging/~akopytov/percona-xtrabackup/bug664986-2.0
- Sergei Glushchenko (community): Approve (g2)
-
Diff: 406 lines (+134/-31)6 files modifiedpatches/innodb51.patch (+17/-6)
patches/innodb51_builtin.patch (+20/-9)
patches/innodb55.patch (+16/-5)
patches/xtradb51.patch (+17/-6)
patches/xtradb55.patch (+16/-5)
test/t/bug664986.sh (+48/-0)
lp://staging/~akopytov/percona-xtrabackup/bug664986-2.1
- Sergei Glushchenko (community): Approve (g2)
-
Diff: 310 lines (+114/-22)5 files modifiedpatches/innodb51.patch (+17/-6)
patches/innodb55.patch (+16/-5)
patches/xtradb51.patch (+17/-6)
patches/xtradb55.patch (+16/-5)
test/t/bug664986.sh (+48/-0)
Changed in percona-xtrabackup: | |
status: | New → Confirmed |
importance: | Undecided → Low |
Changed in percona-xtrabackup: | |
assignee: | Valentine Gostev (longbow) → Stewart Smith (stewart) |
Changed in percona-xtrabackup: | |
assignee: | Stewart Smith (stewart) → nobody |
status: | Confirmed → Triaged |
To post a comment you must log in.
Tried with the latest 1.6:
~$ innobackupex --user=root /home/gval/ data_home_ dir = / data_file_ path = var/lib/ mysql/ibdata1: 10M:autoextend log_group_ home_dir = ./ log_files_ in_group = 2 log_file_ size = 5242880 mysql/ibdata1 mysql/ibdata1 data_file_ path in my.cnf back innobackupex line 342.
...snip...
xtrabackup Ver 1.6 Rev 245 for 5.1.55 unknown-linux-gnu (x86_64)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
xtrabackup: innodb_
110502 14:53:59 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name /var/lib/
InnoDB: File operation call: 'open'.
InnoDB: Error in opening /var/lib/
110502 14:53:59 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
xtrabackup: Could not open or create data files.
xtrabackup: If you tried to add new data files, and it failed here,
xtrabackup: you should now edit innodb_
xtrabackup: to what it was, and remove the new ibdata files InnoDB created
xtrabackup: in this failed attempt. InnoDB only wrote those files full of
xtrabackup: zeros, but did not yet use them in any way. But be careful: do not
xtrabackup: remove old data files which contain your precious data!
innobackupex: Error: ibbackup child process has died at /usr/bin/
~$ echo $?
2
Can you please also try if you can reproduce the issue with XtraBackup 1.6?