Recovering Transactions for a Failed Clustered Server

Recovering Transactions for a Failed Clustered Server

In the case of clustered servers, the recovery process is fairly automated. A server can perform recovery for another server while simultaneously processing its own transactions. Note also that, should the backup server die during the recovery process, recovery can be forwarded to another server.

The following describes the sequence of events.

1. A clustered server crashes.

2. The clustered server's backup server takes control of the transaction log on the crashed server.

3. The Transaction Recovery Service on the backup server sifts through the transaction log files on the failed server. For each incomplete transaction it identifies, it attempts to recover it.

4. If the recovery/completion process is successful, the backup server will relinquish control of the Transaction Recovery Service for the crashed server so that the crashed server can reclaim control when and if it restarts. If a backup server has not released control of the Transaction Recovery Service for a failed server and is inactive when the failed server attempts to restart, the failed server will not be able to start, because it needs access to the Transaction Recovery Service.

In addition, the following limitations apply:

It is not possible to migrate the Transaction Recovery Service to a backup server from a running server. The server must be stopped before migration.

Backup servers cannot accept new transactions for the failed server; they can only process old ones.

Backup servers cannot process heuristic log files.

Backup servers cannot process log records written by gateway implementations such as WebLogic Tuxedo connector. They can only process log records written by WebLogic server.