Re: What do Oracle, DB2, etc. actually *do*?

Neil, William,

> One solution to multi-master replication on slow networks (or networks
> with nodes that are only intermittently connected) is to be very
> asynchronous: transaction commit only affects the local node, and
> conflict resolution is done when replicating changes later. This is more
> useful for filesystem replication: it is easier to do after-the-fact
> conflict resolution, although it is still very complex. ISTM it should
> be possible with DBMS replication, at least in theory.

Actually, Sybase tackles this issue a different way .... one that, I may add,
could be done with Slony-I with a little back-end glue.   Basically, they
make each replicated node the "master" of one subset of data; for example, if
it's a personnel database, then all personnel records for each office
location are "mastered" at that office location.   If you're updating records
at your current location (which is assumed to be the majority of updates) it
goes in direct and cascades out to the other servers; if you update records
for a different office, it goes to their server across the wire and cascades
back to you asynchronously.

Obviously, this only works for distributed applications where such
partitioning of data is reasonable, but that actually covers a lot of
real-world WAN distributed databases.   Point-of-Sale, for example, as well
as HR.

--
Josh Berkus
Aglio Database Solutions
San Francisco