bootstrap option in init script

[Frederic Descamps]

As many people don't like to start the cluster with wsrep_cluster_address=gcomm:// and modify my.cnf afterwards, having an option in the init script is the best option.

like this:

/etc/init.d/mysql
Usage: mysql {start|stop|restart|bootstrap|reload|force-reload|status} [ MySQL (Percona XtraDB Cluster) options ]

[root@percona1 init.d]# /etc/init.d/mysql bootstrap
Starting MySQL (Percona XtraDB Cluster)..... SUCCESS!

This start mysql with --wsrep-cluster-address="gcomm://"

[Frederic Descamps (lefred)]

same feature for debian/ubuntu

[Henrik Ingo (hingo)]

FYI: We are actually working on exactly this kind of feature for Galera 3.0. If I remember correctly, the variable will be --wsrep-cluster-start:
service mysql start --wsrep-cluster-start

Using empty "gcomm://" string will become deprecated and eventually result in an error. This is to further ensure people can't shoot themselves in the foot. (wsrep-cluster-start will also not be allowed in my.cnf, only command line.)

[Frederic Descamps (lefred)]

Henrik,

Nice to know, thank you for sharing. It will be very easy to modify the init script to replace --wsrep-cluster-addess="gcomm://" by --wsrep-cluster-start

[Henrik Ingo (hingo)]

Fred, Raghu: My point was actually the opposite. It would make sense for you to adopt this syntax already now in PXC, rather than adding a "Percona Proprietary" syntax. Just check for --wsrep-cluster-start option in the init script, then convert it to --wsrep-cluster-address. Don't add Percona specific option, please.

[Raghavendra D Prabhu (raghavendra-prabhu)]

@Henrik,

Sure, I will check. I presumed that the option will be available in future, hence added this as a drop-in replacement.

[Henrik Ingo (hingo)]

Raghu

The option is not available yet. (As far as I know.) My point is that you have a point with this patch, but instead of introducing a new syntax:
service mysql bootstrap

Why don't you implement our future syntax instead:
service mysql start --wsrep-cluster-start

Then internally in the script do exactly what you do now (wsrep-cluster-address="gcomm://")

[Frederic Descamps (lefred)]

Hi Henrik,

The point is that debian/ubuntu won't allow you to send a parameter to
the init script (this is what I did before being blamed as I ported the
same feature as rhel init script).

So I think having a new "command" for the init script is the way to go.
Know if it does --wsrep_cluster_address="gcomm://" or
--wsrep-cluster-start that's very easy to modify when it's available.

Regards,

On ven, 2013-03-22 at 16:15 +0000, Henrik Ingo wrote:
> Fred, Raghu: My point was actually the opposite. It would make sense for
> you to adopt this syntax already now in PXC, rather than adding a
> "Percona Proprietary" syntax. Just check for --wsrep-cluster-start
> option in the init script, then convert it to --wsrep-cluster-address.
> Don't add Percona specific option, please.
>

[Alex Yurchenko (ayurchen)]

Hi guys,

Actually the option is there and it is called --wsrep-new-cluster. Unfortunately for some reason it didn't make into 5.5-23 branch, not sure why.

Fred, why not give debian/ubuntu script an ability to accept parameters instead of adding a new command? That will be far more flexible, since sometimes, for example, you want to do

# service mysql start --wsrep-cluster-address=gcomm://a.b.c.d

- and not just wsrep-related stuff...

[Frederic Descamps (lefred)]

Hi Alex,

As you may have noticed, I'm more in the rhel/centos world, so when I
changed the init script of debian, I got some personal messages from
debian pple not very happy with that. They explained this wasn't the
debian way of doing.

Therefor I made a change to my init script to have a new command, I
called it "initialize", then discussing with my colleagues we thought
that for standardization it would be better to have the same behavior in
rhel/centos, so I decided to change the command name, "bootstrap" seemed
to fit better.

So that's why I added this command.

Also it will be much easier for people to bootstrap the cluster, this
will be easier to document too and I hope have less error ;-)

Regards,

On ven, 2013-03-22 at 18:07 +0000, Alex Yurchenko wrote:
> Hi guys,
>
> Actually the option is there and it is called --wsrep-new-cluster.
> Unfortunately for some reason it didn't make into 5.5-23 branch, not
> sure why.
>
> Fred, why not give debian/ubuntu script an ability to accept parameters
> instead of adding a new command? That will be far more flexible, since
> sometimes, for example, you want to do
>
> # service mysql start --wsrep-cluster-address=gcomm://a.b.c.d
>
> - and not just wsrep-related stuff...
>

[Frederic Descamps (lefred)]

Hi guys,

I wanted also to mention that I started all this thread on my own blog
and I got some public and private comments of pple appreciating that new
option of the init script ;)

