Re: What do Oracle, DB2, etc. actually *do*?
От | Lance Obermeyer |
---|---|
Тема | Re: What do Oracle, DB2, etc. actually *do*? |
Дата | |
Msg-id | 072BDB2B234F3840B0AC03411084C9AF61DCB1@ausmail2k2.aus.pervasive.com обсуждение исходный текст |
Ответ на | What do Oracle, DB2, etc. actually *do*? (Tim Smith <reply_in_group@mouse-potato.com>) |
Список | pgsql-advocacy |
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
В списке pgsql-advocacy по дате отправления: