home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6253 < prev    next >
Encoding:
Text File  |  1992-08-21  |  2.8 KB  |  57 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!decwrl!world!edwards
  3. From: edwards@world.std.com (Jonathan Edwards)
  4. Subject: Re: distributed transactions
  5. Message-ID: <BtDA1n.JrB@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <1736k9INNjhh@agate.berkeley.edu> <BtCrA6.Iuy@cup.hp.com> <173oogINNmrp@agate.berkeley.edu>
  8. Date: Sat, 22 Aug 1992 04:05:46 GMT
  9. Lines: 46
  10.  
  11. In article <173oogINNmrp@agate.berkeley.edu> mao@triplerock.CS.Berkeley.EDU (Mike Olson) writes:
  12. >
  13. >you're correct in your assertion that strong consistency in the face
  14. >of catastrophic failures is very difficult to guarantee.  skeen's work
  15. >makes it possible for some nodes, under some conditions, to continue
  16. >to make progress when machines crash or communications fail, but it
  17. >doesn't solve the whole problem.  other approaches are to relax your
  18. >consistency requirements, or to have humans outside the loop grant
  19. >permission to acquire locks and update tables during communications
  20. >failures.
  21. >
  22. >the added complexity of three-phase commit, coupled with the fact that
  23. >a clever adversary can force blockage anyway, have meant that it hasn't
  24. >gotten a lot of attention by commercial vendors.  in real life, what
  25. >people do is spend a lot of money on redundant, highly reliable
  26. >communications systems.  when something crashes, some expensive employees 
  27. >get it working again fast.
  28.  
  29. And so we come full circle through a theoretical detour to my original
  30. issue. The way to build a reliable distributed system in practice is:
  31.  
  32. 1) partition the design into separate autonomous databases that interact
  33. via a reliable message-transfer protocol. This partitioning is naturally
  34. done along organizational or legal boundaries, so human responsibility
  35. correlates with system availability i.e., your ass is covered if the other
  36. guy's system is down. By interacting via messages, there are discrete quanta
  37. of responsibility that flow between systems in atomic steps.
  38. Distributed transactions should never cross autonomous systems, except perhaps
  39. to run the message transfers.
  40.  
  41. 2) Reliability is acheived through redundant hardware and recoverable
  42. databases. Recovery from 'disasters' is done by geographically seperated
  43. hardware which is kept as a 'hot standby' with a synchronously updated
  44. database. This is optimally done via a copy of the journal stream,
  45. which contains all necessary data without the redundancy of the disk write
  46. stream. General purpose replicated data with multi-phase protocols and
  47. fancy voting and broadcast algorithms seems way too complex and
  48. inefficient (but maybe it will improve).
  49. My original post was a query to find out if any commercial databases
  50. were capable of robust hot standby. So far, NOT. So far, there doesn't
  51. even seem much acknowledgement that this is a correct approach
  52. to the problem.
  53.  
  54.  
  55.  
  56.  
  57.