A cluster environment might fail to start due to errors when the server starts up. Potentially, you might see errors in the startup logs, which causes the server to not start cleanly.
Transaction log files might hold old information or data, which causes out-of-date transactions to be executed during start up as part of the recovery process.
Resolving the problem
There are two options to resolve this issue. If there are not any outstanding transactions that must be executed, the second option is preferred.
- You can enable the manual peer recovery option for the environments and the recovery process is activated during start up. However, failover transactions are not automatically resubmitted. Admin action is required to get the failed transactions resubmitted. So, use this option only if it is something that you can afford.
- The transaction logs hold information about in-flight transactions during runtime and possible failed transactions that need recovery. If you can bring down your whole environment. which means all in-flight transactions are stopped, and you can then start the Network Deployment environment in recovery mode. For more information, see How to resolve Transaction- and Partnerlog recovery issues in WebSphere Process Server. This approach flushes out all the 'valid' recoverable transactions. This approach leaves the bad translation still in the logs. When the servers are down, you can make a backup of the tranlogs and remove them from the tranlog directory. The tranlogs are automatically recreated when the servers are brought up. Any existing data in the removed transaction logs is lost. New transaction data is written to the new logs, as required, during transaction processing. This approach should be used during a full cluster restart and should be cleaned for every cluster member.