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).
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)
- 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.
- 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.