Dropping a member or cluster caching facility

In a recoverable database, if you change the member topology (for example, dropping a member), you must take either an incremental or full offline database backup before you can access the database. (This event is considered a change to the life of the database topology.) Otherwise, if you attempt to access the database before taking an offline backup, the database is placed in a backup pending state.

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

You can drop multiple members without having to take a backup after each change. For example, if you drop three members, you need to take a backup only after you have completed all drop operations. However, if you add two members and then drop 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 drop the cluster caching facility or member.
• You cannot drop a member when the Db2 pureScale instance is in a heterogeneous state (unless the cluster manager is offline).

  For more details, see Database and instance operations affected by an online fix pack update in progress.

• If there is more than one member on the host, the db2iupdt -drop command drops all members from that host. The -mid parameter can be used with the -m parameter to specify the logical member to be dropped. The db2iupdt -drop -m MemberHostName -mid MemberID command drops the member with the MemberID member identifier.
• The db2iupdt -drop -m command has these additional restrictions:
  • All databases must be in a consistent state.
  • None of the databases can be configured for HADR.
  • None of the databases can be in backup pending, rollforward pending, or restore pending state.
  • None of the databases can have a table space that is rollforward pending, or in an inconsistent table space.