Re: Bidirectional replication

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: Bidirectional replication
Дата
Msg-id 4a83df22737d0b04a558185d9fb46288@biglumber.com
обсуждение исходный текст
Ответ на Re: Bidirectional replication  (Andrew Sullivan <ajs@crankycanuck.ca>)
Список 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@turnstep.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-----



В списке pgsql-general по дате отправления:

Предыдущее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Bidirectional replication
Следующее
От: Sim Zacks
Дата:
Сообщение: Re: Bidirectional replication