On ven, 2013-03-22 at 18:07 +0000, Alex Yurchenko wrote:
> Hi guys,
>
> Actually the option is there and it is called --wsrep-new-cluster.
> Unfortunately for some reason it didn't make into 5.5-23 branch, not
> sure why.
>
> Fred, why not give debian/ubuntu script an ability to accept parameters
> instead of adding a new command? That will be far more flexible, since
> sometimes, for example, you want to do
>
> # service mysql start --wsrep-cluster-address=gcomm://a.b.c.d
>
> - and not just wsrep-related stuff...
>

[Alex Yurchenko (ayurchen)]

On 2013-03-22 20:21, Frederic Descamps wrote:
> Hi Alex,
>
> As you may have noticed, I'm more in the rhel/centos world, so when I
> changed the init script of debian, I got some personal messages from
> debian pple not very happy with that. They explained this wasn't the
> debian way of doing.

Ok, so what is the debian way to start a node so that it takes SST from
particular donor? Editing my.cnf?

> Therefor I made a change to my init script to have a new command, I
> called it "initialize", then discussing with my colleagues we thought
> that for standardization it would be better to have the same behavior
> in
> rhel/centos, so I decided to change the command name, "bootstrap"
> seemed
> to fit better.
>
> So that's why I added this command.
>
> Also it will be much easier for people to bootstrap the cluster, this
> will be easier to document too and I hope have less error ;-)

Adding a command to start a new cluster also crossed my mind. But then
generality won. And also

# service mysql bootstrap

sounds kinda ambiguous. If it were

# service pxc bootstrap

that would be clearer. But IIRC mysqld already has a --bootstrap
option, and it does a totally different thing.

Anyway - peace,
Alex

> Regards,
>
> On ven, 2013-03-22 at 18:07 +0000, Alex Yurchenko wrote:
>> Hi guys,
>>
>> Actually the option is there and it is called --wsrep-new-cluster.
>> Unfortunately for some reason it didn't make into 5.5-23 branch, not
>> sure why.
>>
>> Fred, why not give debian/ubuntu script an ability to accept
>> parameters
>> instead of adding a new command? That will be far more flexible,
>> since
>> sometimes, for example, you want to do
>>
>> # service mysql start --wsrep-cluster-address=gcomm://a.b.c.d
>>
>> - and not just wsrep-related stuff...
>>
>
> --
> You received this bug notification because you are a member of
> Codership, which is subscribed to Percona XtraDB Cluster.
> https://bugs.launchpad.net/bugs/1152764
>
> Title:
> bootstrap option in init script
>
> Status in Percona XtraDB Cluster - HA scalable solution for MySQL:
> Fix Released
>
> Bug description:
> As many people don't like to start the cluster with
> wsrep_cluster_address=gcomm:// and modify my.cnf afterwards, having
> an
> option in the init script is the best option.
>
> like this:
>
> /etc/init.d/mysql
> Usage: mysql
> {start|stop|restart|bootstrap|reload|force-reload|status} [ MySQL
> (Percona XtraDB Cluster) options ]
>
> [root@percona1 init.d]# /etc/init.d/mysql bootstrap
> Starting MySQL (Percona XtraDB Cluster)..... SUCCESS!
>
>
> This start mysql with --wsrep-cluster-address="gcomm://"
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1152764/+subscriptions

--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: [phone]

[Henrik Ingo (hingo)]

Fred, what is it that doesn't work for you on Ubuntu/Debian?

Let's take as base the init script from PXC for Debian: bazaar.launchpad.net/~percona-core/percona-xtradb-cluster/5.5/view/head:/build/debian/percona-xtradb-cluster-server-5.5.mysql.init and save it as service "foo"

Now I replace the start section with:

  'start')
        # Start daemon
        log_daemon_msg "Starting foo"
        log_daemon_msg "Parameters: $@"
        ;;

The parameter seems to work just as with Centos. Of course the "start" utility doesn't work as this isn't an upstart script.

hingo@chewbacca:~$ sudo /etc/init.d/foo start
 * Starting foo
 * Parameters: start
hingo@chewbacca:~$ sudo /etc/init.d/foo start ---wsrep-cluster-start
 * Starting foo
 * Parameters: start ---wsrep-cluster-start
hingo@chewbacca:~$ start foo bar
start: Unknown job: foo
hingo@chewbacca:~$ sudo service foo start bar
 * Starting foo
 * Parameters: start bar
hingo@chewbacca:~$ lsb_release -ai
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal

[Henrik Ingo (hingo)]

Fred, can you add a link to the comments you got.

I realize having additional options to an init script is non-standard, but is there some argument beyond that? For example, is it specifically against debian packaging guidelines or something?

[Frederic Descamps (lefred)]

Henrik,

in reply to #13, I know it works, I made a patch for that using similar behaviour (http://www.lefred.be/node/163) and that's why
debian/ubuntu wasn't happy.

Comments where on facebook chat, but this is a summary:

"I was reading your patch, and you totally fail to understand debian/ ubuntu . This patch is completely against how it's usually done in debian. If your daemon needs extra command-line options to run, you use a file in /etc/default .
[...]
that's the correct way of doing things in a debian way:
a) if your daemon reads certain options from a config file, use that;
b) if your daemon doesn't read certain options from a config file, but uses command-line arguments instead, use a file in /etc/default (/etc/sysconfig) to specify these extra arguments with an environment variable"

