Maintaining member subset specific server lists

The default server list can be customized when using member subsets. The server list that is provided to an application is constructed using rules that are based on the applications assigned member subset.

When you use member subsets, you have some control over the server list that is used by the client for automatic client reroute (ACR) and workload balancing (WLB).

Addresses that are included in the server list

The server list that is constructed for an application contains an entry for each member included in the application's assigned member subset irrespective of their failover priority. If the applications assigned member subset is defined to include alternative servers and an alternative server is cataloged, the server list contains an entry for the alternate server. The entry for members with failover priority greater than 0 and the alternative server is assigned a priority of 0. The client drives work to the alternate members (such as members with failover priority greater than 0 only if the primary members are not available). If none of the members in the subset available, only then will the client drive work to the alternative server.

Member priority basis

The priority of member addresses in a member subset server list can be based on one of these algorithms:
  • Load based member priority: When a member subset is defined to use load-based member priority, construction of the server list is similar to the default Db2® pureScale® server list. The priority for each entry is based on the relative load of each member in the member subset. The relative load is calculated by using the CPU load average and average page swap rate, and is refreshed every 10 seconds. In a partitioned database environment, load based member priorities are not supported.
  • Equal member priority: When a member subset is defined to use equal member priority, all entries in the server list are assigned a priority. This priority is the same as round-robin transaction-level workload balancing.

Inclusive and exclusive member subsets

This attribute controls whether an application drives work to members that are not in the member subset, if no member that is in the subset is available. The default value is inclusive.

When a member subset is defined as an inclusive subset, and all the members in the subset are primary members (such as their failover priority value is set to 0), then if all members of the subset are offline, other members (that were not included in the member subset) are included in the server list. As a result, when all members in the member subset are down, the client can attempt to reroute connections to these other members. When a member subset is defined as an exclusive subset, when all members of the subset are offline, other members (that were not included in the member subset) are excluded from the server list, leaving no members available to handle client requests.

For example:
  • A Db2 pureScale cluster with three members (0, 1 and 2)
  • Member priority is load based.
  • A member subset is created including member 0 and 1.
  • The default server list for this cluster includes all three members.
For connections assigned to the member set, these behaviors occur depending on whether the subset is inclusive or exclusive:
  • The priority for member 0 and 1 is load-based
  • The priority for member 2 is always 0 (do no direct work). Member 2 is not included in the member subset. However, if member 0 and member 1 are both down, connections can be rerouted to member 2.

If the member subset is defined as an exclusive member subset, the server list that is returned to connections assigned to the subset includes addresses for members 0 and 1, no address is included for member 2. The priorities for members 0 and 1 are load based.