On Mon, Sep 09, 2002 at 12:35:10PM -0500, Jeremy Tinley wrote:
> This handles part of the problem but a true load balanced master
> solution is needed. There's no real advantage in spending 5, 10 or
> $20,000 on a failover master if you can't load balance and the spare
> will just sit idle.
Sure there is. If your master blows up, you have a spare waiting to
take its place. It may not solve your problem, but it is a "real"
advantage for some folks.
> Master servers should intelligently talk to each other and determine
> duplicate key problems.
What if the masters are a few thousand miles apart with 80-120ms
network latency? You may gain some load-handling capabilities (in
theory), but you're got a serious bottleneck to deal with.
> You could create an LVS cluster of masters. You would have to write
> some hand code to remove a master from the cluster when it is behind
> so when a master is brought back up, it's out of the cluster until
> it has caught up.
And that's not terribly difficult to do as long as you have a
reasonable definition of "behind".
> Then toss in some code to sync the downed master with the current
> running ones.
Instead of using MySQL's native replication?
> Perhaps you could point replication to the LVS IP instead of a
> specific machine. When it comes back up, it will find a valid
> master to connect to via LVS, replicate, and then rejoin the
> collective... err, cluster. :)
The trick is to make sure that all the masters have EXACTLY the same
data in their binary logs (give or take the server-id).
Jeremy
--
Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo!
<Jeremy@stripped> | http://jeremy.zawodny.com/
MySQL 3.23.51: up 34 days, processed 686,097,244 queries (230/sec. avg)
