Moving a Db2 member or a cluster caching facility

There are a number of reasons to move a Db2 member or a cluster caching facility from one host to another. This task outlines a number of possible scenarios and some additional factors to consider.

About this task

Following a change in a Db2 pureScale® environment with a db2iupdt -add or -drop operation, a backup of the database might be required. This backup must be performed from one of the preexisting instance members.

Restrictions

A maximum of two cluster caching facilities are supported. If you want to move one, you must drop the other one first, then add the second one on a new host. You receive an error if you try and add a third cluster caching facility before first dropping one.

There must always be at least one Db2 member and one cluster caching facility. If you want to move one, you must add the new Db2 member or cluster caching facility on a new host first before dropping the original one. You receive an error if you try to drop the last remaining member or cluster caching facility.

Procedure

To move the only Db2 member:
1. Stop the Db2 pureScale instance on all hosts by using the db2stop command.
  This step is necessary because the db2iupdt -drop command must run offline.
2. Add a new member.
  This addition ensures that there is always at least one Db2 member.
  For example, add a Db2 member called Member2 with a netname of Netname2 to the Db2 pureScale instance sdinstA:
```
db2iupdt -add -m Member2:Netname2 sdinstA
```
3. Drop the original Db2 member.
  For example, drop the member called Member1 with a netname of Netname1 from the Db2 pureScale instance sdinstA:
```
db2iupdt -drop -m Member1:Netname1 sdinstA
```
4. Back up the database on this Db2 pureScale instance from a member that existed before you started this process if the database is recoverable.
  Recoverable databases have the logarchmeth1 or logarchmeth2 database configuration parameters set to a value other than OFF.
To move one of multiple Db2 members:
1. Stop the Db2 pureScale instance on all hosts by using the db2stop command.
  The db2iupdt -drop command must run offline, so stop the instance on all hosts by using the db2stop command.
2. Drop the Db2 members you want to move.
  For example, drop the member Member2 with a netname of Netname2 from the Db2 pureScale instance sdinstA:
```
db2iupdt -drop -m Member2:Netname2 sdinstA
```
3. Add a new Db2 member.
  For example, add Member3 with a netname of Netname3 as a member to the Db2 pureScale instance sdinstA:
```
db2iupdt -add -m Member3:Netname3 sdinstA
```
4. Back up the database on this Db2 pureScale instance from a member that existed before you started this process if the database is recoverable.
  Recoverable databases have the logarchmeth1 or logarchmeth2 database configuration parameters set to a value other than OFF.
To move the only cluster caching facility (this operation can be done online):
1. Add a new cluster caching facility.
  This addition ensures that there is always at least one cluster caching facility.
  For example, add a cluster caching facility to host cfhost2 with netname cfnet2 to the Db2 pureScale instance sdinstA:
```
db2iupdt -add -cf cfhost2 -cfnet cfnet2 sdinstA
```
2. Drop the initial cluster caching facility.
  For example, drop the cluster caching facility on cfhost1 from the Db2 pureScale instance sdinstA (Note: If performing an online drop, you must first wait for the secondary CF to reach PEER state):
```
db2iupdt -drop -cf cfhost1 sdinstA
```
To move one of two cluster caching facilities (this operation can be done online):
1. A maximum of two cluster caching facilities are supported, so you must drop one first.
  For example, drop the cluster caching facility on cfhost1 from the Db2 pureScale instance sdinstA:
```
db2iupdt -drop -cf cfhost1 sdinstA
```
2. Add the second cluster caching facility on a different host.
  For example, add a cluster caching facility to host cfhost2 with netname cfnet2 to the Db2 pureScale instance sdinstA:
```
db2iupdt -add -cf cfhost2 -cfnet cfnet2 sdinstA
```