home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6409 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  3.5 KB
  1. Path: sparky!uunet!pmafire!news.dell.com!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!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: <1992Aug25.063147.2764@anasaz>
  6. Date: 25 Aug 92 06:31:47 GMT
  7. References: <BtDAt7.L5J@world.std.com> <BtI4Bv.D8r@cup.hp.com> <BtI9KD.MAv@world.std.com>
  8. Organization: Anasazi, Inc.  Phoenix, Az
  9. Lines: 61
  10.  
  11. In article <BtI9KD.MAv@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
  12. >Since there has been quite a lot of traffic generated by my original
  13. >post, I thought I should contribute how I have implemented the
  14. >Remote Hot Standby feature in our proprietary non-relational database.
  15. >There is intense market pressure for us to deliver relational-based
  16. >solutions, thus my post to see if any such could do the job, so far
  17. >fruitlessly.
  18. >
  19. >My database has a global journal stream which batches together the transaction
  20. >data system-wide. A commit is typically a single disk write, and on a 
  21. >reasonably loaded system it averages below one write. 
  22. >There is never any need to flush data to its home location on disk - 
  23. >it can remain cached forever (but thats another story...).
  24. >A normal (all disks intact) recovery takes a few minutes max.
  25. >
  26. >Remote Hot Standby operates by simply keeping a copy of the journal file
  27. >on a remote system. We typically use an Ethernet bridge over T1 lines.
  28. >We usually operate synchronously - a transaction is not complete till
  29. >both the local and remote journal writes are complete.
  30.  
  31. This is a different implimentation of what I've been talking about.
  32. Duplicating the transaction stream (in Mr. Edwards case, the journal
  33. stream) so that it is processed identically by both the local and remote
  34. machines.  
  35.  
  36. >Obviously, latency is the critical performance factor here. Though because of
  37. >journal batching, this hurts response time more than throughput.
  38. >As a result, the communication protocol is absolutely minimal - I talk
  39. >directly to the Ethernet driver and run my own protocol. I have learnt that
  40. >most Ethernet interface boards have pretty pathetic performance.
  41. >
  42. >As journal data is received and written at the remote system, it is
  43. >asynchronously being recovered there, just like a normal journal (roll-forward)
  44. >recovery. Thus the remote system can recover and take over in a few minutes
  45. >from the production system.
  46.  
  47. I think a difference lies in that while I suggest transactions
  48. are processed as they are received on the remote system, Mr. Edwards system
  49. seems to roll forward only upon primary failure, or I suppose nightly.  If
  50. I am wrong in this, please clarify.
  51.  
  52. If the remote does do a "catch-up" each evening, how would you handle a
  53. 24x7 operation withy your product?
  54.  
  55. [good stuff deleted]
  56.  
  57. >By the way, these systems handle Billions of dollars a day, which is what
  58. >justifies so much custom engineering for reliability. Failing to get the
  59. >day's work done on time can cost 100's of thousands of dollars in interest
  60. >penalties alone. Losing data is unthinkable.
  61. >
  62. >Hope this was of interest - Jonathan
  63.  
  64. What type/size systems is this operation implemented on?  If you can say.
  65. Large Unix OLTP operations are still a rarity compared traditional mainframe
  66. solutions, and I love to hear what others are doing.
  67.  
  68. -- 
  69. "... For I have sworn upon the alter of god, eternal hostility against
  70. every form of tyranny over the mind of man."  Thomas Jefferson
  71. Brian Douglass        briand@anasazi.com     602-870-3330 X657
  72.