Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Aug 25, 2005 at 03:38:19AM +0930, David wrote:
>
> > > - 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 :)
Interesting to hear, similar sort of thing here.
But actually I meant "I'd love to know what the full scale mysql clustering
solution is for" :) But only because I don't have the RAM :)
> 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)
Theres always interesting ways to shoot yourself in the foot, even when
you add only a little complexity, (or maybe thats just me ;)
but no I see no special reason why not.
Indeed that is what you will likely want to do in the real world
and Lars suggests exactly that elsewhere in this thread.
> > The debian init.d script seems to handle the mysql fsck :)
>
> what does it do for mysql fsck? is this a mysqlcheck --auto-repair ?
no idea, but I'll have a look ....
from /etc/init.d/mysql:
/usr/bin/mysqld_safe > /dev/null 2>&1 &
for i in 1 2 3 4 5 6; do
sleep 1
if mysqld_status check_alive nowarn ; then break; fi
done
if mysqld_status check_alive warn; then
echo "."
# Now start mysqlcheck or whatever the admin wants.
/etc/mysql/debian-start
else
echo "...failed."
/bin/echo -e "\tPlease take a look at the syslog."
fi
eek!
mysqld_safe says:
#!/bin/sh
# Copyright Abandoned 1996 TCX DataKonsult AB & Monty Program KB & Detron HB
# This file is public domain and comes with NO WARRANTY of any kind
#
# scripts to start the MySQL daemon and restart it if it dies unexpectedly
So I'll imagine you have that.
I notice a bit that says
# Uncomment the following lines if you want all tables to be automatically
# checked and repaired during startup.
they aren't.
/etc/mysql/debian-start seems to be a wrapper to run mysqlcheck in the background
and syslog/send you mail about the problems.
By the looks of it the answer to your question is no.
I don't pretend to see deeply into this, but I'm keen to learn what others
with more experience think. In any case, I suppose I better go read the
source ...
> 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.
If the database was all I wanted to do then I might have headed in that
direction. When I have the time I will at least look into it.
> > did I read something
> > on this list about fscking a journalled filesystem here recently ?
>
> ah yes
perhaps I better go reread that !
> 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
I only skimmed the docs but I had the impression that updates were pushed
from the master initially. Certainly that would seem like the obvious thing
to do. Why they didn't just make the commit wait or timeout on
acknowledgement is beyond me, but if it is as you describe then that could
be a reason.
> you have obviously considered a lot more about such a setup than I have
Sadly its just off the top of my head.
Don't mistake it for sage advice. Sage advice is much shorter. :)
> 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)
I didn't mean to scare anyone off. I wouldn't spend time on drbd if I weren't
hugely impressed. At the same time, reliability is tricky to engineer, and
different problems have different requirements, so I figure maybe its useful
to unpack a few assumptions and to share ideas & experiences with others.
> > > Anybody actually doing this?
> >
> > yes :)
>
> well i'll hopefully soon add to them :)
Welcome aboard :)
> > 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
a brief howto is always good thing ... ;)
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall