If you start a MariaDB galera cluster, the first server holds the data, but the rest can start with empty data set. Currently this is not possible: if [ ! -d "${datadir}"/mysql ] ; then ... eerror "You don't appear to have the mysql database installed yet." eerror "Please run \`emerge --config =${DBPKG_P}\` to have this done..." return 1 fi
I second this request and for exactly the same reason. Also see https://bugs.gentoo.org/show_bug.cgi?id=625918 - dev-db/mysql-init-scripts does not support an action for Galera's cluster-bootstrap operation, forcing a lot of manual yak-shaving to bring up a cluster from all nodes down or configure a new cluster.
Created attachment 486414 [details, diff] mysql.init.patch Does the attached patch solve the new cluster issue?
No, that won't solve it, because wsrep-new-cluster is used when bootstrapping the first node of a cluster and its data directory MUST contain data. It is OK for the data directory to be empty only if the node is joining an existing already-bootstrapped cluster. If I'm reading it right, this patch will skip the empty-datadir test if and only if a bootstrap is being performe, which is the one time in a Galera cluster that it must not be empty.
Hmmm ..... I think I know an approach that would work. IF /etc/mysql/my.cnf contains the string 'wsrep_on', on a line that is not commented out, AND my_args does NOT contain the string wsrep-new-cluster, THEN the empty-datadir check can be skipped.
Created attachment 486476 [details, diff] Combined patch for this bug and #625918 Functionality: 1. Galera is not in use: No change in functionality, data directory validity is checked 2. Galera is in use: 2a. rc-service mysql bootstrap New cluster is bootstrapped Data directory must not be empty Service correctly marked as started 2b. rc-service mysql start Existing cluster is joined (existing cluster must be running) Data directory is PERMITTED to be empty Known shortcomings: Galera is detected by the presence of the wsrep_on variable in $MY_CNF. Properly, Galera should be considered active only if wsrep_on is present and not commented out or disabled. However, for reasons I don't yet understand I was unable to get the 'present and not commented out' check to work, only the 'present' check. I also do not check the value of the variable, only that it is present. Also, this patch does not exhaustively check ALL files in the configdir. Known bugs: None discovered so far.
Created attachment 486478 [details, diff] mysql.init.patch Here is a second revision to compare. boostrap_galera is added as a function so any user knows what it does. Also, you cannot read a file to know if wsrep_on is enabled, you won't know where the file is. You must use my_print_defaults. Please test and confirm.
Created attachment 486482 [details, diff] mysql.init.patch Revision 3 with further logic to bootstrap_galera
(In reply to Brian Evans from comment #7) > Created attachment 486482 [details, diff] [details, diff] > mysql.init.patch > > Revision 3 with further logic to bootstrap_galera Sorry, this fails to start mysqld. narn:root:/etc/init.d:14 # rc-service mysql start * Checking mysqld configuration for mysql ... /etc/init.d/mysql: line 182: /sbin/mysqld: No such file or directory * mysql config check failed [ !! ] * ERROR: mysql failed to start
You know, you said the init script can't read from my.cnf because the init script doesn't know where it is. But the existing init script does this: MY_CNF="${MY_CNF:-/etc/${SVCNAME}/my.cnf}" if [ ! -r "${MY_CNF}" ] ; then eerror "Cannot read the configuration file \`${MY_CNF}'" return 1 fi And I've tested and verified that my fileContainsString function passed that same ${MY_CNF} works. So I confess I don't quite see the problem with doing it this way. Am I missing something non-obvious?
(In reply to Phil Stracchino (Unix Ronin) from comment #9) > You know, you said the init script can't read from my.cnf because the init > script doesn't know where it is. But the existing init script does this: > > MY_CNF="${MY_CNF:-/etc/${SVCNAME}/my.cnf}" > > if [ ! -r "${MY_CNF}" ] ; then > eerror "Cannot read the configuration file \`${MY_CNF}'" > return 1 > fi > > And I've tested and verified that my fileContainsString function passed that > same ${MY_CNF} works. So I confess I don't quite see the problem with doing > it this way. Am I missing something non-obvious? Because this won't work with the configs included with MariaDB 10.2
Created attachment 486486 [details, diff] mysql.init.patch Revision 4 to account for empty basedir
(In reply to Brian Evans from comment #10) > (In reply to Phil Stracchino (Unix Ronin) from comment #9) > > You know, you said the init script can't read from my.cnf because the init > > script doesn't know where it is. But the existing init script does this: > > > > MY_CNF="${MY_CNF:-/etc/${SVCNAME}/my.cnf}" > > > > if [ ! -r "${MY_CNF}" ] ; then > > eerror "Cannot read the configuration file \`${MY_CNF}'" > > return 1 > > fi > > > > And I've tested and verified that my fileContainsString function passed that > > same ${MY_CNF} works. So I confess I don't quite see the problem with doing > > it this way. Am I missing something non-obvious? > > Because this won't work with the configs included with MariaDB 10.2 To expand, i made the 10.2 config based on !includedir which may have several files. Never assume that a user doesn't have !include or !includedir and read the file. Using my_print_defaults is consistent.
(In reply to Brian Evans from comment #12) > To expand, i made the 10.2 config based on !includedir which may have > several files. Never assume that a user doesn't have !include or > !includedir and read the file. Using my_print_defaults is consistent. A good point. I did note that as a limitation of my patch. Trying version 4.
Sorry, still no go. First problem was a bad variable declaration: narn:root:/etc/init.d:40 # service mysql start * Checking mysqld configuration for mysql ... [ ok ] * Starting mysql ... /etc/init.d/mysql: line 79: local: `wsrep-new=': not a valid identifier * MySQL datadir `' is empty or invalid * Please check your config file `/etc/mysql/my.cnf' * ERROR: mysql failed to start I changed that wsrep-new variable to wsrep_new, and got a little further: narn:root:/etc/init.d:42 # service mysql start * Caching service dependencies ... [ ok ] * Checking mysqld configuration for mysql ... [ ok ] * Starting mysql ... * MySQL datadir `' is empty or invalid * Please check your config file `/etc/mysql/my.cnf' * ERROR: mysql failed to start It looks like get_config() is not working correctly.
Created attachment 486570 [details, diff] mysql.init.patch (In reply to Phil Stracchino (Unix Ronin) from comment #14) > narn:root:/etc/init.d:42 # service mysql start > * Caching service dependencies ... > [ ok ] > * Checking mysqld configuration for mysql ... > [ ok ] > * Starting mysql ... > * MySQL datadir `' is empty or invalid > * Please check your config file `/etc/mysql/my.cnf' > * ERROR: mysql failed to start > > > It looks like get_config() is not working correctly. Yes, I tried to play with it, so this is a bit reverted.
Galera active, stop and restart: successful Standaline start with Galera disabled: successful Galera active, bootstrap: successful Bootstrap with empty data: correctly alerts that database is empty Standalone start with empty data and Galera disabled: correctly alerts Galera active, start with empty data: Successfully starts, receives SST and rejoins The one state I have found that does not work correctly and requires manual intervention: When attempting to bootstrap from a potentially-unclean data directory (grastate.dat contains 'safe_to_bootstrap: 0'), the script does not detect that bootstrap has failed. It hangs and leaves the mysql service marked in 'crashed' state when killed. Marking the service 'crashed' is probably correct in this case, but the script should exit instead of hanging.
er, meant 'should exit and report failure instead of hanging'
Thinking about it, the safe option in this case would be for bootstrep_galera( ) to check ${datadir}/grastate.dat for safe_to_bootstrap and abort bootstrap with a warning if it is 0. But it does still need to exit with a failed/crashed state if bootstrap or join fails, instead of hanging. (This is probably not entirely straightforward in the case of an empty-or-unclean cluster join that requires an SST.)
(In reply to Phil Stracchino (Unix Ronin) from comment #18) > Thinking about it, the safe option in this case would be for > bootstrep_galera( ) to check ${datadir}/grastate.dat for safe_to_bootstrap > and abort bootstrap with a warning if it is 0. But it does still need to > exit with a failed/crashed state if bootstrap or join fails, instead of > hanging. (This is probably not entirely straightforward in the case of an > empty-or-unclean cluster join that requires an SST.) Added with mysql-init-scripts-2.2 Thanks for the testing. An init system will not be able to account for all possible reasons the service fails to start. That's the administrator's job. We do provide some fail-safe, but a user should know what they are doing to solve issues.
(In reply to Brian Evans from comment #19) > Added with mysql-init-scripts-2.2 > > Thanks for the testing. An init system will not be able to account for all > possible reasons the service fails to start. That's the administrator's job. > We do provide some fail-safe, but a user should know what they are doing to > solve issues. Totally agree. The one failure mode I was able to find is an edge case that requires detailed knowledge of Galera to resolve anyway.
