NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/database/6254

Internet Message Format | 1992-08-21 | 5.3 KB

Path: sparky!uunet!decwrl!infopiz!lupine!motcsd!udc!mcdphx!ennews!anasaz!qip!briand
Newsgroups: comp.databases
Subject: Re: Hot Standby DBMS's
Message-ID: <1992Aug21.073707.6235@anasaz>
From: briand@anasaz (Brian Douglass)
Date: 21 Aug 92 07:37:07 GMT
References: <[e-mail]> <1992Aug19.052516.24063@anasaz> <[e-mail]>
Organization: Anasazi, Inc.  Phoenix, Az
Lines: 92

In article <[e-mail]> [e-mail] (Jonathan Edwards) writes:
>In article <1992Aug19.052516.24063@anasaz> briand@anasaz (Brian Douglass) writes:
>>Another approach to this through the use of Transaction Managers (Tuxedo,
>>Encina, Top-End under Unix).  These products, and their grandpappy, CICS,
>>have the ability to distribute transactions among processors or machines be
>>they 10 feet apart or 100 miles.
>>
>>The general approach to your problem would be to have machine 1 (M1) receiving
>>and processing transactions.  A 100 miles away, you put machine 2 (M2).  A
>>wire runs between them.  Whenever a transaction comes into M1 for processing,
>>the same transaction is forwarded on to M2 for identical processing.  If M1
>>goes down for some reason (Hurricane), M2 takes over processing.  Whether
>>transactions arrive at it from M1, or straight from the source units across
>>the net, they all look the same to it.
>
>I infer that you are using 'transaction processing' in the older usage, of
>a unit of work to be processed, canonically a 3270 screen.

No.  A transaction is any set of actions upon the database requiring a
change from a consistent to an inconsistent state, and return to a
consistent state through a commitment of the actions or roll back.  For
example, TPC-A or B benchmarks.

>Nowadays a
>'transaction manager' usually means a system to support logical database
>transactions with journaling and recovery, and does not refer to application
>data flow. The ENCINA product is only the former, as far as I know.

Journaling and recovery are typically handled at the Resource Manager
(DBMS) level, but are coordinated by a TM, especially if a system is
distributed across machines.  However, the TM handles the routing of
transactions amongst machines until they reach their final destination for
processing.  Tuxedo even supports data-dependant routing.  That is, a
DEPOSIT transaction for account 103xxxx would get routed to machine 103,
while a DEPOSIT for account 457xxxx would go to machine 457, even though
both machines are running the exact same software.

>
>Given a CICS-like environment, you propose splitting all input transactions
>(3270 screens) across two systems (i infer).

3270 screens aren't the right analogy.  A collection of DBMS activities
are better:
    Update cust_bal set bal = bal + deposit where acct = cust_num;
    Update tell_bal set bal = bal + deposit where tell = tell_num;
    Update brnc_bal set bal = bal + deposit where branch = brnc_num;
    Insert into his_log values(cust_num, deposit, tell_num, brnc_num, time);
    COMMIT WORK;

>One of these system is 'muted' so that its outputs are
>supressed. This is not quite perfect, though, due to the possibility of
>timing differences on the two systems. Any transaction mix that leads to
>lock races could have different outcomes on the two systems due to random
>timing differences.

The two systems are not in lock step.  The above transaction would arrive
at machine 1 as a DEPOSIT transaction and would be processed by the
DEPOSIT process.  The very same transaction would be routed to machine 2
for the same processing.  There is no need the individual DEPOSIT processes
to even know about each other.  The coordination that does have to take
place is that machine 2 completes the transaction successfully.  If it
doesn't, then this transaction remains open in a log on machine 1.  It does
NOT affect the consistency of the data on machine 1.  Machine 1 is just
storing up transactions that are uncompleted on machine 2.  At this point
it should be programatic to insure that when machine 2 does ressurect, it
does catchup with machine 1, and all transactions are processed singularly
by machine 2.

Great in theory, but I haven't seen it work, under Unix.  I have seen it on
IBMs and PC's.  In a previous life a fella I worked with did exactly this
under DOS using Token Ring.  And by golly it worked.  We couldn't break it,
and the databases were always consistent after the dead machine was brought
back up.  If it can be done on DOS, surely it can be added in Tuxedo or Encina,
or Top-End.

>It seems to me that you have to base hot standby either on a copy of the
>disk-write stream, or a copy of the journal stream, which is more efficient
>and can more easily support catchup. I am basically trying to
>find out if any commercial databases do replication based on the journal
>stream.

It would be nice if a commercial DBMS did support data replication, and not
simply data distribution (table 1 on machine 1, table 2 on machine 2).
Such a product would make micro based, high availability OLTP engines a
reality, without needing special hardware gyrations.  In the meantime, TMs
should be able to handle this through programming.


--
"... For I have sworn upon the alter of god, eternal hostility against
every form of tyranny over the mind of man."  Thomas Jefferson
Brian Douglass        [e-mail]     602-870-3330 X657