Recovering from a failed db2iupdt -drop operation in a GDPC

The db2iupdt -drop operation might fail in a geographically dispersed Db2® pureScale® cluster, leaving the topology in an inconsistent state.

About this task

When you drop a host in a GDPC with the db2iupdt -drop command, it might fail if you drop a host that is a network shared disk (NSD) server. To ensure that the host drop is successful, you must check whether the host is an NSD server, and you must remove it from the NSD server list before you issue the db2iupdt -drop command.

Procedure

  1. Put the cluster into maintenance mode.
  2. Check whether the host is an NSD server.
    Run the following commands to check. In this example, HostA1 is an NSD server and HostB1 becomes the new NSD server.
    mmlsnsd| grep HostA1
File system Disk name NSD servers
datafs gpfs2nsd HostB1,HostA1
db2fs1 gpfs9nsd HostB1,HostA1
logfs gpfs6nsd HostB1,HostA1
    If the host is in the NSD server list, it must be removed. You can remove the host by creating an NSD server list.
    1. Create an NSD server list file that contains the NSD servers for each NSD.
      cat /tmp/nsd.txt
gpfg2nsd:HostB1
gpfs9nsd:HostB1
pfgs6nsd:HostB1
    2. Update the instance so that it uses the new NSD server list. Issue the following command as root.
      mmchnsd -F /tmp/nsd.txt
  3. Exit cluster maintenance mode.
  4. Wait for GPFS to become active.
  5. Issue the db2iupdt -drop command with the host that you want to drop. 
    db2iupdt -drop HostA1