[DRBD-user] Replication for disaster recovery

Velko veljko3 at gmail.com
Sun Apr 27 20:08:50 CEST 2014

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On 2014-Apr-26 10:31, Digimer wrote:
> >You're talking about hardware fencing? That's possible only when servers
> >are in the same DC.
> 
> yes and no. If the WAN link is working, you can fence over
> distances. The problem is that your fencing will fail if the WAN
> fails, which means you cluster will fail to fence and stay blocked
> (as Lars explained in his reply).
> 
> > I'd like to automate demoting on primary server to
> >avoid split-brains. Promoting secondary to primary would be done
> >manually.
> 
> I'm not sure I understand the benefit here. If the WAN link drops,
> fencing will fail and the nodes will be blocked. Forcing a demotion
> doesn't really help, as a human will need to step in anyway. Let
> that human decide what node takes what role.

Like I said in my answer to Lars, I was trying to get answer to
attempted solution instead to actual problem. Blocking prevents split
brain and is enough for me. If state of the nodes want change without my
intervention, thats fine by me. 

> >although that server is still visible from some other locations. I
> 
> If the other node is visible, it's fencing should also be
> accessible. Fence the node and recover.

But I was thinking of scenario where nodes can't see each other, but are
accessible from different locations. Maybe not very likely scenario, but
possible. 

> To restate; both nodes should block until their peer is put into a
> known state; Be it by human or fencing action. If the nodes are
> blocked, then their role as Primary or Secondary shouldn't matter.

I agree. Thanks for pointing that out. 



More information about the drbd-user mailing list