[Pacemaker] MySQL Master-Master replication with Corosync and Pacemaker

[Peter Scott]

On 1/26/12 5:25 AM, Dan Frincu wrote:
> Hi,
>
> On Thu, Jan 26, 2012 at 1:43 AM, Peter Scott<Peter at psdt.com>  wrote:
>> >  Hello.  Our problem is that a Corosync restart on the idle machine in a
>> >  2-node cluster shuts down the mysqld process there and we need it to stay
>> >  up for replication.  We are very new to Corosync and Pacemaker [...]
>> >
>> >  The problem is this: Say that dev-mysql01 is the active node.  If we restart
>> >  Corosync on dev-mysql02, it stops mysqld there and does not restart it.  We
>> >  can of course restart it manually but we want to understand why this is
>> >  happening because it surprises us and maybe there are other circumstances
>> >  under which it would either stop mysqld or fail to reatart it.
> Corosync is the first layer in the cluster stack (membership and
> messaging), Pacemaker is the second layer (cluster resource
> management), your services are on the third layer.
>
> You take down the bottom layer, that ensures communication, the upper
> layers have no way to talk to the rest of the cluster.
>
> Bottom line, when services are controlled by the cluster and through
> manual intervention the processes that control them are stopped,
> everything under their control stops as well.
>
> If this is intended for administrative purposes, follow Florian's advice.
Thank for your answer.  We're just trying to understand the tools here.  
Certainly if we restart Corosync manually we can ensure that whoever 
does that will then restart MySQL.  I'm not even sure why someone would 
restart Corosync administratively, we were just experimenting.  But 
maybe they would do it because they made a configuration change.

Can you clarify what happened here for me?  When we restarted Corosync, 
something must have told MySQL to stop.  Was that Corosync or 
Pacemaker?  Why did it not tell MySQL to start again when Corosync came 
back?