+

Search Tips   |   Advanced Search

Configure manual peer recovery for the transaction service

Manual peer recovery processing is not the default setting; enable it through configuration. Administrator intervention is then required to trigger any peer recovery processing.

Complete this task to use manual peer recovery for the transaction service. A scenario where we might want to use manual peer recovery is when the file system does not provide the required level of file locking support, and no constraints are in place to ensure that overloading or network partitioning does not occur. See topic about how to choose between automated and manual transaction peer recovery.

After configuring manual peer recovery, your intervention is required only when a server fails and cannot be restarted; in this case, use the administrative console to specify which peer server performs recovery processing for the failed server.

Manual peer recovery configuration is provided by a group of policies known as static policies, where one policy definition is provided for each application server. Individual definitions are required to define server-specific configuration within the policy, which in this case is the identity of the server that initiates a peer recovery process.


Tasks

  1. Create the required static policy definitions.

    1. In the navigation pane of the administrative console, click...

        Servers > Core groups > Core group settings

      All the members of a cluster are in a single core group, which by default is the DefaultCoreGroup core group. Click the core group containing your cluster. The Core groups configuration panel is displayed.

    2. Under Additional Properties, click Policies.

      The current set of policies is displayed. We can identify the current policy that applies to transactional high availability (HA) by the match criteria type = WAS_TRANSACTIONS. The default policy has a policy type of One of N policy. If this policy exists, we do not have to remove it, because it is overridden by the static policy that we are creating.

    3. Click New to create a new policy.

    4. Select Static policy and click Next.

    5. Provide a name for the policy.

      This value is a free-form text string used only as a label in the administrative console. However, to assist readability in the administrative console, use a name that associates the policy with a particular server, for example, TM-SERVER1 policy.

    6. Enter a description if required, and click OK.

    7. Set values for the Is alive timer and the Quorum options, if required.

    8. Under Additional Properties, click Match criteria to open an empty match criteria panel.

    9. Click New to create a new match criterion.

      Match criteria are key-value pairs that are used to define the scope of a policy.

    10. Enter type in the Name field and WAS_TRANSACTIONS in the Value field. Click OK. This match criterion is used to associate the policy with the transaction service.

    11. Click New to create a second new match criterion.

    12. Enter GN_PS in the Name field.

    13. Enter cell\node\server in the Value field.

      For example, dmgrCell\appnode1\server1.

    14. Click OK. This match criterion is used to associate the policy with a particular server.

    15. Return to the configuration page for the new policy, and under Additional Properties, click Static group servers. The Static group servers panel is displayed. This panel lists all the servers in the core group and classifies them as either core group servers or static group servers.

    16. From the Core group servers list, select the server associated with the policy and click Add >> to move it to the Static group servers list. The static group servers list is the set of servers that attempts to own the recovery logs at the same time. Adding an incorrect server to this list can compromise data integrity. For normal operation, follow these rules to guarantee data integrity:

      • Add only one server to the list of static group servers.

        Adding two servers causes recovery log contention, because both servers attempt to own the associated recovery logs. The exception to this rule is adding a second server as part of manual peer recovery initiation. See Manage manual peer recovery of the transaction service.

      • Add only the server associated with the policy to the list. Adding a different server prevents the home server from owning its recovery logs, and stops the home server from starting correctly.

  2. Repeat the procedure in step 1 for each server in the cluster.

  3. Save our changes to the master configuration, ensuring that we select the Synchronize changes with Nodes check box.

  4. Stop and restart the cluster members for the changes to take effect.

Manual transaction peer recovery is configured for all the servers in the cluster. Automatic transaction peer recovery can no longer occur.


What to do next

If a server fails, follow the instructions in Manage manual peer recovery of the transaction service, to trigger recovery processing.


Related:

  • How to choose between automated and manual transaction peer recovery
  • Manage manual peer recovery of the transaction service