[DRBD-user] 3 simple questions for a nifty setup
paddy at panici.net
Thu Jun 30 21:34:49 CEST 2005
I'm no expert, but I am doing similar things so I'll have a stab at
some answers for you.
On Thu, Jun 30, 2005 at 08:43:48PM +0200, ephigenie at g-house.de wrote:
> Hello Everyone,
> I've managed to get drbd-07.11 to work with 2 sarge boxes,
> but there a few questions open at this point :
> whenever i try to mount the drbd/0 device on the secondary,
If I understand you correctly, the answer is: you shouldn't do that.
nevertheless I got the impression that you could ...
> i get the following ...
> but the device is not mounted (according to /proc/mounts & mtab etc..)
> the mountpoint has no influence on that behaviour since when i try
> an other one, it works ?
sorry don't understand those last two lines (above). Do you mean you can
mount it okay on the primary ?
> www-2:/# mount -t ext3 /dev/drbd/0 /ha/
> mount: block device /dev/drbd/0 is write-protected, mounting read-only
> mount: /dev/drbd/0 already mounted or /ha/ busy
aren't mount(1) error message great !
> the second one :
> i'd like to make some webspace ha - this should work i think
> but as I'm lazy, i concidered using drbd for a mysql instance
> but there's my question - are there any problems known with that ?
Don't know if there are know problems but I have such a setup on a sarge testbed
it seems to work (very simple testing), and I'd be happy to share my config with you.
My assumptions are:
If drbd does what it says on the packet, then when you start mysql after failover
it shouldn't be any worse than if you restarted after, say, a power failure.
I don't how big (or how long) problems might be if mysql do its equivalent of
fsck, so that's a worry. By the looks of it mysql replication is not without
its complications and the cluster mode is out of the question for my application.
Having said that, I plan to try out mysql replication and compare the results.
Since IIUC mysql replication is asyncronous, drbd might even be better for some
values of better.
> for sure i will sort all writeaccess out and direct it to the master
reads too, with drbd you're only going to have one mysql instance accessing the
database at a time. I've yet to figure out what happens at the client when the
connection to the primary get lost, but I expect it'll be okay :)
> but this seems to me more smart than using the mysql - replication
I guess it depends on your load. If you are doing a lot of reads then I imagine
replication could be a big win.
> Is there anyone who has this as a working setup or has experiences with that ?
> the third one :
> at the moment there are only 2boxes, but a third and a forth a prepared ...
> but i searched the half web for that and had nothing found -
> so is it possible to have 1 primary and 3 or more secondarys ?
> What about choosing the next primary - can heartbeat do that job - or is
> this just for the head-to-head config everywhere mentioned with 1 primary and 1
> secondary ?
my understanding is that drbd will only do 2 machines, although I'd be delighted
to learn otherwise. One of the temptations of mysql replication for me is the
ability to form larger networks of replicas.
There are other similar technologies that do different things. I don't any
experience with them, (so these are _not_ recommendations) but an ipcomplete
list I'm sure:
GNBD/GFS comes to mind as an example of a clustered filesystem
where you can mount and write at more than one node. I don't know whether
you can run multiple mysql servers against the same backend (perhaps with
a master for the writes ?), somehow I doubt it. IIRC its in unstable but
not sarge (not stable upstream).
ENBD (looks similar to DRBD)
There's also stuff like AFS and coda. Intermezzo looked interesting for a while there.
postgresql appears to have similar features to mysql.
of course, its horses for courses.
> thanks for your help
hope this does help :)
Perl 6 will give you the big knob. -- Larry Wall
More information about the drbd-user