Filter
Top Products
Server Shadowing and Recovery
B.2 Automatic Features
• RTR_EVTNUM_SRSHADOWGAIN - Server has gained its shadow partner
• RTR_EVTNUM_SRRECOVERCMPL - Server has completed recovery
The shadow events are delivered with no special status and no data. They are
delivered only to the server(s) whose state has changed.
A server receives RTR_EVTNUM_SRPRIMARY under the following
circumstances:
• On initial startup if servers for the key-range are not already running on
other nodes.
• If the server had previously been standby and the previous primary has
failed.
• If the server had previously been shadow secondary and the previous primary
has failed.
A server receives RTR_EVTNUM_SRSTANDBY when it starts up and servers
already exist for the same key-range on another node in the
same cluster
.
A server receives RTR_EVTNUM_SRSECONDARY when it starts up and a
shadow primary set of servers exist elsewhere.
A server receives RTR_EVTNUM_SRSHADOWLOST if it is running as primary
and the secondary goes away.
A server receives RTR_EVTNUM_SRSHADOWGAIN if it is running as primary
and a secondary node starts up.
A server receives RTR_EVTNUM_SRRECOVERCMPL when it has finished doing
recovery operations, and is hence ready to start processing new transactions.
B.3 The RTR Journal System
The RTR journal is used for two purposes:
• RTR stores data about a transaction so that if the server processing a
transaction fails for any reason, another server can transparently continue
from where the previous server failed (if it is able to access the same database
and journal).
• RTR also stores data about transactions when a shadow site is known to be
missing. In this case, RTR stores all transaction data which can result in
a database update. The RTR journal stores this data until the secondary
shadow site is available again. RTR then transparently replays this data to
the shadow site, after which the data is deleted from the journal.
The amount of space required for the journal depends upon:
the size of the messages in a transaction,
the number of messages in the transaction,
the rate of generation of transactions,
the maximum time a shadow site can be out of commission.
The /MAXIMUM_BLOCKS qualifier on the CREATE JOURNAL command
controls how large a journal may become. The /MAXIMUM_BLOCKS qualifier
defines the maximum number of blocks which the journal is allowed to occupy on
any one disk. Note that RTR does not check if this amount of space is actually
available, as the disk space specified by /MAXIMUM_BLOCKS is used only on
demand by RTR when insufficient space is available in the space allocated by the
/BLOCKS qualifier.
B–2 Server Shadowing and Recovery