On Nov 7, 2007, at 8:26 AM, Dominik Klein wrote:

Hi Andrew

thanks for your reply.

So I thought I could implement "demote" as "return 0", as "promote" on the other machine will do the job anyway. Well, not the best idea as a "monitor" action on the apparently demoted machine will still return Master Status until "promote" on the second machine finished.
What if the crm delayed the slave's monitor until after the other side was promoted... would that help significantly?

That would propably prevent one failed monitor action in this very special case.

Feel free to add it as an enhancement request in bugzilla - i think it makes a certain amount of sense (in general, not just in your case) to implement


Furthermore, the switchover command will fail if the other machine is not responding. In case the current master really has a problem, all you can do get a writeable database on the current slave is to use the failover command. But Linux-HA only knows "promote" and "demote".

So I implemented some promote and demote the following way:

#### promote
if switchover_to_me
then
   return 0
else
   if ! switchover_to_me
   then
       failover_to_me
       return $?
   fi
fi
####

#### demote
switchover_to_other_machine
# dont care if this works as it cannot work if
# the other machine is not healthy
return 0
####

What you also need to know about slony-1 is the fact that you need to resync the COMPLETE data after a failover. In slony-1 it is not possible to let a failed node rejoin the slony-Cluster (even if it was healthy when the failover command was issued). It has to fetch ALL data from the new master. So you want to avoid failover if it is not absolutely necessary.

Up to now I thought my RA could handle a few cases and it turns out: SOME it can handle (like master reboot or slave reboot or controlled switchover). But a simple thing as killing postgres on the master machine causes a failover. Why?:

Say A is master, B is slave at this moment

1. monitor on A fails
2. Linux-HA executes demote on A
-> As you see above, this will work even if it does nothing
3. Linux-HA executes promote on B
-> This, as postgres on A is not running, will end up in a failover (see above)
Notifications might help.
The Filesystem agent (when operating in OCFS2 mode) keeps a list of who its peers are. If you did the same then I think you'd be able to recognize that you're all alone and that it was ok to switchover_to_me instead.

Read my first post again.

I read it a few times but found myself getting lost - maybe i was just having a bad day :-)

Switchover is not possible if the other postgres instance is not available. The only way to make a single slave the new master is to use the failover command.

What *would* help here is:

1. monitor on A fails -> OCF_NOT_RUNNING
Now, instead of "demote A, promote B":
2. Stop/Start the resource on A

One can certainly have demote->stop->start->promote (all on A)
Does that help? The demote shouldn't be a problem for you because its a no-op.

The notify data will also tell you that you used to be a master and that no-one else is one at the moment... in theory that should be enough info to allow you to do something clever right?


Iirc "start" includes a monitor action (or "probe" called sometimes in this case).

Not really... we probe only when we dont know the current state of a resource on a node. So generally this only happens at startup or when the admin uses crm_resource -C

This would report "OCF_RUNNING_MASTER", so the problem would be solved.

On the other hand, this is propably a pretty big change in Linux- HA's master/slave handling and this should be discussed.

Regards
Dominik
_______________________________________________
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

Reply via email to