Re: Bidirectional replication

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Bidirectional replication
Date: 2011-05-09 02:56:16
Message-ID: 4a83df22737d0b04a558185d9fb46288@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> 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]

Yeah, I've talked with Jan about the similarities and differences
between eserver and Bucardo. Seem philosophically simliar, although
a bit diverged technically at this point.

> 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).

Not sure I really see why this is important. You mean as far as the
fact that tables X, Y, and Z are in a replicated set, but client A
makes changes to X and Y, and then client B makes changes to table
Z, and thus Bucardo slurps in X, Y, and Z, but never as client A
or B saw them? Any client connecting to the master after client
B commits would have the same "problem", no?

> [1] The code is still hanging around somewhere, I think, mostly
> as an example of what not to do.

Heh, I gotta look that up someday.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201105082255
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAk3HV7wACgkQvJuQZxSWSsg23wCfemaF8EBf58C47omG0Fc8TMeb
WB4AoIZPZ57zDKLfoJ/wN2CFpUbQuq3k
=CrQ3
-----END PGP SIGNATURE-----

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sim Zacks 2011-05-09 04:12:44 Re: Bidirectional replication
Previous Message Greg Sabino Mullane 2011-05-09 02:44:24 Re: Bidirectional replication