HP Reliable Transaction Router - Manual (Page 53)

Failover and Recovery
Backend
Restart
Recovery
Transactions in the process of being committed at the time of a
failure are recovered from RTR’s disk journal. Recovery could be
with a concurrent server, a standby server, or a restarted server
created when the failed backend restarts.
Correct ordering of the execution of transactions against the
database is maintained.
Transaction
Message
Replay
Transaction messages that are lost in transit are resent when
possible. The frontend and backend nodes keep an in-memory
copy of all active messages for this purpose.
Link Failure
Recovery
In the event of a communications failure, RTR tries to reconnect
the link or links until it succeeds.
Recovery Scenarios
This section describes how RTR recovers from different hardware
and software failure. For additional information on failure and
recovery scenarios, refer to the HP Reliable Transaction Router
Application Design Guide.
Backend
Recovery
If standby or shadow servers are available on another backend
node, operation of the rest of the system will continue without
interruption, using the standby or shadow server.
If a backend processor is lost, any transactions in progress
are remembered by RTR and later recovered, either when the
backend restarts, or by a standby if one is present. Thus, the
distributed database is brought back to a transaction-consistent
state.
Router
Recovery
If a router fails and another router node is available, all in-
progress transactions are transparently rerouted by the other
router. System operation will continue without interruption.
Reliability Features 3–3