[MDEV-15639] sst mariabackup required datadir in my.cnf Created: 2018-03-22  Updated: 2021-05-22  Resolved: 2021-05-22

Status: Closed
Project: MariaDB Server
Component/s: Galera SST
Affects Version/s: 10.2.13
Fix Version/s: 10.6.1, 10.2.39, 10.3.30, 10.4.20, 10.5.11

Type: Bug Priority: Major
Reporter: Oli Sennhauser Assignee: Julius Goryavsky
Resolution: Fixed Votes: 0
Labels: None
Environment:

centos 7

Issue Links:
Relates
relates to MDEV-23580 galera_3nodes.galera_ipv6_rsync_secti... Closed
relates to MDEV-25669 SST scripts should check all server g... Closed

 Description   

when we switched from rsync sst method to mariabackup and forced an sst the sst failed with the following error message, which is not easy to see/find:

[root@notebook31 .sst]# tail innobackup.move.log
180322 17:37:22 innobackupex: Starting the move-back operation

IMPORTANT: Please check that the move-back run completes successfully.
At the end of a successful move-back run innobackupex
prints "completed OK!".

--innobackupex based on MariaDB server 10.2.13-MariaDB Linux (x86_64)
Error: datadir must be specified.

Maybe it is possible to write down datadir automatically in my.cnf when mariadb is rolled out via RPM?

 Comments   
Comment by Elena Stepanova [ 2018-03-23 ]

I had the exact same problem while setting up SST tests. It gets especially nasty when you run more than one node on the same machine.
I wouldn't go as far as writing something into a cnf file, and besides it's not a general solution. The behavior is dangerous in general, since you might be running a node from a non-default location, but innobackupex still tries to get the datadir directly from the default cnf files – even if the wrapping SST script knows the datadir location, it doesn't pass it to innobackupex. So, I think it needs to be fixed in the SST script if at all possible.

Comment by Julius Goryavsky [ 2021-05-22 ]

These issues were finally resolved after closing https://jira.mariadb.org/browse/MDEV-25669 and https://jira.mariadb.org/browse/MDEV-23580

Generated at Thu Feb 08 08:22:54 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.