Failover priority

Failover priority extends the configuration options for member subsets. You can explicitly define the members that are part of the alternate member list by using the FAILOVER_PRIORITY attribute in the WLM_ALTER_MEMBER_SUBSET procedure.

The FAILOVER_PRIORITY attribute can be used with the existent ADD clause. Members with a failover priority of 0 (the default priority) are considered primary members and members with failover priority greater than 0 are considered alternative members.

Failover behavior

  • The number of primary members in the subset defines the minimum number of members to service an application. The application is going to fail over to one of the alternate members with the lowest failover priority when there are alternate members that are defined and one of the primary members is not available.
  • If there are multiple alternate members with the same failover priority, then the members that are chosen for the failover application are based on the lowest member number from the lowest priority grouping. (The number of primary members in the subset defines the minimum number of members you want servicing the application).
  • If the member subset is defined as an inclusive subset and there are not enough alternate members to failover, then the application uses the other available members in the cluster that are not part of the subset.

Failback behavior

  • If a member of lower priority becomes available, then the applications from the member with the highest failover priority fails back. This means that all the new clients connect to the member with lower priority that becomes available.
  • The existing clients are connected to the member with the higher failover priority until they complete their processing.
  • The following code block shows an example of creating an inclusive member subset named SALES_PREFERRED_SUBSET with members 0 and 1 as primary members and members 2, 3, and 4 as alternate members:
    CALL SYSPROC.WLM_CREATE_MEMBER_SUBSET( 'SALES_PREFERRED_SUBSET', '<databaseAlias>SALES_P</databaseAlias>', '( 0 )' ) ; 
CALL SYSPROC.WLM_ALTER_MEMBER_SUBSET( 'SALES_PREFERRED_SUBSET',  NULL, '( ADD 1 )' ) ;        
CALL SYSPROC.WLM_ALTER_MEMBER_SUBSET( 'SALES_PREFERRED_SUBSET',  NULL, '( ADD 2 FAILOVER_PRIORITY 1, ADD 3 FAILOVER_PRIORITY 1 )' ) ;         
CALL SYSPROC.WLM_ALTER_MEMBER_SUBSET( 'SALES_PREFERRED_SUBSET',  NULL, '( ADD 4 FAILOVER_PRIORITY 2 )' ) ;
  • The query to achieve this output is: 
    SELECT SUBSETID, MEMBERS, FAILOVER_PRIORITY FROM SYSCAT.MEMBERSUBSETMEMBERS
  • The failover priority column in the table shows the FAILOVER_PRIORITY attribute of the members in the subset.
    Table 1. SYSCAT.MEMBERSUBSETMEMBERS
    SUBSETID MEMBERS FAILOVER_PRIORITY
    1 0 0
    1 1 0
    1 2 1
    1 3 1
    1 4 2
    Rules:
    • The value for FAILOVER_PRIORITY must be 0 - 254.
    • If FAILOVER_PRIORITY is not specified with ADD or ALTER, the member is considered to be a primary member.

Legacy behavior

  • During migration, we set the value of FAILOVER_PRIORITY attribute to 0 for all of the members in the existing member subsets. This is done to preserve the legacy behavior of member subsets. If all the members in the subset have a failover priority of 0, then we use legacy behavior.
  • The legacy behavior of inclusive member subsets includes:
    • Workload fail over to the members in the instance but not in the subset if all members in the subset are not available.
    • Failback to one of the members in the subset as soon as it is online and stops using the members that are not in the subset.
  • The legacy behavior of exclusive member subsets includes:
    • Workload is not processed if there are no members available in the subset