From: | Mike Christensen <mike(at)kitchenpc(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: peer-to-peer replication with Postgres |
Date: | 2010-05-11 02:00:40 |
Message-ID: | AANLkTilrBZ69QP6uAGPrh2sxzjxxxXNvMDBIN3EWRDX7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
The concept of updating one database and doing all your reads from
another database is kinda confusing to me. Does that mean you have to
design your whole app around that concept, have a different connection
string and what not for your "writable" database and "read-only
databases"? I'm using Castle ActiveRecord which I'm not even sure
supports that (without a ton of custom code anyway).
Is there any sort of abstraction layer (like in the driver level) that
can abstract that and just make updates go to one DB and reads
round-robin to other DBs? Hopefully there's a way to make this design
simple to implement.
Mike
On Mon, May 10, 2010 at 6:23 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Mon, May 10, 2010 at 7:21 PM, Mike Christensen <mike(at)kitchenpc(dot)com> wrote:
>> Man that sounds awesome. I need that now. So does that mean you'd
>> have one beefy SQL server for all the updates and everything writes to
>> that, and then you'd have a bunch of read-only servers and new data
>> trickles into them from the master continuously?
>
> Yep. You can also do something similar but less efficient now with
> slony or some other replication engine. But they're less simple to
> set up and usually less efficient than log shipping.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2010-05-11 02:14:35 | Re: peer-to-peer replication with Postgres |
Previous Message | bricklen | 2010-05-11 01:45:38 | Re: Archiver not picking up changes to archive_command |