Non-default log location causes Galera join to "fail" (xtrabackup)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL patches by Codership |
New
|
Undecided
|
Unassigned |
Bug Description
Hope this is the right place to report this.
Software
percona-
galera-
mysql-5.
We have a wish to move log files away from the disk that contains the database files, to spread the IO of the system across our SAN, thus we have configured the system to use.
data -> /data/mysql/data
logs -> /data/mysql/logs
With the basic configuration (I've removed tuning information, as I think it's irrelevant, and I can reproduce the problem using just the configuration listed here.
[mysqld]
# 1. Mandatory settings: these settings are REQUIRED for proper cluster operation
query_cache_size=0
binlog_format=ROW
default_
innodb_
innodb_
# 2. Optional mysqld settings: your regular InnoDB tuning and such
datadir=
innodb_
innodb_
innodb_
innodb_
# 3. wsrep provider configuration: basic wsrep options
wsrep_provider=
wsrep_provider_
wsrep_cluster_
wsrep_cluster_
wsrep_sst_
wsrep_sst_
wsrep_node_
# 4. additional "frequently used" wsrep settings
wsrep_node_
wsrep_sst_
wsrep_slave_
# this block seems to make no difference.
[xtrabackup]
datadir=
log-bin=
log-bin-
log-error=
innodb-
If in my.cnf I setup the following (on all nodes, and bootstrap).
log-bin=
log-bin-
innodb_
(it only seems to be the innodb_
I keep seeing the following errors in the database logs
131022 9:56:57 InnoDB: Error: page 3 log sequence number 7750166
InnoDB: is in the future! Current system log sequence number 1596006.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://
InnoDB: for more information.
And I notice, that though I've requested that the innodb logs (ib_logfile0, ib_logfile1) to be placed in /data/mysql/logs
Examining nodes..
node-a => the bootstrap (first node of the cluster, started with the --wsrep_
# ls /data/mysql/
ls: cannot access /data/mysql/
(as I would expect).
on all other nodes (b,c,d) all have logs placed in this diretory, as well as in /data/mysql/logs
# ls /data/mysql/
/data/mysql/
# ls /data/mysql/
/data/mysql/
And it seems that xtrabackup is creating the log files in /data/mysql/data, though it has been instructed to place them in /data/mysql/logs
Running the system using rsync, the above problem does not exist, and the ib_logfiles are in the correct locations.
thus on all nodes
# ls /data/mysql/
ls: cannot access /data/mysql/
# ls /data/mysql/
/data/mysql/
Not sure if it's an xtrabackup bug..
Looks like a duplicate of:
https:/ /bugs.launchpad .net/percona- xtradb- cluster/ +bug/1098566 /bugs.launchpad .net/percona- xtradb- cluster/ +bug/1019288
https:/