Re: Bidirectional replication

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

>>> Yeah. One nasty property that async multi master solutions share is
>>> that they change the definition of what 'COMMIT' means -- the database
>>> can't guarantee the transaction is valid because not all the
>>> supporting facts are necessarily known. Even after libpq gives you
>>> the green light that transaction could fail an arbitrary length of
>>> time later, and you can't rely in the assumption it's valid until
>>> you've done some synchronizing with the other 'masters'. Maybe you
>>> don't need to rely on that assumption so a 'fix it later, or possibly
>>> never' methodology works well. Those cases unfortunately fairly rare
>>> in the real world.

>> I don't quite follow you here. Are you talking about *synchronous* multi-master?
>> Async multi-master works just fine, as long as you are not expecting the
>> servers to give the exact same answer at the exact same time. But certainly
>> transactions are "valid".

> Lets say you have a foreign key constraint on delete restrict. On one
> master you delete the key as there are no child entities. On the other
> master you add a child entity, which should prevent deleting the parent
> record. Both masters allowed the transaction to be committed, which
> means that the users have both been given acknowledgement that their
> actions are valid. If the rules are that the guy who put in the child
> wins that means the committed delete never happened. If the parent wins
> that means that the insert of the child was illegal.

Well, that's one way to look at it, but you have to remember to treat the
async replication as the invisible hand of another session, that may
change what you have just committed, just like any other user may. If I
add a child entry, then user X deletes said entry, and then user Y deletes
the parent entry, that is for all intent and purposes the same as what happens
in a replication scenario. The difference is that technically I add the child
entry, user Y deletes said entry, and /then/ user R (replication) deletes both
the parent and child (or inserts the parent back in). But in both cases, both
the child creator and the parent deleter receive back a "ok commit". If you
have a very large async response time, and your application has a very tight
control over things, it may cause a problem, but in real life the syncing
happens quite quickly, and the window for even catching both writes, not to
mention sorting it out, is quite small. And I would expect an application
running against a MM database would be able to handle such events anyway.

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

iEYEAREDAAYFAk3hwKIACgkQvJuQZxSWSsgu9gCgpBrlVa5xvmRNdIdcstlv60oJ
tQsAn0sPvDHNZI+CVIT46SP4mEP7aGLM
=4c4P
-----END PGP SIGNATURE-----