home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6170 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.7 KB  |  59 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!decwrl!world!edwards
  3. From: edwards@world.std.com (Jonathan Edwards)
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <Bt6IsC.F00@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <9208172103.AA04378@hplwk.hpl.hp.com>
  8. Date: Tue, 18 Aug 1992 12:31:23 GMT
  9. Lines: 48
  10.  
  11. In article <9208172103.AA04378@hplwk.hpl.hp.com> albert@HPLWK.HPL.HP.COM (Joseph Albert) writes:
  12. >
  13. >Jonathan Edwards writes:
  14. >
  15. >>In the transaction-processing world, there is the concept of a 'hot standby'
  16. >>system, which is a geographically separated system containing a copy of the
  17. >>database, and capable of coming online very quickly. The replicated data must
  18. >>be close to current, and guaranteeing complete synchronization is required
  19. >>by some applications. A further feature is the ability to 'catchup'
  20. >>incrementally to missed changes after an outage, without a complete database
  21. >>copy. Our database (homebrew non-relational) does this.
  22. >>Are there any other databases that can do this?
  23. >
  24. >A more reliable fault-tolerance would be obtained from redundancy at a
  25. >level which is lowered than the level of abstraction of the database.
  26. >Disks can be made redundant by having 2 or 3 physical disks, with
  27. [...]
  28.  
  29. Yes, this is 'remote mirroring', which I discussed in my post.
  30. Note that I am talking about keeping the systems 100 miles apart. To do disk
  31. mirroring over that distance is EXTREMELY expensive: you basically need a
  32. fiber optic cable. Sending the journal stream of the database requires an
  33. order of magnitude (or two) less bandwidth.
  34.  
  35. And doing 'catchup' requires a complete database copy. Note that most
  36. disk mirroring schemes, including DEC's and OSF's, force you to do a disk
  37. copy (perhaps partial in OSF) after EVERY RECOVERY, even if the disks are
  38. perfectly fine. This goes to show that mirroring is inapropriate to be
  39. implemented at the device-level, and should be instead coupled with a
  40. journal-based recovery mechanism.
  41.  
  42. >the scheme described at hte beginning of this article, where there is 
  43. >a redundant logical database, with some form of update between
  44. >the real and standby databases to keep the standby one current is
  45. >less fault-tolerant than what was just described. effectively, the
  46. >two databases become one large distributed dbms, with its own newly
  47. >introduced points of failure.
  48.  
  49. Wrong - unless you are talking about software failures. We are both talking
  50. about two equivalent hardware systems 100 miles apart with a cable between
  51. them. Of course you need at least two cables, preferably not going through the
  52. same telco switching centers. With T1 lines this is feasable - with dedicated
  53. fiber it is even more outrageously expensive.
  54. >
  55. >Joseph Albert
  56. >albert@hplabs.hp.com
  57.  
  58.  
  59.