Re: [GENERAL] replication choices

2007-02-06 Thread Andrew Sullivan
On Thu, Jan 25, 2007 at 12:17:52PM -0800, Ben wrote: familiar with Slony, and from what I understand, using Slony with bad networks leads to bad problems. I'm also not sure that Slony supports replicating from multiple sources to the same postgres install, even if each replication process

Re: [GENERAL] replication choices

2007-02-06 Thread Andrew Sullivan
On Wed, Jan 31, 2007 at 03:17:40PM -0800, Ben wrote: the remote sites back to the central site, each remote site needs to have a normal slony node first, which I don't have the hardware for. An answer for this, though a dirty kludge, is to replicate to another database in the same cluster.

Re: [GENERAL] replication choices

2007-02-06 Thread Ben
Yeah, log shipping looks like it solves the network problem, except for the part about how how I must replicate to a normal slony node before I can get logs to ship. We don't have the hardware to have a secondary database at every site. :( On Tue, 6 Feb 2007, Andrew Sullivan wrote: On Thu,

Re: [GENERAL] replication choices

2007-02-06 Thread Ben
Just to be clear, this effectively means I double my database writes, correct? On Tue, 6 Feb 2007, Andrew Sullivan wrote: On Wed, Jan 31, 2007 at 03:17:40PM -0800, Ben wrote: the remote sites back to the central site, each remote site needs to have a normal slony node first, which I don't

Re: [GENERAL] replication choices

2007-01-31 Thread Lenorovitz, Joel
I believe I have a similar situation involving multiple database instances acting quasi-independently on a common (at least conceptually) set of data. Since each instance can effectively operate independently, I am uncertain if the term replication is accurate, but here is my strategy to keep the

Re: [GENERAL] replication choices

2007-01-31 Thread Guido Neitzer
On 31.01.2007, at 14:53, Lenorovitz, Joel wrote: I do not know of any product, Slony included, that has built in support for a situation such as this, so I suspect all of the details will have to be handled in a custom fashion. It is not relevant for you as your are using PostgreSQL (for

Re: [GENERAL] replication choices

2007-01-31 Thread Ben
Well, it sounds like your situation is more difficult than mine, in that it looks like you might have to deal with the possibility of conflicting changes. Fortuantely, I don't have that issue, because even though I have data flowing both ways between my master and my sites, it only flows one

[GENERAL] replication choices

2007-01-25 Thread Ben
Hi guys. I've inherited a system that I'm looking to add replication to. It already has some custom replication code, but it's being nice to say that code less than good. I'm hoping there's an existing project out there that will work much better. Unfortunately, I'm not seeing anything that

Re: [GENERAL] replication choices

2007-01-25 Thread Bruce Momjian
Have you read the 8.2 documentation about this: http://www.postgresql.org/docs/8.2/static/high-availability.html --- Ben wrote: Hi guys. I've inherited a system that I'm looking to add replication to. It already

Re: [GENERAL] replication choices

2007-01-25 Thread Ben
Yes, but unless I'm missing something, it doesn't look like any of those options perfectly fit my situation, except perhaps Slony, which is why I'm leaning that direction now despite my concerns. Is there a section of this page I should be re-reading? On Thu, 25 Jan 2007, Bruce Momjian wrote: