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,
atsome arbitrary point (every 5 minutes...) a process wakes up, sees what records have changed at the local node, uses
thisto create an update set, and then propagates the changes to other nodes. Where their stuff is impressive is
subscribingto 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
ofrecords from lots of related tables. This is neat. Also, they can detect basic conflicts and apply simple
resolutionrules. More interestingly, they can avoid a lot of conflicts by creating "fragments", which are a set of
columnsfrom 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
willnot 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
distributingreads and a few writes across a WAN.
-----Original Message-----
From: Christopher Browne [mailto:cbbrowne@acm.org]
Sent: Saturday, March 19, 2005 6:55 AM
To: pgsql-advocacy@postgresql.org
Subject: Re: [pgsql-advocacy] What do Oracle, DB2, etc. actually *do*?
In an attempt to throw the authorities off his trail, neilc@samurai.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