Currently, db2haicu does limited hostname validation during
setup. If the user input hostnames are not the same as the
hostnames defined from the uname value, this can lead to
problems post-configuration.
This discrepancy can cause control takeover attempt (issuing db2
takeover ...) to potentially fail. It can also cause problems
locking the resources, thus affecting db2stop operation.
As part of the HADR integrated solution, DB2 engine code will
generate IBM.Test flags based on the local uname value for the
remote host to act upon. If there is a name discrepancy between
the name obtained from uname and the name known to SA MP
resources, the remote host will expect a different IBM.Test
resource than the actual one created by the local host.
This will prevent the proper handshake from occurring. When this
happens, the monitor script will return Offline for both hosts.
Thus, SA MP will act on this perceived failure: an apparent
second takeover will occur using the BY FORCE option and a split
brain may result.
This symptom may not surface if the HADR resource is locked at
the time, so the problem can appear to be intermittent.
Another symptom is failure to lock the resource during db2stop.
SA MP will then see the resource as down and automatically
restart the instance.
As an example, the IBM.Test resource will be named to include
the value from uname, if the SA MP defined name is different,
the flag created one one server, will not be what is searched
for on the other server. Some of the discrepancies can be seen
in the db2gcf messages when DIAGLEVEL is at 4.
uname -a
AIX server2-uname 1 6 00CCCAFC4C00
And to SA MP, server2 is defined only as "server2" instead of
"server2-uname"
Server1 will look for resources with "server2" in the name:
2011-02-06-08.53.21.705198-360 I4304220A900 LEVEL: Info
PID : 1311660 TID : 1 PROC : db2gcf
INSTANCE: db2inst1 NODE : 000
EDUID : 1
FUNCTION: DB2 Common, Generic Control Facility, gcf_start,
probe:199
DATA #1 : String, 32 bytes
db2_db2inst1_db2inst1_SAMPLE-rs
DATA #2 : String, 50 bytes
db2_SAMPLE_ClusterInitiatedMove_db2inst1_db2inst1
DATA #3 : String, 60 bytes
db2_SAMPLE_server1_VirtualOffline_db2inst1_db2inst1
DATA #4 : String, 57 bytes
db2_SAMPLE_server2_Reintegrate_db2inst1_db2inst1
DATA #5 : String, 63 bytes
db2_SAMPLE_server1_UserInitiatedMove_db2inst1_db2inst1
DATA #6 : String, 57 bytes
db2_SAMPLE_server2_UserMoveAck_db2inst1_db2inst1
While Server2 will create resources using "server2-uname":
2011-02-06-07.50.10.715633-360 I775112A910 LEVEL: Info
PID : 4456726 TID : 1 PROC : db2gcf
INSTANCE: db2inst1 NODE : 000
EDUID : 1
FUNCTION: DB2 Common, Generic Control Facility, gcf_start,
probe:199
DATA #1 : String, 32 bytes
db2_db2inst1_db2inst1_SAMPLE-rs
DATA #2 : String, 50 bytes
db2_SAMPLE_ClusterInitiatedMove_db2inst1_db2inst1
DATA #3 : String, 65 bytes
db2_SAMPLE_server2-uname_VirtualOffline_db2inst1_db2inst1
DATA #4 : String, 57 bytes
db2_SAMPLE_server1_Reintegrate_db2inst1_db2inst1
DATA #5 : String, 68 bytes
db2_SAMPLE_server2-uname_UserInitiatedMove_db2inst1_db2inst1
DATA #6 : String, 57 bytes
db2_SAMPLE_server1_UserMoveAck_db2inst1_db2inst1
This apar will cause db2haicu to report the problem and block
the cluster setup. It will not impact an already existing
cluster. |
