NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/database/6583

Text File | 1992-09-08 | 5.2 KB | 113 lines

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: [e-mail] (David Boyce)
Subject: Re: Hot Standby DBMS's
Message-ID: <[e-mail]>
Sender: @uk03.bull.co.uk
Nntp-Posting-Host: pluto
Organization: Bull HN UK
References: <[e-mail]> <[e-mail]> <1992Aug25.063147.2764@anasaz> <[e-mail]>
Date: Mon, 7 Sep 92 16:50:29 GMT
Lines: 100

[e-mail] (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    ([e-mail])
                Tel: [phone]    BULL HN Information Systems Ltd.
                Fax: [phone]    1, Three Cherry Trees Lane,
                          Hemel Hempstead, Herts HP2 7DZ