[ClusterLabs] Antw: Re: reproducible split brain

[vija ar]

root file system is fine ...

but fencing is not a necessity a cluster shld function without it .. i see
the issue with corosync which has all been .. a inherent way of not working
neatly or smoothly ..

for e.g. take an issue where the live node is hung in db cluster .. now db
perspective transactions r not happening and tht is fine as the node is
having some issue .. now there is no need to fence this hung node but just
to switch over to passive one .. but tht doesnt happens and fencing takes
place either by reboot or shut .. which further makes the DB dirty or far
more than tht in non-recoverable state which wouldnt have happen if a
normal switch to other node as in cluster would have happened ...

i see fencing is not a solution its only required to forcefully take
control which is not the case always

On Thu, Mar 17, 2016 at 12:49 PM, Ulrich Windl <
Ulrich.Windl at rz.uni-regensburg.de> wrote:

> >>> Christopher Harvey <cwh at eml.cc> schrieb am 16.03.2016 um 21:04 in
> Nachricht
> <1458158684.122207.551267810.11F73AB9 at webmail.messagingengine.com>:
> [...]
> >> > Would stonith solve this problem, or does this look like a bug?
> >>
> >> It should, that is its job.
> >
> > is there some log I can enable that would say
> > "ERROR: hey, I would use stonith here, but you have it disabled! your
> > warranty is void past this point! do not pass go, do not file a bug"?
>
> What should the kernel say during boot if the user has not defined a root
> file system?
>
> Maybe the "stonith-enabled=false" setting should be called either
> "data-corruption-mode=true" or "hang-forever-on-error=true" ;-)
>
> Regards,
> Ulrich
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20160317/54813cc5/attachment-0002.html>