Configure transaction properties for peer recovery

 

+

Search Tips   |   Advanced Search

 

Peer recovery for the transaction service enables servers in a cluster to complete outstanding work for a failed cluster member . Follow the steps in this topic to configure the transaction properties that are required for peer recovery of failed appservers in a cluster.

Transaction peer recovery requires a common configuration of the resource providers between the participating server members in order to be able to perform peer recovery between servers. This means that peer recovery processing can only take place between members of the same server cluster. Although a cluster can contain servers that are at different versions of WebSphere Application Server, enable and configure high availability only if all servers in the cluster are at V6 or later.

 

Overview

Configure the transaction properties that are required for peer recovery is part of the overall task for configuring a cluster to use high availability support.

 

Procedure

  1. Configure the transaction log directory setting for each server in the cluster.

    You can configure the location of the transaction log directory using either the console or commands. The configuration is stored in the serverindex.xml node-level configuration file.

    Each server in the cluster must be able to access the log directories of other servers in the same cluster. For this reason, do not leave this setting unset. If you do not set a directory, the appserver assumes a default location within the appropriate profile directory, which might not be accessible to other servers in the cluster.

    Each server in the cluster must also have a unique transaction log directory, to avoid attempts by multiple servers to access the same log file. For example, you could use the name of each server as part of the log directory name for that server.

    The storage mechanism that is used to host recovery log files (for example, you can use IBM Network attached storage (NAS) and shared SCSI drives, but not simple network share) and access to that mechanism (for example, through a LAN), must support the file-based force operation that is used by the recovery log service to force data to disk.

    In addition, configure the mechanism by which the remote log files are accessed, to exploit any fault tolerance in the underlying file system. For example, by using the NFS and hard mounting the remote directory containing the log files using the -o hard option of the NFS mount command, the NFS client will retry a failed operation until the NFS server becomes available again.

    If you have migrated from a previous version of WAS, be aware that previous versions stored the recovery log configuration in the server.xml server-level configuration file. If you run existing scripting that configures the original recovery log settings, or migrate V5 appservers to a later version of WAS, the original transaction log directory configuration in the server.xml file is updated. The administrative console detects this condition and prompts you to save the configuration when you view the transaction service panel. This save operation saves the changed configuration to the serverindex.xml file, and resets the older fields to null. Change your existing scripting to target the serverindex.xml file at the earliest opportunity. New scripting should also target the serverindex.xml file.

  2. Enable the high availability function for the cluster, by completing the following steps on the cluster configuration panel of the WebSphere Application Server console:

    1. In the console, click...

      Servers | Clusters | cluster

    2. Select the Enable failover of transaction log recovery option.

    3. Click OK.

  3. Decide which kind of transaction peer recovery to use by referring to How to choose between automated and manual transaction peer recovery.

  4. Perform one of the following actions, depending on the configuration that you require.



Configure manual peer recovery for the transaction service

Configure automated peer recovery for the transaction service

 

Related concepts


Transactional high availability

 

Related tasks


Use the transaction service