Filter
Top Products
RTR Terminology
Figure 1–13 Transactional Shadowing Configuration
VM-0831A-AI
TRFE
Database
Database
BE
Server
application
BE
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