You can configure the location of the transaction log directory by using either
the administrative 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 application server 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 local area network (LAN)), must support the file-based force
operation that is used by the recovery log service to force data to disk.
The storage mechanism that is used to host recovery log files and access to that mechanism must
support the file-based force operation that is used by the recovery log service to force data to
disk. For example, you can store the logs on another IBM i server by using the NetClient file system (QNTC), which
provides access to data on a remote system using the Server Message Block (SMB) protocol.
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 Network File System (NFS) and
hard-mounting the remote directory containing the log files (by using the -o hard option of the NFS
mount command), the NFS client will try again with a failed operation until the NFS server becomes
available again.
Note: If you have migrated from a previous version of WebSphere Application Server, 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 Version 5 application servers to a later
version of WebSphere Application Server, 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.