Then I explain that this is something like a one shot parameter and this is the reply:

"I would still say it's wrong
in that case I would add an extra option in your case ... esac
something like along the lines of force-restart"

and

"but I would still say accepting an extra argument is not the correct way
look at the init-script from apache for example

it does things like this:

start-htcacheclean)
log_daemon_msg "Starting htcacheclean"
start_htcacheclean || log_end_msg 1
log_end_msg 0"

That's why I proposed a new command to the init script, which I don't see where the problem is as PXC could have an extra command as it's not MySQL (there are extra configuration settings, extra variables and extra status variables, so why not an extra init command?)

The goal with that extra init command is to have the same command on every distro and not use a way in centos/rhel and another in ubunut/debian...

Also I didn't/don't put any pression to have this patch merged, this is an option now you guys make your choice of course ;-)

[Henrik Ingo (hingo)]

Ok so basically it was one guy saying you totally fail to understand how linux works :-) At the same time he fails to understand that banning the argument from config file is precisely the point. He doesn't even seem to know whether MySQL hasa config file. Btw, I don't see that this issue is any different on Centos vs Ubuntu. Both alternatives work in both cases and having extra

Anyway, having a different init command is of course also an alternative. Like Alex points out, simply calling it "bootstrap" is quite overloaded and ambiguous and we early on steered clear from that. I would perhaps suggest "cluster-start"?

service mysql cluster-start
service mysql start
service mysql stop
...

[Frederic Descamps (lefred)]

I've a debian maintener friend, let's me ask him more info ;)

Btw, yeah for the name of the command I had no idea, I started with "initialize" but that was too frenglish I guess, so I opted for "bootstrap" but any other name making more sense is welcome ;)

cluster-start +1

;)

[Alex Yurchenko (ayurchen)]

Fred,

As Lenin once said, "Marxism is not a dogma, but a recipe". I think it is fully applicable to Debian init scripts policy. If the recipe does not cover your use case, you have to find a way that does. I think the guy (who said that you didn't understand Debian) was rightfully alarmed that you were going to introduce a non-standard way to pass parameters to daemons which the Debian user is not supposed to be used to. What he didn't understand was that mysqld is not a exactly a standard OS daemon (and MySQL DBA is not exactly a Debian user), and a cluster node process is even less so - that is, sometimes the DBA needs to start it manually, and pass it parameters, just like the regular program.

Also, being able to pass command line parameters to init script does not invalidate other, "standard", ways to configure mysqld daemon in Debian, so you're a not really breaking any rules by supporting an additional way, so it can't be a serious objection. I suppose the guy was just trying to "educate" you about the standard Debian ways being unaware that those are not enough.

Generally not being able to pass arbitrary command line options to mysqld in init script invocation can be a serious pain in the ass so I'd wholeheartedly advise to leave that opportunity in debian init script - at least for the sake of compatibility with RHEL/CentOS. However once you support passing the parameters, the need for dedicated command kinda falls off.

As for the command name, finding a good one is paramount since it stays forever ;) Again, with Henrik's proposal we see

# service mysql cluster-start

which is kinda confusing (which cluster is meant here? MySQL Cluster?). Wouldn't it make sense to rename the whole service as 'pxc' in that case? Or this one:

# service mysql bootstrap-pxc

?

[Henrik Ingo (hingo)]

My suggestion is based on using the same name as the actual mysqld option: --wsrep-cluster-start

It's true that "cluster-start" isn't 100% self explanatory either (it start only one node, not a full cluster) but at least it is not overloaded or conflicting with existing functionality, like "bootstrap".

[Alex Yurchenko (ayurchen)]

Hehrik, the option name (as of now) is --wsrep-new-cluster (see lp:codership-mysql/5.5) with attempt to imply that a new cluster will be created as opposed to starting a potentially old one. But the naming is of course debatable.

[Henrik Ingo (hingo)]

Ah, my bad. Thanks for correcting.

So in that case I propose also:
service mysql new-cluster
or possibly:
service mysql start-new-cluster

...as the new init script command. The latter alternative modeled on "start-htcacheclean" and other similar start-* commands.

[Raghavendra D Prabhu (raghavendra-prabhu)]

Thanks for all the comments. I see a fix committed for wsrep-cluster-start in lp:1087368. I have uncommitted the change for now, it would be better to work out the init scripts to use it (which is probably merged in next milestone).

[Raghavendra D Prabhu (raghavendra-prabhu)]

This is waiting on https://bugs.launchpad.net/bugs/1087368 for its utilization.

[Raghavendra D Prabhu (raghavendra-prabhu)]

Since lp:1087368 has been moved to 5.5-24, using wsrep-cluster-address=gcomm:// in the interim.

[Raghavendra D Prabhu (raghavendra-prabhu)]

Since lp:1087368 was merged, fixed here as well.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1307