Re: Bidirectional replication

From: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Bidirectional replication
Date: 2011-05-06 12:59:18
Message-ID: 20110506125917.GB29489@shinkuro.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, May 05, 2011 at 09:22:14PM -0600, Joshua Tolley wrote:

> course, but it is trigger based. One notable difference between Bucardo and
> Slony is that whereas Slony's triggers store the entire row data in a separate
> log table when something changes, Bucardo stores only the primary key.

That's interesting. An earlier replication system we had at Afilias
(erserver, which was descended from the rserv code that used to be in
contrib/) used this strategy.[1]

I liked to distinguish between the "latest consistent data" strategy
and the "logical order application" strategy.

There are some advantages to the latest consistent data strategy, the
greatest of which is that you don't get the "lag" problems. Under
Slony, you have to capture all the state between the last replication
sync and the current one, even if there are multiple changes to the
same row.

There is a problem, however, in that if you want to use your replica
to capture various changes along the way, you can't do it. Moreover,
there's no guarantee under such a system that your replica is ever
consistent with the way a given _client_ saw the database (there is a
guarantee that it is consistent with some database state on the
master, of course, but not a guarantee that it ever looks just as a
client would have seen it at the moment of the client's action).
These two counter-considerations were among the things that made the
erserver strategy undesirable from my point of view given what we were
trying to do at Afilias at the time. So that's why I was happy we
changed direction with Slony. (But that decision came with its own
complications.)

A

[1] The code is still hanging around somewhere, I think, mostly as an
example of what not to do. For instance: copying entire result sets
into memory and them sorting them is a bad idea. Also, if someone
imposes on you a programmer you are fairly sure doesn't understand the
problem you're working on, you should quit on the spot. (I have to
keep relearning this one, though.)

--
Andrew Sullivan
ajs(at)crankycanuck(dot)ca

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vick Khera 2011-05-06 13:15:37 Re: Bidirectional replication
Previous Message Mark Morgan Lloyd 2011-05-06 12:38:22 Re: ZEOS or PGDAC - How to lock a resource?