I think having only one writer greatly simplifies things, but it also
provides a single point of failure, which I think kills the idea for me.
I've had too many experiences with network trouble in different areas where
the west coast goes down, but east coast is still reachable, or Dallas goes
out or something.
----- Original Message -----
From: Peter Galbavy <[EMAIL PROTECTED]>
To: Rich Ryan <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 28, 1999 1:31 AM
Subject: Re: [ADMIN] HSA (Highly Scalable Architecture) Distribution and
replication
> On Thu, Oct 28, 1999 at 01:11:32AM -0700, Rich Ryan wrote:
> > Has anyone written a HSA e-commerce solution using postgres? In english,
> > this means I want more than one server running postgres with the same
> > database(s). I get lots and lots of queries, and it's just too much for
one
> > poor machine to handle. I get far less inserts, updates, and deletions,
but
> > regardless, the DB's have to be synchronized every couple hours. If I
can't
> > find any HSA to start from, then I'll start from scratch, but I thought
I'd
> > ask first. If I start from scratch, an initial architecture that comes
to
> > mind is designating one server as the master, and the others as slaves.
> > Every slave gives the rows to be replicated (since the last replication)
to
> > the master at a configurable interval. When the master has been served
by
> > all the slaves, he then synchronizes everyone...I read somewhere that
this
> > is one of the advantages Oracle has over Postgres, but that in a year
> > Postgres should have an HSA solution. Is anyone working on this? Maybe
we
> > could start?
>
> There must be better ways of doing it, but we thought of using a
> transaction log from a *single* central update server (writer) to
> update multiple readers, running in '-F' mode. Not yet tried it.
>
> Regards,
> --
> Peter Galbavy
> Knowledge Matters Ltd
> http://www.knowledge.com/
>
> ************
************
