home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6184 < prev    next >
Encoding:
Text File  |  1992-08-18  |  2.6 KB  |  62 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!munnari.oz.au!metro!bnd2.bnd.oz.au!johnw
  3. From: johnw@bnd2.bnd.oz.au (John Warburton)
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <1992Aug19.001017.10999@bnd2.bnd.oz.au>
  6. Organization: B&D Doors, Sydney, NSW, Australia
  7. References: <9208172103.AA04378@hplwk.hpl.hp.com>
  8. Date: Wed, 19 Aug 1992 00:10:17 GMT
  9. Lines: 51
  10.  
  11. From article <9208172103.AA04378@hplwk.hpl.hp.com>, by albert@HPLWK.HPL.HP.COM (Joseph Albert):
  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. > drivers that make them look like a single device. if one disk fails,
  28.     .
  29.     .
  30.     .
  31.     .
  32.   lots more on physical fault tolerance deleted...
  33.  
  34. That all sounds good for cpu, disk crashes etc, but what about when you plug
  35. humans into the loop?
  36.  
  37. 4 out of our last 5 crashes have been human error & not hardware problems.
  38. Mainly filling up the database disks & no more writes possible, or someone
  39. accidentally writing direct onto the databse volume file .. sigh
  40.  
  41. I think that these sort of problems and the resultant reload of database
  42. checkpoint & replay of transactions could have been avoided with a machine that
  43. has the checkpoint written to it, at the same time as to tape, and transaction
  44. logs sent to the machine every 15 mins, so as to save time in reload of the
  45. checkpoint, - all we would do would replay the transactions -saving us about 2
  46. 1/2 expensive hours.
  47.  
  48. The reason this looks good, is that you do not have to replace your existing
  49. hardware for expensive fault tolerant machines. All you need is a (secondhand?)
  50. machine like your production one, with cheaper disks - just as long as it limps
  51. along until you fix the problem on the production machine, that's fine.
  52.  
  53. comments?
  54.  
  55. > Joseph Albert
  56. > albert@hplabs.hp.com
  57. -- 
  58. John Warburton                Internet:    johnw@bnd2.bnd.oz.au
  59. Systems Administrator            Phone:       +61 2 771 5566
  60. B & D Australia                Fax:         +61 2 771 6385
  61.           Living on ice-cream and chocolate kisses...
  62.