Compaq AA-Q88CE-TE manual RTR Journal System, Server Shadowing and Recovery Automatic Features

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–2Server Shadowing and Recovery