home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.databases
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!cass.ma02.bull.com!pluto.uk03.bull.co.uk!dboyce
- From: dboyce@hemel.bull.co.uk (David Boyce)
- Subject: Re: Hot Standby DBMS's
- Message-ID: <1992Sep7.165029.26587@uk03.bull.co.uk>
- Sender: @uk03.bull.co.uk
- Nntp-Posting-Host: pluto
- Organization: Bull HN UK
- References: <BtI4Bv.D8r@cup.hp.com> <BtI9KD.MAv@world.std.com> <1992Aug25.063147.2764@anasaz> <BtpKqr.Kz1@world.std.com>
- Date: Mon, 7 Sep 92 16:50:29 GMT
- Lines: 100
-
- edwards@world.std.com (Jonathan Edwards) writes:
-
- >In article <1992Aug25.063147.2764@anasaz> briand@anasaz (Brian Douglass) writes:
- >>>As journal data is received and written at the remote system, it is
- >>>asynchronously being recovered there, just like a normal journal (roll-forward)
- >>>recovery. Thus the remote system can recover and take over in a few minutes
- >>>from the production system.
- >>
- >>I think a difference lies in that while I suggest transactions
- >>are processed as they are received on the remote system, Mr. Edwards system
- >>seems to roll forward only upon primary failure, or I suppose nightly. If
- >>I am wrong in this, please clarify.
- >No, the remote system is recovering (rolling forward) on the fly.
- >That's what the HOT in Remote Hot Standby means.
-
- >>What type/size systems is this operation implemented on? If you can say.
- >>Large Unix OLTP operations are still a rarity compared traditional mainframe
- >>solutions, and I love to hear what others are doing.
-
- >VAX/VMS - the whole size range. The database itself is written in VAX
- >assembler and mostly runs in kernel mode to pull off some nice stuff.
- >The basic code is 10 years old, though it has evolved considerably.
- >By modern standards it is a white elephant, but will still blow the doors
- >off anything else. But it seems the market is willing to buy 10 times as
- >much hardware (literally!) in order to get a relational solution...
-
- For another example of a system of this type, in 1984 Honeywell
- Information Systems (now part of Bull) released a two-machine version
- of its TPS6 proprietary TP system which was a hot remote standby
- configuration (we called it 'Resiliency'). This was (and I believe
- still is) being used in a significant number of customer sites. It ran
- on Honeywell's DPS6 range of minicomputers.
-
- The two machines were separate systems linked by fibre-optic or
- broadband cable (usually two physical links were configured), with
- 'intelligent' switches to automatically re-configure terminals and
- other devices to the hot standby ('tracker') on master failure.
-
- During normal running, the master database's roll-forward journal was
- passed, via one of the links, from 'master' to 'tracker' as it was
- generated, and the tracker would apply this to its copy of the
- database.
-
- If the master failed, the tracker would abort current transactions and
- restart their associated programs, and become the new master. The
- on-line users would be interrupted for a short time, and then could
- restart their work following the last completed transaction. When the
- reason for the old master failing was dealt with, it could be
- re-introduced as a hot standby.
-
- One interesting addition to this was to link batch program requests
- made within transactions to transaction completion; these program
- requests were also tracked so that requests made by completed
- transactions on the master were not lost if the master failed prior to
- the requests being scheduled.
-
- Another addition was the management of print spool requests; using the
- same mechanism, print requests could be maintained on a hot standby
- basis.
-
- Care was taken to ensure compatible configurations on each side,
- although interestingly there was enough 'give' in the checking to
- permit some re-configuration without interrupting service, although
- this wasn't possible for every type of configuration change.
-
- As noted in other posts, the implementation is tightly coupled to the
- particular database (although at the time its loosely-coupled system
- architecture gave it significant advantages).
-
- A thought arising:
-
- Other posts have pointed out that transmission of journalling data
- appears to be the only certain method of ensuring database consistency
- in a hot-standby architecture. This presently continues to be
- supported only by proprietary databases.
-
- With a number of database vendors now offering support for the XA-
- interface, allowing co-ordination within distributed transactions,
- shouldn't we also be seeking to encourage the definition of an
- equivalent 'hot-standby' interface, which permits communication of
- journal information to be managed by a component of a Transaction
- Manager?
-
- Interfaces for obtaining journal data from an RM and passing it to an
- standby RM would be needed, as would RM-independent methods of recovery
- and catch-up. Not beyond the wit of man, I would have thought.
-
- Obviously the database vendors need to be convinced of the need to make
- this interface available.
-
- Note that they do not need to publish the content of the journalised
- data - it could be encrypted - just provide it in a form in which it
- can be transmitted.
-
- Any interest?
- --
- David Boyce (David.Boyce@hemel.bull.co.uk)
- Tel: +44-442-884468 BULL HN Information Systems Ltd.
- Fax: +44-442-884570 1, Three Cherry Trees Lane,
- Hemel Hempstead, Herts HP2 7DZ
-