Customers migrating from v91 to v98 are facing difficulties when
trying to setup high availability (HA) environments. They are
accustomed to using v8 and v91 methods for node fail-over.
The functionality introduced in v95 and later for failover is:
If no port 0 exists on the target machine (that is, no nodes are
currently associated with it), then there are two steps to
fail-over:
1. Serially move any node from the source machine that is not
port 0 to the target at port 0.
2. In parallel, move all remaining nodes (or one by one if so
desired with port 0 on source being last)
If there does exist nodes on the target machine already, this
operation does not require the serial step. All nodes can be
moved in parallel.
To move nodes in parallel, follow the following is necessary:
Given:
0 one.ca.ibm.com 0
1 one.ca.ibm.com 1
2 one.ca.ibm.com 2
Port 0 non-existent on target machine
1. Serial
$ db2start dbpartitionnum 2 restart hostname two.ca.ibm.com port
0
2. In Parallel
$ db2start dbpartitionnum 1 restart hostname two.ca.ibm.com port
1 &
$ db2start dbpartitionnum 0 restart hostname two.ca.ibm.com port
2 &
Port 0 exists on target machine
In Parallel
$ db2start dbpartitionnum 2 restart hostname two.ca.ibm.com port
1 &
$ db2start dbpartitionnum 1 restart hostname two.ca.ibm.com port
2 &
$ db2start dbpartitionnum 0 restart hostname two.ca.ibm.com port
3 &
Otherwise the following error will occur:
SQL6031N Error in the db2nodes.cfg file at line number "3".
Reason code "13".
Also when trying to start on the target machine a node that is
port 0 on the source machine first, the failover might appear to
hung showing timeout errors in the db2diag.log:
FUNCTION: DB2 UDB, base sys utilities, sqleGetSpinLock, probe:40
DATA #1 : String, 64 bytes
Waited for other mlns to complete(mlns,elapsed time in seconds):
DATA #2 : Hexdump, 4 bytes
0x0FFFFFFFFFFF74C8 : 0000 000A ....
DATA #3 : Hexdump, 4 bytes
0x0FFFFFFFFFFF74CC : 0000 000C ....
...
FUNCTION: DB2 UDB, base sys utilities, sqleGetSpinLock, probe:50
DATA #1 : String, 88 bytes
Time out in port zero host restart,while waiting for other mlns
on sam
host to complete
DATA #2 : Hexdump, 4 bytes
0x0FFFFFFFFFFF74C8 : 0000 000A ....
DATA #3 : Hexdump, 4 bytes
0x0FFFFFFFFFFF74CC : 0000 00F0
The functionality for v9.5 and later introduced a parallel start
feature, which means that logical port 0 will have to be moved
last, not first.
This APAR will allow for the old v9.1 behaviour to be available
in v9.5 and later |
