home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6201 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  4.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!usc!sdd.hp.com!hplabs!ucbvax!HPLWK.HPL.HP.COM!albert
  2. From: albert@HPLWK.HPL.HP.COM (Joseph Albert)
  3. Newsgroups: comp.databases
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <9208200523.AA06321@hplwk.hpl.hp.com>
  6. Date: 20 Aug 92 05:23:36 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Lines: 83
  9.  
  10. References: <9208172103.AA04378@hplwk.hpl.hp.com> <Bt6IsC.F00@world.std.com>
  11. Sender: 
  12. Followup-To: 
  13. Distribution: 
  14. Organization: Hewlett-Packard Laboratories -- Database Technology Dept
  15. Keywords: 
  16.  
  17. In article <Bt6IsC.F00@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
  18.  
  19. >Yes, this is 'remote mirroring', which I discussed in my post.
  20. >Note that I am talking about keeping the systems 100 miles apart.
  21.  
  22. Usually, when people talk about `hot standby dbms they mean one that 
  23. is available when an active one crashes from hardware or other failure,
  24. not a geographically distributed system.
  25.  
  26. It is important to keep three separate issues distinct: 
  27.  
  28. one sort of functionality is recoverability from catastrophic errors--
  29. eg inadvertantly deleted a table with vital data, malicious users who
  30. deliberately change data, complete failures, etc.  this is handled by
  31. backing up the system. recovery from these errors is a manual process.
  32. these backups don't have to be to tape, but could be taken ovre a network,
  33. posted to another disk etc.
  34.  
  35. a second sort of functionality has a need arising from transaction management.
  36. if the system crashes while there are active transactions, the system must,
  37. when brought back up, restore the database to a transaction consistent
  38. state. that is, all of the effects of all committed transactions must
  39. be applied to the database, and none of the effects of uncommitted
  40. transactions should be visible in the database. a system normally
  41. uses a log (sometimes shadow pages) to achieve this.
  42. note that, given the presence of a transaction log, one can further
  43. use the log to be able to do backups without taking the system down.
  44. (by doing a fuzzy dump, where the database may have effects of active,
  45. but uncommitted transactions, and use the log to roll the fuzzy state
  46. forward to a transaction-consistent state at recovery time).
  47.  
  48. a third sort of functionality consists of building a high-availability
  49. or fault-tolerant system, which is a system that can tolerate some
  50. set of precisely specified errors without missing a beat, ie no need
  51. to do the sorts of recovery described in the first or second case for
  52. the specific set of errors. 
  53.  
  54. the 3rd functionality is what people often mean by `hot standby', which
  55. is to what i was proposing a solution. the functionality of the
  56. 1st and 2nd cases is typically provided by most commercial DBMS's.
  57.  
  58. the 3 things are listed in order of decreasing recovery time.
  59.  
  60. for example, someone drops a bomb on the computer. if the backup tapes
  61. are stored somewhere else, you can buy a new computer, install the software,
  62. and install the backup tapes, setting up a system as it was-- this will
  63. resolve very catastrophic errors, but it takes some time to get things back
  64. in order.
  65.  
  66. less serious, the OS crashes, and with it, the dbms. the hardware still works
  67. the disk is not damaged, everything is fine, so you restart the system, and
  68. the dbms recovers to a transaction-consistent state. the system is only
  69. down however long it takes to get it restarted.
  70.  
  71. finally, the 3rd case is designed to have the system keep working even
  72. during an error. a page on the disk goes bad, the OS crashes, the dbms
  73. crashes, .... your business loses $1 million for every hour the
  74. computer is unavailable. so, you design a hardware configuration
  75. with redundancy, so it can tolerate 1 instance of any of a number of
  76. faults. 
  77.  
  78. if you want geographic distribution, with replicated data, as noted in
  79. your 2nd post, a distributed dbms architecture will fill the bill. for
  80. such a system, the transaction model is enhanced to support distributed
  81. transactions, and data replicas that are kept consistent across all
  82. sites. various protocols for maintaining consitency of replicated data
  83. have been studied. for example, you could require a write to a data
  84. item atomically write to every replica (after obtaining locks that prevent
  85. reads or other writes to any of the replicas). then, a read on that item
  86. only has to read one replica. or you could only force the write to
  87. a majority of replicas (which must first be locked). then reads must
  88. (lock and ) read a majority of replicas to be ensured of getting the latest
  89. value. etc.
  90.  
  91. joseph albert
  92. albert@hplabs.hp.com
  93.