[DRBD-user] 3 simple questions for a nifty setup

paddy paddy at panici.net
Wed Aug 24 21:01:58 CEST 2005

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

On Wed, Aug 24, 2005 at 07:59:44PM +0200, Lars Ellenberg wrote:
> / 2005-08-24 18:34:25 +0100
> \ paddy:
> thank you for this nice little summary.
> some notes:
> note that a softlink from /var/lib/mysql to some directory on the drbd
> volume would be fine, too.

yeah, when my system grows up :)

Actually, there's a rough edge here around what happens if mysql gets 
started (say by accident) on the secondary. (Sorry, thinking out loud)

> > I've cobbled together a nasty trick with bind to fail over a dns name, so 
> > that a writer can access the db from the secondary node. 
> use an alias ip as service address, and fail over the ip.  have this
> cluster ip address in dns.  nobody cares which of the nodes currently
> has the cluster address.

I had originally planned to use ip failover, but thats shelved for now.
Agreed its the obvious way if you have the option, I should have thought 
to mention it.

> > There is also the issue of whether a commit propagates correctly.  My assumption
> > would be that mysql would return from a commit only after some reasonably 
> > conservative effort has been made to write the necessary data to disk and 
> > that drbd protocol A will thus guarantee that the commit is written both sides.
> protocol _C_ is the transaction safe one.
>   A --> asynchronous (unsafe),
>   C -> commit safe (synchronous),
>   and B somewhere in between...

Oops !!!

I've just checked and I am in fact using Protocol C.

Sorry, I was shooting from the hip there :)

IIUC, even Protocol B is fairly conservative and might be of interest to someone
looking for this sort of replication ?

> > > Anybody actually doing this?
> > 
> > yes :)
> sure.

A weight is lifted from my shoulders ;)

I'm certainly interested to hear of others experiences with such setups.

> > Sorry, I missed the bit earlier about having multiple secondaries in drbd.
> > 
> > As you know, I had assumed that this is not possible with 0.7, but I don't
> > recall exactly why.
> in short, because reliable multicast is tricky.

I have only heard of it.

Do you get all the magic out of the networking or do you have to do 
more work in drbd itself ?

> we have paying customers where we do a "tripple legged, two secondary" setup,
> but that is currently no so much for availability than for desaster recovery
> backup purposes.

What happens at fail-over ? are they primary/secondary/tertiary ?

Perl 6 will give you the big knob. -- Larry Wall

More information about the drbd-user mailing list