| 2014-01-24 13:26:50 |
maxadamo |
bug |
|
|
added bug |
| 2014-01-24 13:51:52 |
maxadamo |
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 not accessible by the user is found under MySQL "datadir" 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) mkdir ~mysql/blahblah
2) chown root:root ~mysql/blahblah
3) chmod 700 ~mysql/blahblah
4) run innobackupex as user mysql
Of course, there should not be such a weird directory, but in the case of 'lost+found' there shgould 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. |
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 not accessible by the user is found under MySQL "datadir" 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) mkdir ~mysql/blahblah
2) chown root:root ~mysql/blahblah
3) chmod 700 ~mysql/blahblah
4) run innobackupex as user mysql
Of course, there should not be such a weird directory, but in the case of 'lost+found' there shgould 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. |
|
| 2014-01-24 13:52:55 |
maxadamo |
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 not accessible by the user is found under MySQL "datadir" 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) mkdir ~mysql/blahblah
2) chown root:root ~mysql/blahblah
3) chmod 700 ~mysql/blahblah
4) run innobackupex as user mysql
Of course, there should not be such a weird directory, but in the case of 'lost+found' there shgould 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. |
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 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) mkdir ~mysql/blahblah
2) chown root:root ~mysql/blahblah
3) chmod 700 ~mysql/blahblah
4) run innobackupex as user mysql
Of course, there should not be such a weird directory, but in the case of 'lost+found' there shgould 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. |
|
| 2014-01-27 13:25:11 |
Alexey Kopytov |
bug watch added |
|
http://bugs.mysql.com/bug.php?id=22615 |
|
| 2014-01-27 13:25:22 |
Alexey Kopytov |
nominated for series |
|
percona-xtrabackup/2.1 |
|
| 2014-01-27 13:25:22 |
Alexey Kopytov |
bug task added |
|
percona-xtrabackup/2.1 |
|
| 2014-01-27 13:25:22 |
Alexey Kopytov |
nominated for series |
|
percona-xtrabackup/2.2 |
|
| 2014-01-27 13:25:22 |
Alexey Kopytov |
bug task added |
|
percona-xtrabackup/2.2 |
|
| 2014-01-27 13:25:27 |
Alexey Kopytov |
percona-xtrabackup/2.1: status |
New |
Triaged |
|
| 2014-01-27 13:25:30 |
Alexey Kopytov |
percona-xtrabackup/2.2: status |
New |
Triaged |
|
| 2014-01-27 13:25:33 |
Alexey Kopytov |
percona-xtrabackup/2.1: importance |
Undecided |
Wishlist |
|
| 2014-01-27 13:25:35 |
Alexey Kopytov |
percona-xtrabackup/2.2: importance |
Undecided |
Wishlist |
|
| 2014-01-27 13:25:39 |
Alexey Kopytov |
percona-xtrabackup/2.1: milestone |
|
future-2.1-releases |
|
| 2014-01-27 13:25:42 |
Alexey Kopytov |
percona-xtrabackup/2.2: milestone |
|
2.2.0 |
|
| 2014-03-26 12:50:48 |
Alexey Kopytov |
percona-xtrabackup/2.2: milestone |
2.2.0 |
future-2.2-releases |
|
| 2014-04-03 19:24:52 |
maxadamo |
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 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) mkdir ~mysql/blahblah
2) chown root:root ~mysql/blahblah
3) chmod 700 ~mysql/blahblah
4) run innobackupex as user mysql
Of course, there should not be such a weird directory, but in the case of 'lost+found' there shgould 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. |
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. |
|
| 2014-06-20 05:40:54 |
Alexey Kopytov |
tags |
|
low-hanging-fruit |
|
| 2014-06-20 05:41:02 |
Alexey Kopytov |
percona-xtrabackup/2.1: importance |
Wishlist |
Low |
|
| 2014-06-20 05:41:04 |
Alexey Kopytov |
percona-xtrabackup/2.2: importance |
Wishlist |
Low |
|
| 2014-11-14 05:20:01 |
Sergei Glushchenko |
percona-xtrabackup/2.3: milestone |
future-2.2-releases |
future-2.3-releases |
|
| 2017-02-14 06:15:45 |
Sergei Glushchenko |
nominated for series |
|
percona-xtrabackup/2.4 |
|
| 2017-02-14 06:15:45 |
Sergei Glushchenko |
bug task added |
|
percona-xtrabackup/2.4 |
|
| 2017-02-14 06:15:58 |
Sergei Glushchenko |
percona-xtrabackup/2.4: milestone |
future-2.3-releases |
future-2.4-releases |
|
| 2017-02-14 06:16:03 |
Sergei Glushchenko |
percona-xtrabackup/2.2: status |
Triaged |
Won't Fix |
|
| 2017-02-14 06:16:06 |
Sergei Glushchenko |
percona-xtrabackup/2.1: status |
Triaged |
Won't Fix |
|
| 2017-02-14 06:22:02 |
Sergei Glushchenko |
percona-xtrabackup/2.2: milestone |
future-2.2-releases |
|
|
| 2017-02-14 06:22:04 |
Sergei Glushchenko |
percona-xtrabackup/2.1: milestone |
future-2.1-releases |
|
|
| 2017-02-14 10:14:38 |
Vasily Nemkov |
percona-xtrabackup/2.3: assignee |
|
Vasily Nemkov (vasily.nemkov) |
|
| 2017-03-17 11:51:32 |
Vasily Nemkov |
percona-xtrabackup/2.3: status |
Triaged |
Fix Released |
|
| 2017-03-17 11:51:52 |
Vasily Nemkov |
percona-xtrabackup/2.4: status |
Triaged |
In Progress |
|
| 2017-03-17 11:51:52 |
Vasily Nemkov |
percona-xtrabackup/2.4: assignee |
|
Vasily Nemkov (vasily.nemkov) |
|
| 2017-03-23 15:30:26 |
Vasily Nemkov |
percona-xtrabackup/2.4: status |
In Progress |
Fix Released |
|
| 2017-04-03 06:06:51 |
Vasily Nemkov |
percona-xtrabackup/2.3: milestone |
future-2.3-releases |
2.3.8 |
|
| 2017-04-03 06:07:06 |
Vasily Nemkov |
percona-xtrabackup/2.4: milestone |
future-2.4-releases |
2.4.7 |
|
