home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6203 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  3.1 KB
  1. Path: sparky!uunet!olivea!decwrl!decwrl!infopiz!lupine!motcsd!udc!mcdphx!ennews!anasaz!qip!briand
  2. From: briand@anasaz (Brian Douglass)
  3. Newsgroups: comp.databases
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <1992Aug19.052516.24063@anasaz>
  6. Date: 19 Aug 92 05:25:16 GMT
  7. References: <9208172103.AA04378@hplwk.hpl.hp.com> <Bt6IsC.F00@world.std.com>
  8. Organization: Anasazi, Inc.  Phoenix, Az
  9. Lines: 52
  10.  
  11. In article <Bt6IsC.F00@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
  12. >In article <9208172103.AA04378@hplwk.hpl.hp.com> albert@HPLWK.HPL.HP.COM (Joseph Albert) writes:
  13. >>
  14. >>Jonathan Edwards writes:
  15. >>
  16. >>>In the transaction-processing world, there is the concept of a 'hot standby'
  17. >>>system, which is a geographically separated system containing a copy of the
  18. >>>database, and capable of coming online very quickly. The replicated data must
  19. >>>be close to current, and guaranteeing complete synchronization is required
  20. >>>by some applications. A further feature is the ability to 'catchup'
  21. >>>incrementally to missed changes after an outage, without a complete database
  22. >>>copy. Our database (homebrew non-relational) does this.
  23. >>>Are there any other databases that can do this?
  24. >>
  25. >>A more reliable fault-tolerance would be obtained from redundancy at a
  26. >>level which is lowered than the level of abstraction of the database.
  27. >>Disks can be made redundant by having 2 or 3 physical disks, with
  28. >[...]
  29. >
  30. >Yes, this is 'remote mirroring', which I discussed in my post.
  31. >Note that I am talking about keeping the systems 100 miles apart. To do disk
  32. >mirroring over that distance is EXTREMELY expensive: you basically need a
  33. >fiber optic cable. Sending the journal stream of the database requires an
  34. >order of magnitude (or two) less bandwidth.
  35.  
  36. Another approach to this through the use of Transaction Managers (Tuxedo,
  37. Encina, Top-End under Unix).  These products, and their grandpappy, CICS,
  38. have the ability to distribute transactions among processors or machines be
  39. they 10 feet apart or 100 miles.  
  40.  
  41. The general approach to your problem would be to have machine 1 (M1) receiving 
  42. and processing transactions.  A 100 miles away, you put machine 2 (M2).  A 
  43. wire runs between them.  Whenever a transaction comes into M1 for processing, 
  44. the same transaction is forwarded on to M2 for identical processing.  If M1
  45. goes down for some reason (Hurricane), M2 takes over processing.  Whether
  46. transactions arrive at it from M1, or straight from the source units across
  47. the net, they all look the same to it.  
  48.  
  49. Now of course some additional programming is necessary on both M1 and M2 so
  50. that when one or the other is down, a sync log is created.  Once the down
  51. machine is resurrected, the sync log is read and transactions are fed to
  52. the revived machine until is catches up, and the sync process can go back
  53. to sleep.
  54.  
  55. People from all three of these companies are listening and I'm sure they'd
  56. be happy to post their addresses, phone numbers and contacts if people are
  57. interested.
  58.  
  59. -- 
  60. "... For I have sworn upon the alter of god, eternal hostility against
  61. every form of tyranny over the mind of man."  Thomas Jefferson
  62. Brian Douglass        briand@anasazi.com     602-870-3330 X657
  63.