[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: High Availability.. (SQL server)



Yes, we've faced this problem and are planning a solution.
We've not coded anything yet, but have plans for a couple of months.  Maybe
it could be an Open Source project if there's nothing pre-existing.  I'd
want the daemon interfaces to be DB independant.

Basic idea is to seperate the Queries from the Updates.
Queries use local mysql DB, tracking is done asynchronously through a perl
daemon, that queues, then sends the writes in batches, to reduce number of
transactions.

The Master DB is not truly redundant, but would have hot spare, the fault
tolerance comes in from the buffering introduced by the daemons, and
queueing system.

Rob

----- Original Message -----
From: "Christian Hammers" <ch@westend.com>
To: "Jason Hammerschmidt" <Jason.Hammerschmidt@MacLaren.com>
Cc: <debian-isp@lists.debian.org>
Sent: Friday, October 06, 2000 10:24 PM
Subject: Re: High Availability.. (SQL server)


> Hello
>
> Has anyone ever tried to make a webserver host with a mysql database
> (used for a session database that gets updated on every click) redundant
> by adding an exactly same computer and do DNS-load balancing?
>
> If there were no SQL database this would be no problem, two web-servers
> that access a shared NFS Raid for data. But you can't have two MySQL
> daemons access the same files and if you have only one SQL server for
> both web servers there is no redundancy. On the other side if you have
> two seperate mysql servers there is no synchronising between them, I
> know about that update-log method but when serving a couple of clients
> per second I doubt that the two servers syncronise fast enough to allow
> using a session-db (imaging first request on A, then second request on B
> but B's mysql server hasn't updated the mysql db and so the session
> information are lost).
>
> Any ideas?
>
> bye,
>
>  -christian-




Reply to: