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

I'm quite familiar with what Peer Direct sells.

Their software is strictly async. It depends upon having each record maintain the timestamp of its last change. Then, at some arbitrary point (every 5 minutes...) a process wakes up, sees what records have changed at the local node, uses this to create an update set, and then propagates the changes to other nodes. Where their stuff is impressive is subscribing to subsets of the data and handling conflicts. They can allow a node to subscribe to just certain sets of records, usually determined by some high level key (like a country code) and then follow all FK constraints to pull lots of records from lots of related tables. This is neat. Also, they can detect basic conflicts and apply simple resolution rules. More interestingly, they can avoid a lot of conflicts by creating "fragments", which are a set of columns from a table that are treated as a whole (name fragment = {first name, middle initial, last name}, address fragment = {street, city, state, zip, country}). If you configure it right, a change at node 1 to the address fragment will not conflict with a change to the name fragment at node 2.

It is not optimal if all you are interested in is failover. It is a good solution if your fundamental problem is distributing reads and a few writes across a WAN.

-----Original Message-----
From: Christopher Browne [mailto:cbbrowne(at)acm(dot)org]
Sent: Saturday, March 19, 2005 6:55 AM
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: [pgsql-advocacy] What do Oracle, DB2, etc. actually *do*?

In an attempt to throw the authorities off his trail, neilc(at)samurai(dot)com (Neil Conway) transmitted:
> William Yu wrote:
>> Here's my question about "multi-master" replication whether it's
>> Oracle or not. How in the world does it work over high latency, low
>> bandwidth connections w/o getting pummelled in performance?
>
> Well, it may well be the case that it doesn't work :) Not all kinds of
> replication are appropriate for all situations, and I agree that
> synchronous, multi-master replication isn't likely to be useful in the
> situation you describe.
>
> 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.

PeerDirect is marketing something that sounds like that...
<http://www.peerdirect.com/products/data_replication_engine/index.ssp>

This sort of "after the fact data synchronization with conflict
resolution" bears marked similarities to:

a) The way PalmOS systems address syncing between a handheld computer
and potentially multiple desktop machines.

It's often most convenient to cut'n'paste changes to things into
one's "Palm Desktop" software because you have higher-bandwidth
input devices like keyboards and mice as compared to scribbling
with a stylus.

I can make changes to data at home or at the office, and when I
HotSync to my PDA, the data starts flowing towards those places it
hasn't been yet...

b) The way Lotus Notes(tm) allowed you to set up queues of messages.

You could update/add material offline, and then "sync up" which
would push/pull changes.

Slony-I and Slony-II won't be doing that, which means that there's
room for someone with interest to have a further usefully-distinct
form of replication.
--
let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/slony.html
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend