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