Dropping a member or cluster caching facility

In a recoverable database, if you make any change to member topology, for example adding or dropping a member, you must take an offline backup before you can access the database. Otherwise, if you attempt to access the database before taking an offline backup, the database is placed in a backup pending state.

In a non-recoverable database, if you make any change to the member topology, you do not need to take an offline backup before you can access the database. However, the database would only be recoverable to the point in time when you took the last backup image, and using the same topology as when the image was produced. If you do not take an offline back and attempt to access the database, the database is not placed in a backup pending state.

You can add multiple members or drop multiple members without having to take a backup after each change. For example, if you add three members, you only have to take a backup after you have completed all add operations. However, if you add two members and then drop a member, or if you drop two members and then add a member, you must take a backup before you can perform any additional member topology changes.

Restrictions

The db2iupdt -drop command does not drop the last cluster caching facility or the last member, in the DB2® pureScale® instance. To drop the last member or cluster caching facility in the DB2 pureScale instance, see the "Removing DB2 Enterprise Server Edition with the DB2 pureScale Feature" topic.

You must run the db2iupdt -drop command from a host that will still belong to the instance after you have dropped the cluster caching facility or member.