[DRBD-user] Replication for disaster recovery

Velko veljko3 at gmail.com
Fri Apr 25 23:47:45 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.

Hi Digimer,

On 2014-Apr-25 10:22, Digimer wrote:
> >I'm planing to use DRBD for DR and since I've never used it, I have a
> >few questions.
> >
> >1. Have anyone used it for replication to different data center (both
> >east coast of USA)? I was thinking of using protocol A without DRBD
> >proxy (maybe protocol B). How does it work in real life?
> You would want Protocol A, or else your storage performance would
> effectively drop to the same speed as the network. Of course, the
> trade-off is that the remote side will often be a little behind
> production (or a lot behind, depending of how much data is being
> written compared to the network speed).

That is something I will have to live with.

> >2. Since there is a lot of 2-3 MB files in size of 1GB daily that are
> >not that important in case I need to switch to secondary site, would it
> >be possible to put those files on separate partition (DRBD device) and
> >configure it to have lower priority? Maybe only periodically
> >resynchronization? I understood that it is much more efficient.
> >Partition with less changing files and InnoDB tables would have high
> >priority.
> Not easily. I suppose you could create a separate resource which
> would use a different port and then try QoS, but that could get
> tricky (in general, not DRBD specific, QoS can be a pita).

In that case, I'll just use rsync and cron for those files.

> >3. Would having separate NIC for replications improve performances in
> >this case?
> Depends entirely on where your bottle-neck is. I suspect that will
> be your WAN connection, which you didn't talk about. ;)

I just thought that main problem will be latency, not bandwidth. 100Mb
can't be saturated in my usecase, but that's just theory and practice
can be different.

> >4. Is it possible to configure DRBD to automatically demote in case of
> >loosing internet connection?
> Not safely, no. There is now reliable way to use fencing, and
> without reliable fencing, only a human can ensure the state of the
> lost node. To try and automate it would very likely lead to
> split-brains.

You're talking about hardware fencing? That's possible only when servers
are in the same DC. I'd like to automate demoting on primary server to
avoid split-brains. Promoting secondary to primary would be done
manually.  Imagine this situation: DC where primary server is looses
network only partially. Because of it, I'm unable to access the server
(and it can't see peer either) and I think that that server is offline
although that server is still visible from some other locations. I
promote secondary server to primary, change DNS records and now, until
DNS servers are propagated to the whole world there will be two primary
servers. That's why I thought that it would be good to make primary
server demote itself in cases like this.

More information about the drbd-user mailing list