On Thu, Nov 20, 2008 at 08:32:52AM -0700, Ryan Kish wrote:
>> - Both nodes have a two ldap configurations, one for running as the
>> master, one for running as the slave. I had to write a couple of OCF
>> scripts for each service (master and slave).
On 2008-11-20, Dejan Muhamedagic <dejanmm[at]fastmail.fm> wrote:
>
> I guess that this could be better handled by a multi-state
> (master-slave) resource. For which you'd need an appropriate OCF
> RA. Basically, what you already have could be combined in a
> single RA, with two extra operations (actions): promote (slave
> to master) and demote (vice versa). Your configuration would
> also be simpler.
>
> Dejan
I've recently given multi-state RAs a hard, heavy thought.
I have to disagree on several issues brought up above:
- the "master/slave, promote/demote" is not a universal multi-state model and
appears, to me at least, to poorly represent instance relationships between
several different components/applications.
- the mysql replication model as a master-slave architecture, by giving the
"master"/"slave" moniker values to an option determining a hosts's role, is a
misrepresentation. The fact of the matter is that one host can run both, the
master AND the backup instances at the same time, and all still make sense and
be coherent with the HA supervisor, depending on the availability/reachability
of nodes. I have yet to figure the advantage of changing on the fly
the state of an instance, particularly in it's relationship with other
instances, whether the same or different components/applications are involved,
instead of just stopping and restarting an instance with a different
configuration.
It makes a lot more sense to use the supervisor's logical instance control
facilities than hardcode in the RA promote/demote rules that have to track and
manage the states of multiple instances, and especially difficult to write
"decision" code that requires to assess and control the states of several
different compnents.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
