home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6430 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  2.3 KB
  1. Path: sparky!uunet!nntp1.radiomail.net!psinntp!psinntp!bacon!yen!chris
  2. From: chris@yen.imsi.com (Chris Payne)
  3. Newsgroups: comp.databases
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <CHRIS.92Aug28101634@yen.imsi.com>
  6. Date: 28 Aug 92 14:16:34 GMT
  7. References: <CHRIS.92Aug25123032@yen.imsi.com> <BtKEqE.9uy@cup.hp.com>
  8. Sender: news@bacon.IMSI.COM
  9. Organization: Moore Capital Management
  10. Lines: 38
  11. In-reply-to: dhepner@cup.hp.com's message of 26 Aug 92 00:30:14 GMT
  12. Originator: chris@yen
  13.  
  14.  
  15. dhepner@cup.hp.com (Dan Hepner) writes:
  16.  
  17.    > One clean solution to the hot-backup equivalence problem is to
  18.    >serialize the request stream.  Guarantee that when a credit precedes a
  19.    >debit on one db server, it precedes the debit on all active servers.
  20.  
  21.    If this advice "credit must always precede debit" is not followed you 
  22.    might get deadlocks even without replication.  However, this is insufficient 
  23.    to prevent the other kind of out-of-order deadlocks.  What you have to 
  24.    guarantee is that a transaction will acquire locks in a specified order 
  25.    across copies.  I.e. execution of credit on copy 1 must always complete 
  26.    before beginning on copy 2.
  27.  
  28. Here's the idea: serialize & fork the db request stream.  Each hot
  29. standby database will receive the same transactions in the same order.
  30. Other receiver(s) can take the same stream and keep it for posterity.
  31.  
  32. Handling multiple requests in parallel is a critical feature of modern
  33. db's -- you can't afford to force every client's requests into a
  34. single serialized stream.  As a result, you can't guarantee that the
  35. interactions between the requests of various clients will be
  36. duplicated on each hot standby server.  But, hey, if there's a
  37. possible problem (as in lock ordering), then the application is
  38. already in trouble.  Ensuring this level of server-equivalence on the
  39. server side would reduce performance.
  40.  
  41.    >If you want to catch-up a server which is down periodically, keep a
  42.    >copy of the request stream.
  43.  
  44.    How would you guarantee that transactions will be executed in the same
  45.    serial order as was implied by the online system?  As has been pointed
  46.    out, such a guarantee is required to keep the copies synchronized.
  47.  
  48. Unless you're worried about the non-serial nature of the server
  49. itself, this is trivial, right?
  50.  
  51. /c (chris@imsi.com)
  52.