--- On Fri, 1/9/09, Dejan Muhamedagic <[email protected]> wrote:
>On Thu, Jan 08, 2009 at 06:07:08AM -0800, Joe Bill wrote:
>>
>> - 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.
>
>What is exactly missing? Can you please be more specific. And
>provide perhaps some examples.
...
>> It makes a lot more sense to use the supervisor's logical
>> instance control facilities than hardcode in the RA
>
>Can you define: "supervisor", "logical instance", and "control
>facilities".
Sure. Take for example mysql replication. What Mysql Inc. defines as a
master instance and it's slave replica instances, are, and should be, IMHO,
viewed by the supervisor, aka Heartbeat, as 2 distinct, running, "logical"
instances, each matching a different cluster resource, regardless of the
number of hosts that are running any of both instances at any time.
If we are to consider a single host, master mysql instance, the fact that only
one host at a time may run this specific cluster instance, but that this
cluster instance may failover on any number of nodes in the cluster, is, and
should be/remain the result of configuring Heartbeat to run and maintain that
specific cluster instance, not that of the mysql master instance.
Then we have the slave instance, for which the mysql configuration should
always be exactly the same, regardless of the host it runs on, and the number
of hosts this slave instance can run on at any time. This is, and should
remain the result of configuring the supervisor heartbeat, and letting
heartbeat manage the starting and the failover of those instances specified
under it's control, rather than at a host's startup init phase.
>> 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.
>
>Several? I thought one RA would control only one resource.
>
Don't you rather mean "control only one *resource type* ?"
>Thanks,
>Dejan
No problem.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
