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@crankycanuck.ca