Why are 2 ports required for a HADR Pair?

[bwmiller16]

Why are 2 ports required for a HADR Pair?

Environment: RH Linux AS3

UDB Express 8.2 with HADR Option

Folks -

Working with HADR and getting this setup to work right.

Cutting right to the chase: Why in DB2-land do we need
to have 2 ports on each machine? In this case why couldn't we just use
55005 or 55006? Why do we need both? In our knowledge
of tcp/ip, linux, etc. we see no reason other than somebody
at IBM coded it this way.

Maybe UDB is using the port number as a unique-identifier?

HADR database role = STANDBY
HADR local host name (HADR_LOCAL_HOST) =
emdb22.xyz.com
HADR local service name (HADR_LOCAL_SVC) = 55006
HADR remote host name (HADR_REMOTE_HOST) =
emdb21.xyz.com
HADR remote service name (HADR_REMOTE_SVC) = 55005
HADR instance name of remote server (HADR_REMOTE_INST) = db2admin
HADR timeout value (HADR_TIMEOUT) = 120
HADR log write synchronization mode (HADR_SYNCMODE) = SYNC

We understand that the wizard produces 2 ports; IBM support is
kinda vague on this and admit they're not sure why this is so.

We tested and suceeded with hadr ports defined both ways in a rather
crude test with no discernable concrete problems.

We're just curious and dislike mysteries, I guess.

Curious in Colorado

Bruce and Dave

[Serge Rielau]

bw********@yahoo.com wrote:

Why are 2 ports required for a HADR Pair?

Environment: RH Linux AS3

UDB Express 8.2 with HADR Option

Folks -

Working with HADR and getting this setup to work right.

Cutting right to the chase: Why in DB2-land do we need
to have 2 ports on each machine? In this case why couldn't we just use
55005 or 55006? Why do we need both? In our knowledge
of tcp/ip, linux, etc. we see no reason other than somebody
at IBM coded it this way.

Maybe UDB is using the port number as a unique-identifier?

HADR database role = STANDBY
HADR local host name (HADR_LOCAL_HOST) =
emdb22.xyz.com
HADR local service name (HADR_LOCAL_SVC) = 55006
HADR remote host name (HADR_REMOTE_HOST) =
emdb21.xyz.com
HADR remote service name (HADR_REMOTE_SVC) = 55005
HADR instance name of remote server (HADR_REMOTE_INST) = db2admin
HADR timeout value (HADR_TIMEOUT) = 120
HADR log write synchronization mode (HADR_SYNCMODE) = SYNC

We understand that the wizard produces 2 ports; IBM support is
kinda vague on this and admit they're not sure why this is so.

We tested and suceeded with hadr ports defined both ways in a rather
crude test with no discernable concrete problems.

We're just curious and dislike mysteries, I guess.

Curious in Colorado

Bruce and Dave

Answer from backstage:
"HADR_LOCAL_SVC specifies the port on local machine and HADR_REMOTE_SVC
specifies the port on remote machine. Unless hadr primary and standby
are configured on the same machine, there is no reason why they can not
use the same value."

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Steve Pearson]

Dear Curious,

There is no need to configure two ports on each machine
specifically for HADR, which will use only one each.

There is a separate HADR config parmeter for the port
on each machine so that the user may choose different
port numbers (or service names) if they so desire. This
does not mean different names/numbers are requried on
the two systems. Note, however, that HADR does require
its port(s) to be distinct from other TCP/IP ports configured
for DB2, such as that used for a client connection.

Regards,
- Steve P.
IBM DB2 UDB for LUW Development
Portland, OR

[bwmiller16]

Wow. I guess you can't be more clear than this!

The original issue arose when we imported data into the primary HADR
database with only a single HADR port defined to the standby HADR
server, we got a disconnect status

Anyway, when we switched our configuration to two HADR ports (ie 55004
and 55005) then we no longer got a disconnected status and all went
well.

There wasn't anything special about this particular database that we
were importing data into; in fact, it was smaller than 2 other
databases that worked fine on a single port. The disconnect status now
is a really huge mystery. We worked around this by importing our data
outside of HADR, defined the HADR pair, and then backed-up and restored
into the standby HADR database which worked well.

Thanks for all the input, guys. Much appreciated; hope to see you all
at IDUG.

Now we're REALLY curious in beautiful Colorado.

Bruce and Dave