Topology changes (add or drop CFs)

A cluster caching facility (CF) topology refers to the CFs that are part of a Db2® pureScale® instance. The CF topology refers to all CFs specified in the node configuration file (db2nodes.cfg).

Starting in Db2 Version 11.1 Mod Pack 3 and Fix Pack 3, adding and dropping CFs can be performed online without having to bring down the entire Db2 pureScale cluster.
Note: All hosts in the cluster must be running at the same Db2 level in order to add or drop a CF. This applies for both online and offline operations.

Adding a new CF online

As in previous releases, adding a CF to the Db2 pureScale instance must be performed from a host member or cluster caching facility (CF) that is already part of the instance.

The new CF is added by using the db2iupdt command. When you add a CF to a member host with one or more members, the other members on the host need to be in STOPPED state.

A CF cannot be added to a host that already has a CF.

After the new CF is added, the instance is in the same state it was before the db2iupdt command was issued. The CF is not explicitly started as part of the add operation. The new CF must be started manually by using the db2start command.

Dropping a CF online

As in previous releases, dropping a CF from the Db2 pureScale instance must be performed from a host member or cluster caching facility (CF) that is already part of the instance.

A CF is dropped by using the db2iupdt command. There are no restrictions to dropping the secondary CF. However, if dropping the primary CF then the secondary CF must be in PEER state.

Topology change in a Geographically dispersed pureScale cluster (GDPC)

All information in the sections above are also applicable to GDPC. In GDPC, take special precaution when deciding to drop a CF from either of the non-tiebreaker sites. Dropping a CF will leave the cluster running with a single CF as well as an unequal number of nodes in the two non-tiebreaker sites. The latter impacts the cluster in two ways:
  1. A cluster alert will be raised automatically and displayed via db2instance -list. The alert will be cleared automatically once a new CF is added back to the same site.
  2. When the cluster has one non-tiebreaker site with less nodes, and if a site failure occurs in the site with more nodes, it will cause a cluster outage. The surviving site will not be able to gain operational quorum even with the tie-breaker site. Therefore, it is important to add the CF host back immediately after the drop. You can add and drop CF operations online. A cluster outage is not required.