HADR setup in a Db2 pureScale environment

There are a few considerations for setting up an HADR database pair in a Db2 pureScale environment.

Asymmetric standby members

Because only one member on the standby replays logs, consider configuring a standby member with more CPU power and memory to serve as the preferred replay member. Similarly, consider which member on the primary cluster has the most CPU and memory, so that you can select it to be the preferred replay member if the current primary become the standby after a role switch. In both cases, you designate the preferred replay member by issuing the START HADR command from that member, with either AS PRIMARYor AS STANDBYoption. The preferred replay member designation is persistent. It remains in place until changed by the next START HADR command.

In Db2 12.1.2 and earlier, the member topology must be the same on both the primary cluster and standby cluster. In Db2 12.1.3 and later, each of the clusters can have different member topologies, with the primary cluster having the same, more, or fewer members than the standby cluster.

If you have more than one member on the standby cluster and you have resource constraints, such as hardware constraints, you can configure the additional standby members as logical members that share hosts. If the standby cluster takes over the primary role, the new primary is not as powerful as the old primary.

If there are more members in your standby cluster than in your primary cluster, ensure that the right number of members exist in each cluster, to service the needs of your workloads and to maintain adequate replay performance. Check these performance requirements both before and after a TAKEOVER operation. Additional members might need to be added on the primary cluster and the number of members on the standby cluster might need to be reduced. Additional resources, such as hardware resources, can be added, removed, or tuned to satisfy your requirements.

Standby cluster caching facilities

The cluster caching facility (CF) does not have to be the same on the primary and standby clusters. The standby makes minimal use of the CF because only one member performs the replay, so it is possible to have only one CF on the standby cluster. If, however, the standby takes over as the new primary, you should add a CF to help ensure that your Db2 pureScale environment is highly available. Refer to the "Topology changes (add or drop CFs)" page for instructions on how to add the secondary CF.

Member subsetting

You can use member subsetting to specify a subset of members to use for a database. The subset is stored internally as a list of member numbers. The database then maps the members to host names for the client to connect to. If this database uses HADR, you can only specify the subset list on the primary database. The subset member list is replicated to the standby. When adding or dropping members from the topology, update the subset list accordingly, especially before or after a TAKEOVER operation if the primary and standby member topology differs.