IV67580: MEMBER NETNAME CHANGED TO BE SAME AS CF AFTER KILL MEMBER IF MEMBER AND CF ARE CO-LOCATED AND CF HAS DIFFERENT SET OFNETNA

DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 10 for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 11 for Linux, UNIX, and Windows

APAR status

• Closed as program error.

Error description

• It's a new setup.
  
  Member 0 and CF 129 locate on TESTPS1
  Member 1 and CF 128 locate on TESTPS2
  
  Member 0 netname: PS1_M_PRIV1,PS1_M_PRIV2
  Member 1 netname: PS2_M_PRIV1,PS2_M_PRIV2
  CF 128 netname: PS2_C_PRIV1,PS2_C_PRIV2
  CF 129 netname: PS1_C_PRIV1,PS1_C_PRIV2
  
  Customer run the following procedures:
  
  ./db2icrt  -d -p 50000 -u db2ftest -m TESTPS1 -mnet
  PS1_M_PRIV1,PS1_M_PRIV2 -cf TESTPS2 -cfnet
  PS2_C_PRIV1,PS2_C_PRIV2  -instance_shared_dev /dev/dm-15
  -instance_shared_mount /db2shared -tbdev /dev/dm-16 db2itest
  
  ./db2iupdt -add -cf TESTPS1 -cfnet PS1_C_PRIV1,PS1_C_PRIV2
  db2itest
  ./db2iupdt -add -m TESTPS2 -mnet PS2_M_PRIV1,PS2_M_PRIV2
  db2itest
  
  Firstly, they ifdown member 0's netnames to test member down.
  Everything is fine.
  
  Then, they made member 0 up and ifdown CF 129's netnames to
  test CF down, but noticed member 0 also went down.
  
  Checking db2nodes.cfg, found member 0's netnames were changed
  to be same as CF 129, which explained why member 0 went down.
  
  The problem is related to the DN (Domain Node) entry in HA
  registry, run command "db2hareg -dump":
  
  A05000400000000,IN,100,2,0,1
  A05000400000000,DN,TESTPS1,,PS1_C_PRIV1,PS1_C_PRIV2
  A05000400000000,NL,128,TESTPS2,0,PS2_C_PRIV1,PS2_C_PRIV2,-,CF
  A05000400000000,NL,0,TESTPS1,0,PS1_M_PRIV1,PS1_M_PRIV2,-,MEMBER
  A05000400000000,MO,/db2shared, ,0,7,0
  A05000400000000,RU,32872,32736
  A05000400000000,NL,1,TESTPS2,0,PS2_M_PRIV1,PS2_M_PRIV2,-,MEMBER
  A05000400000000,DN,TESTPS2,,PS2_M_PRIV1,PS2_M_PRIV2
  A05000400000000,NL,129,TESTPS1,0,PS1_C_PRIV1,PS1_C_PRIV2,-,CF
  A05000400000000,DB,TESTDB,1
  A05000400000000,MO,/db2testdata01,TESTDB,0,7,0
  A05000400000000,MO,/db2testdata02,TESTDB,0,1,0
  A05000400000000,MO,/db2testdata03,TESTDB,0,1,0
  A05000400000000,MO,/db2testtemp01,TESTDB,0,1,0
  A05000400000000,MO,/db2diag, ,0,1,0
  
  When the first time member 0 went down, its entry in
  db2nodes.cfg was wrongly updated by the DN entry of TESTPS1.
  

Local fix

• The following workaround is only for testing purpose:
  
  db2stop
  
  db2hareg -del DomainNode hostname=TESTPS1
  
  db2hareg -add DomainNode
  hostname=TESTPS1,tag=PS1_M_PRIV1+PS1_M_PRIV2
  
  double check that the HA registry is correct after the change
  with "db2hareg -dump"
  
  modify db2nodes.cfg file and correct the netnames for member 0
  to  PS1_M_PRIV1 and PS1_M_PRIV2
  
  db2start
  
  check that there are no alerts and all the netnames/hosts are
  correct from "db2instnace -list" output
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * user who use db2 v10.5 with purescale feature                *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * See Error Description                                        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Update to 10.5.0.6 or above                                  *
  ****************************************************************
  

Problem conclusion

• Problem Fixed In 10.5.0.6
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  DB2 PURESCALE F

• Fixed component ID

  5724Y6900

Applicable component levels