|
Actually, because of that problem, we are writing a little daemon which
occasionally searches for duplicate records (as our sql statements are
mostly inserts and updates, where a duplicate update would simply write the
same info twice). A final plan on the drawing boards is to have a master
dispatch daemon, and slave daemons on each DB server, with the master daemon
multicasting the updates so that you can scale the system farther. If any of
that sounds useful, or you can think of other things to add, let me know.
-Sean Ward
----- Original Message -----
From: Jean-Christophe BOGGIO <cat@xxxxxxxxxx>
To: Sean Ward <SeanWard@xxxxxxx>; <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, April 04, 2000 5:54 PM
Subject: Re: mysql through lvs?
> ----- Original Message -----
> From: "Sean Ward" <SeanWard@xxxxxxx>
> To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, April 04, 2000 5:33 PM
> Subject: Re: mysql through lvs?
>
>
> > Actually, I ran into the same problem (ie, load balancing and scaling
> mysql)
> > recently. The way that I solved this is I wrote a sql dispatch daemon,
> which
> > can execute a sql statement concurrently on several backend systems.
Then,
> I
> > rewrote my app so that it seperated reads from writes. Basically, what
my
> > program now does is track a set of open connections to mysql servers,
and
> > how many requests are pending on each, and when a new request comes in,
it
> > choses the least weighted connection, and processes all the reads along
> > that. Any writes which are required (I have a high read/write ratio) are
> > written to a file, which is then picked up by the dispatch daemon, and
> > executed in parallel across the server. The dispatch daemon also has the
> > advantages that because it records a global log of changes, I can bring
a
> > new server into sync my snapshotting another server's DB files, and then
> > replaying the log from the time of the snapshot.
>
> This looks like Oracle's redo logs. It's a very clever method but it has o
ne
> drawback : if reads occur in the period of time between the 'demanded'
write
> and the actual database update, they won't reflect the changes,
particularly
> if the server is highly loaded (because it will take longer to process the
> logs). In Oracle, this technique is used for backup and repair purposes
like
> you do. Some applications dont need to immediately reflect changes and
there
> the method is excellent.
>
> > If that kind of arrangement
> > is of any help to you, check out lsdproject.sourceforge.net where I've
> stuck
> > up the source for the dispatch deamon. I'll probably have the read only
> > connection balancer up there too in a few days, depending on interest.
The
> > problem I found with using LVS for load balancing was the need to create
a
> > new connection for each request (a slow operation) to get the new
> connection
> > load balanced. Its faster to have a pool of open connections and balance
> > between them in user land.
> > -Sean Ward
>
> Thank you for providing this code !
>
> Jc
>
>
>
>
>
|
