DB2 10.5 for Linux, UNIX, and Windows

Dropping a member or cluster caching facility

Dropping a member or cluster caching facility entails running the db2iupdt command. This topology change might require a database backup, depending on whether or not the database is recoverable.

About this task

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

Procedure

Log in to the host that will still belong to the instance after you dropped the cluster caching facility or member.
Stop the DB2 pureScale instance on all hosts by using the db2stop command.

To remove a DB2 member:

   DB2DIR/instance/db2iupdt -drop -m hostname instance_name

To remove a cluster caching facility:

   DB2DIR/instance/db2iupdt -drop -cf hostname instance_name

DB2DIR is the directory where the DB2 pureScale software is installed.

Remove the DB2 pureScale Feature installation on the host by running the following command:
```
   DB2DIR/install/db2_deinstall -a
```
When the DB2 installer removes the last DB2 installation, it also automatically removes DB2 cluster services.

Results

After a member is dropped, its entry is kept in the diagnostic directory.

Example

For example, if you want to drop a member from a host that is called test1 and an instance called db2sdin1, run the following command:

   DB2DIR/instance/db2iupdt -drop -m test1 db2sdin1

Then, to remove the DB2 installation from the test1 host, run the following command from the test1 host:

   DB2DIR/install/db2_deinstall -a

What to do next

Perform either an incremental or full offline database backup that reflects the current topology of yourDB2 pureScale cluster.