HP Reliable Transaction Router User Manual

Page 28

RTR Terminology

Figure 1–13 Transactional Shadowing Configuration

VM-0831A-AI

Database

Server

application

Server

application

Primary Server

Shadow Server

RTR Journal

In the RTR environment, one data store (database or data

file) is elected the primary, and a second data store is made

the shadow. The shadow data store is a copy of the data store

kept on the primary. If either data store becomes unavailable,

all transactions continue to be processed and stored on the

surviving data store. At the same time, RTR makes a record

of (remembers) all transactions stored only on the shadow data

store in the RTR journal by the shadow server.
When creating the configuration used by an application and

defining the nodes where a facility has its frontends, routers,

and backends, the setup must also define which nodes will have

journal files. Each backend in an RTR configuration must have

a journal file to capture transactions when other nodes are

unavailable. When the primary server and data store become

available again, RTR replays the transactions in the journal to

the primary data store through the primary server. This brings

the data store back into synchronization.
With transactional shadowing, there is no requirement that

hardware, the data store, or the operating system at different

sites be the same. You could, for example, have one site running

OpenVMS and another running Windows; the RTR transactional

commit process would be the same at each site. Because the

database resides at both sites, either backend can have an

outage and all transactions will still be processed and recovered.

1–16 Introduction