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. Cool! What happens at fail-over ? are they primary/secondary/tertiary ? Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall