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 mine: node1 drbddisk::r0 IPaddr::192.168.0.123 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. > same <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 David > 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! > >