Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Administer Transactions > Administer the transaction service > Manage transaction logging for optimum server availability
Move a transaction log from one server to another
We can move the transaction logs for an application server to another server.
The following steps explain how to move transaction logs from one application server to another.
The transaction service does not allow transaction logs to be moved from one server to another in a high availability (HA) environment. In such scenarios, WAS dynamically controls which server is assigned ownership of the recovery logs. For this reason, the following steps are not applicable when the Enable failover of transaction log recovery option has been set on the administrative console.
For more information see the Transactional high availability topic and its related topics.
Procedure
- Move all the transaction log files for the application server. The transaction log directory for each server contains a number of files and subdirectories. When moving transaction logs from one server to another move all of the files and subdirectories together as a single unit; otherwise recovery might not complete resulting in data inconsistency.
- Follow the relevant step below, depending on your server configuration:
- Optional: For a server configuration where there are no distributed transactions, move the transaction logs to any server that has access to the same resource managers. For a single server or network-deployed server configuration where it is known there are no distributed transactions present in the logs, the transaction logs can be moved to any server (on any node) that has access to the same resource managers as the original server. For example, the server needs communication and valid security access to databases or message queues.
If the server is in a different cell from the original server, ensure that there is a JAAS alias available to the server that was used by the original server for accessing XA resources. In this case you should use wsadmin to construct the aliases, because if you use the administrative console to create the alias, then the node name gets prefixed to the alias.
All the transaction log files for the original server must be moved to a directory accessible by the new server. This can be accomplished by either renaming the transaction log directory or copying all the contents to the new server transaction log directory before starting the new server.
- Optional: For a network-deployed server configuration where there are distributed transactions, move the transaction logs to a server that has the same name and host IP address, and access to the same resource managers. For a network-deployed server configuration, when it is known there are distributed transactions present in the logs, there are more restrictions. Distributed transactions that access multiple servers log information about each server involved in the transaction. This information includes the server name and the IP address of the machine on which the server is running. When recovery is taking place on server restart, the server uses this information to contact the distributed servers and similarly, the distributed servers try to contact the server with the same original name. Therefore, if a server fails and the logs have to be recovered on an alternative server, the alternative server must have the same name and host IP address as the original server. The alternative server also must have access to the same resource managers as the original server. For example, the server needs communication and valid security access to databases or message queues.
All servers within a cell must have unique names.
To complete transaction recovery, the application server uses the resource manager configuration information in the transaction logs. However, for the application server to continue to do new work with the same resource managers, the server must have an appropriate resource manager configuration (as for the original server).
Transactional high availability
Manage transaction logging for optimum server availability