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

David david at davidbranford.net
Wed Aug 24 20:08:19 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.

> -----Original Message-----
> From: drbd-user-bounces at lists.linbit.com
> [mailto:drbd-user-bounces at lists.linbit.com]On Behalf Of paddy
> Sent: Thursday, 25 August 2005 3:04 AM
> To: DRBD List
> Subject: Re: [DRBD-user] 3 simple questions for a nifty setup
> On Thu, Aug 25, 2005 at 12:46:30AM +0930, David wrote:
> >
> > Thanks paddy for your reply. I think I am better understanding the
> > differences
> Glad to help.  Hope I've not mislead you :)

not at all...

> > - I am not after the full-scale mysql clustering solution; I
> > don't need it/have the resources.
> I'd love to know what its for.

our in-house mailserver & webserver, actually - nothing huge, by any means,
but it is a production system with a hundred or so users so I gotta get it
right ;) Currently it runs on one physical server and I would like to make
it a two-server heartbeat setup 'cause things have died before... (hard
drives, those kind of things :)

> > What do you mean when you say you have mysql running on top of
> drbd? Have
> > you got both PC's mysql data directories separate, or do they
> share the same
> > data files? (ie. /mnt/drbd0/var/lib/mysql)
> yes.  I have an ext3 filesystem which I mount on /var/lib/mysql.
> It is mounted on the primary side and my haresources looks like:
> node1  drbddisk::r0  Filesystem::/dev/drbd0::/var/lib/mysql::ext3  mysql
> node2
> (removing some extraneous noise for clarity)

Interesting - just what I imagined! It's great to hear that it is working
for you (so far...) - this *might* actually be possible


node1 drbddisk::r0 IPaddr::
Filesystem::/dev/drbd0::/mnt/drbd::ext3 mysql apache

out of interest, anybody know if it's bad to sym-link /var/lib/mysql to
/mnt/drbd/mysql, rather than actualy mounting it in the place mysql is
expecting its data dir? (ie. actually mount it at /var/lib/mysql)

> heartbeat takes care of the dependencies, there is a drbd init.d script
> but neither the filesystem mount nor mysql are started by the
> regular init.


<snip />
> where mysqld_status() is just cribbed from the code in the debian
> init.d script.
> The debian init.d script seems to handle the mysql fsck :)

what does it do for mysql fsck? is this a mysqlcheck --auto-repair ?

> 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.
> I've seen mysql fsck and complain a couple of times so far,
> without any apparent harm :)  Not seen any problem at the filesystem level
> yet (nor do I expect to, it seems to be well tested).

so far, so good... :)

> For my application (simply logging - unrelated inserts a row at a time)
> its even possible for the whole setup to go split brain (as it has done
> a couple of times) with minimal pain to me.  I just dump the extra records
> on one side, resync and then load the dump in.   It's so absurd that I'm
> almost ashamed to admit it, but it does what I want. I'm also fortunate
> that there are various secondary systems which would enable me to rebuild
> the database without loss if it all went horribly wrong.
> Not exactly your average database problem ;)
> To be honest, I'm not even watching it terribly closely right now.
> It could be going wrong and I just haven't noticed :)
> (actually, I'm aware of bugs elsewhere, so it's not just a question of
> whether it goes wrong, but what goes wrong and how often, which is why
> its more dificult for me to be certain that there isn't a problem
> with the mysql over drbd part of iti. That and I'm working on other
> things :).

so many problems... so many solutions. I think your solution sounds ideal;
lot simpler than mysql cluster/replication. Although it would be a different
story perhaps if mysql replication handled automatic master selection.

> > I was wondering if such a setup as the latter is possible,
> since it seems
> > logical to me and pretty straight-forward; if a server running mysql
> > crashes, it must reboot and recover. If the primary server of a
> two-server
> > heartbeat "cluster" crashes, same thing - it's just a different machine
> > which must recover from the cluster, it is not privy to any
> extra/different
> > information... or is it?
> This is pretty much my reasoning too.
<snip />
did I read
> something
> on this list about fscking a journalled filesystem here recently ?

ah yes

> 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.
> It is an assumption based entirely on imagination, without
> foundation in research.
> By comparison, my best understanding of mysql replication was
> that a commit
> could get lost if the master crashed before it propagated to a slave.
> (I could be wrong on this. I'd be happy to be corrected).

I think the data is simply stored on the master in the binary log and the
connection between master & slave is non-crital - ie. doesn't have to be
maintained constantly; the slave just connects ad-hoc and re-syncs using its
latest records for reference

> Other possible pros and cons include:

<snip snip/>

you have obviously considered a lot more about such a setup than I have; I
was simply hoping that with drbd's reported performance re.
stability/reliability and "protocol A" it would be fairly reliable (fairly =
reliable enough for me)

> > Does anybody see any danger with this proposed setup?
> yes :)
> > Anybody actually doing this?
> yes :)

well i'll hopefully soon add to them :)

> > What do you mean by mysql on drbd - could you say (briefly) how you have
> > mysql running on drbd (ie. which files are available to which servers?)
> I hope I covered this above.  Feel free to enquire further on any details.

yes you did, and thanks

> 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.  I'm not in a position to try it out right now, but I
> am interested to hear whether it works.

hopefully i will have an opportunity to try in a couple of days - i'll post
my results

many many thanks for your valuable help/information


> Regards,
> Paddy
> --
> Perl 6 will give you the big knob. -- Larry Wall
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
> !DSPAM:430cafba47401497720507!

More information about the drbd-user mailing list