Re: Replication & web apps - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Replication & web apps
Date
Msg-id 1142540129.3047.24.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: Replication & web apps  (Brad Nicholson <bnichols@ca.afilias.info>)
List pgsql-general
On Thu, 2006-03-16 at 13:18, Brad Nicholson wrote:
> Jeff Amiel wrote:
>
> > There are other techniques to balance the load of the database calls so
> > that some go to one box and some to others, yet keep the data in synch...
> > Continuent makes a commercial p/cluster product  as well as an open
> > source product called Sequoia that sit in the JDBC layer and direct
> > traffic and control the load balancing.
>
> pgpool allows you to load balance queries between two servers.  While it
> doesn't solve the issue of trying to read a row that hasn't been
> replicated, it does offer you a bit of control that may be of use to
> you.  Any statement that is in a transaction will automatically go to
> the master DB.  If some queries are sensitive to this issue, and some
> aren't, then you might be able to make pgpool work for you by wrapping
> the sensitive ones in a transaction.

Note that it's also possible to use pgpool as a synchronous clustering
too with automatic failover.  Since it is statement based, you have to
make sure both DBs are in exactly the same state when you start it up,
and you can't rely on things like now() being exactly the same, nor on
random() and a few other things.

however, for many applications, this is plenty good enough, and it's
dirt simple to setup and use.

pgsql-general by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: will slony work for this ?
Next
From: Stephen Frost
Date:
Subject: Re: ERROR: FULL JOIN is only supported with merge-joinable join conditions