On 2008-02-21T14:35:30, Doug Lochart <[EMAIL PROTECTED]> wrote:
> So now I am walking through my ha.cf with "crm off" (yes I want to get
> this working in version 1 then convert my haresources to cib format
> afterwards).
I don't think this approach is going to make you very happy. v2 is quite
different in all resource matters, compared to v1.
> 1) There are a number of handlers that can be used in drbd, here are a few:
> # what should be done in case the node is primary, degraded (=no
> connection) and has inconsistent data.
> pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f";
>
> This will forcibly halt the local node. Since heartbeat is in control
> I would assume that stonith should be the only thing doing the
> powering down. Do I simply comment out this handler?
It's not harmful, though. Otherwise, heartbeat will simply shut it down
anyway.
> 2) # The node is currently primary, but lost the after split brain
> auto recovery procedure. As as consequence it should go away.
> pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f";
>
> This again will forcibly halt the local node. I know the value above
> should not be there but I am not sure what to put there in its place
> if anything.
heartbeat will demote one primary anyway.
> 3) # Commands to run in case we need to downgrade the peer's disk
> state to "Outdated". Should be implemented by the superior
> # communication possibilities of our cluster manager. Update: Now
> there is a solution that relies on heartbeat's
> # communication layers. You should really use this.
> outdate-peer "/usr/lib/heartbeat/drbd-peer-outdater -t 5";
>
> Okay so I should use heartbeats communication layers according to the
> comment. Then does that mean I simply comment out this handler?
This smells of drbd8 + v2; I don't know.
> 4) # The node is currently primary, but should become sync target
> after the negotiating phase. Alert someone about this incident.
> pri-lost "echo pri-lost. Have a look at the log files. | mail -s
> 'DRBD Alert' [EMAIL PROTECTED]";
>
> This just tells me that this node was primary and now is in secondary.
> Before it becomes primary again it needs to be the target
> of a sync. Here I simply send an email notifying me that this happened.
>
> What I do not understand is how does the sync materialize? I assume
> that this is always manual task?
It happens automatically, and it means the primary gets data
overwritten, which is rather bound to upset the applications/fs on top.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
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
