Re: [Linux-HA] OCF RA mysql

2011-12-03 Thread Nick Khamis
Does the new versions of the RA include remnance of heartbeat v1
script, or have those been completely removed?

Cheers,

Nick.

On Thu, Dec 1, 2011 at 2:02 PM, Florian Haas flor...@hastexo.com wrote:
 On Wed, Nov 30, 2011 at 3:14 PM, Nick Khamis sym...@gmail.com wrote:
 Does the latest version of the RAs have all the old
 heartbeat related material removed?

 I don't follow. Care to clarify the question?

 Florian

 --
 Need help with High Availability?
 http://www.hastexo.com/now
 ___
 Linux-HA mailing list
 Linux-HA@lists.linux-ha.org
 http://lists.linux-ha.org/mailman/listinfo/linux-ha
 See also: http://linux-ha.org/ReportingProblems
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] OCF RA mysql

2011-12-01 Thread Florian Haas
On Wed, Nov 30, 2011 at 3:14 PM, Nick Khamis sym...@gmail.com wrote:
 Does the latest version of the RAs have all the old
 heartbeat related material removed?

I don't follow. Care to clarify the question?

Florian

-- 
Need help with High Availability?
http://www.hastexo.com/now
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


[Linux-HA] OCF RA mysql

2011-11-30 Thread alain . moulle
Hi

I 'm facing a problem with this RA, I wonder if is it a real one already 
identified :
in fact, the stop of the mysql resource fails and therefore the node is 
fenced.
I've checked a little in the RA script : the stop kills the pid retreived 
from 
/var/lib/mysql/mysqld.pid
as indicated in my params :
params binary=/usr/bin/mysqld_safe pid=/var/run/mysqld/mysqld.pid \
but this daemon has /usr/bin/mysqld_safe as father, as this mysqld_safe 
is expected to restart automatically the mysqld daemon if it is killed of 
if
it fails. 
So the stop target of the RA kills the daemon mysqld but as it is 
instantaneously
restarted, it proceeds to SIGTERM, then SIGKILL, etc. until timeout on 
stop
and it is logical because the daemon is restarted just after each kill

So is there something I miss in my configuration ?
Or is this RA not well working when using /usr/bin/mysqld_safe as binary ?

Thanks for your experience around this RA.
Alain 
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] OCF RA mysql

2011-11-30 Thread Florian Haas
On Wed, Nov 30, 2011 at 9:46 AM,  alain.mou...@bull.net wrote:
 Hi

 I 'm facing a problem with this RA, I wonder if is it a real one already
 identified :
 in fact, the stop of the mysql resource fails and therefore the node is
 fenced.
 I've checked a little in the RA script : the stop kills the pid retreived
 from
 /var/lib/mysql/mysqld.pid
 as indicated in my params :
 params binary=/usr/bin/mysqld_safe pid=/var/run/mysqld/mysqld.pid \
 but this daemon has /usr/bin/mysqld_safe as father, as this mysqld_safe
 is expected to restart automatically the mysqld daemon if it is killed of
 if
 it fails.
 So the stop target of the RA kills the daemon mysqld but as it is
 instantaneously
 restarted, it proceeds to SIGTERM, then SIGKILL, etc. until timeout on
 stop
 and it is logical because the daemon is restarted just after each kill

 So is there something I miss in my configuration ?
 Or is this RA not well working when using /usr/bin/mysqld_safe as binary ?

This default is a leftover from the old heartbeat v1 days, when the
cluster manager didn't do any resource monitoring on its own, and
starting MySQL under its angel process was more than helpful. This is
now obsolete. We've had a few discussions about changing this default
here on the list, but those always died in the end because sadly, we
have no real good way of alerting users to changed defaults in RAs.

In a Pacemaker configuration with resource monitoring enabled, you
ought to just use mysqld directly. If you're on RHEL or a derivative,
this means that you'll have to set the binary parameter to the full
path for mysqld, which on that platform (somewhat strangely) lives in
/usr/libexec which is not in the default $PATH. If you're on a
different platform you should be able to just use mysqld as that
would be found in /usr/sbin there.

Cheers,
Florian

-- 
Need help with High Availability?
http://www.hastexo.com/now
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] OCF RA mysql

2011-11-30 Thread alain . moulle
Hi Florian,

 I did not see the previous threads about this, sorry.
Thanks a lot for this information.

Alain



De :Florian Haas flor...@hastexo.com
A : General Linux-HA mailing list linux-ha@lists.linux-ha.org
Date :  30/11/2011 10:28
Objet : Re: [Linux-HA] OCF RA mysql
Envoyé par :linux-ha-boun...@lists.linux-ha.org



On Wed, Nov 30, 2011 at 9:46 AM,  alain.mou...@bull.net wrote:
 Hi

 I 'm facing a problem with this RA, I wonder if is it a real one already
 identified :
 in fact, the stop of the mysql resource fails and therefore the node is
 fenced.
 I've checked a little in the RA script : the stop kills the pid 
retreived
 from
 /var/lib/mysql/mysqld.pid
 as indicated in my params :
 params binary=/usr/bin/mysqld_safe pid=/var/run/mysqld/mysqld.pid \
 but this daemon has /usr/bin/mysqld_safe as father, as this mysqld_safe
 is expected to restart automatically the mysqld daemon if it is killed 
of
 if
 it fails.
 So the stop target of the RA kills the daemon mysqld but as it is
 instantaneously
 restarted, it proceeds to SIGTERM, then SIGKILL, etc. until timeout on
 stop
 and it is logical because the daemon is restarted just after each kill

 So is there something I miss in my configuration ?
 Or is this RA not well working when using /usr/bin/mysqld_safe as binary 
?

This default is a leftover from the old heartbeat v1 days, when the
cluster manager didn't do any resource monitoring on its own, and
starting MySQL under its angel process was more than helpful. This is
now obsolete. We've had a few discussions about changing this default
here on the list, but those always died in the end because sadly, we
have no real good way of alerting users to changed defaults in RAs.

In a Pacemaker configuration with resource monitoring enabled, you
ought to just use mysqld directly. If you're on RHEL or a derivative,
this means that you'll have to set the binary parameter to the full
path for mysqld, which on that platform (somewhat strangely) lives in
/usr/libexec which is not in the default $PATH. If you're on a
different platform you should be able to just use mysqld as that
would be found in /usr/sbin there.

Cheers,
Florian

-- 
Need help with High Availability?
http://www.hastexo.com/now
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] OCF RA mysql

2011-11-30 Thread Nick Khamis
Does the latest version of the RAs have all the old
heartbeat related material removed?

Cheers,

Nick.
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems