search

ibmdb / node-ibm_db

IBM DB2 and IBM Informix bindings for node
MIT License
188 stars 151 forks source link

Application trying to connect to old Primary (Standby) from HADR #870

Closed fsmegale closed 1 year ago

fsmegale commented 2 years ago

Hello.

Customer is using the last version of node-ibm_db

ibmdb/node-ibm_db https://github.com/ibmdb/node-ibm_db

He had ROS (Read-Only Standby) enabled in the HADR from Db2 Server. He uses VIP in the TSA.

The application has the VIP configured in the datasource.

He does a first takeover. We are not sure if everything works fine (no logs from that time).

When he does another takeover the VIP goes to the new Primary but the Application keeps trying to connect to the old Primary (new Standby).

As ROS is enabled, the application connects to the old Primary and tries to write to the database. As writing to the Standby is not supported, the application gets a -1773 from Db2 Server. With ROS disabled, the application gets another error when trying to connect.

Customer needs to restart the application to make it work again.

Any idea about what could be causing that behavior? Is there any MAC address cache (related to the old Standby) made be the driver?

Thanks Felipe

.

techabhay366 commented 2 years ago

Hi Felipe , What is the status of TSA cluster when you issued the takeover command ? lssam command output.

Also , have you configured alternate server in primary and standby databases for ACR auto client reroute ? update alternate server ...

bimalkjha commented 2 years ago

@fsmegale When ibm_db connect first time to the Primary of HADR, post connection, server sends the info about primary and secondary server to client. client keeps this info in memory and use for future connection. On second connection request, if connection to primary fails, client will retry connection to secondary as per the configuration received from the server. ibmdb.open() will always try to connect the the DB:hostname:port given in the connection string. If connection fails, then only it goes for retry to the alternate host. To get more clarity about what is going in your client system, we need db2trace. Try to reproduce the problem using a small test script and collect the db2trace files by following below commands:

db2trc on -f 1.trc
node test.js
db2trc off
db2trc flw 1.trc 1.flw
db2trc fmt 1.trc 1.fmt

zip all generated files with complete output of node test.js and share here. Thanks.

bimalkjha commented 1 year ago

@fsmegale Closing this issue now due to inactivity. We can reopen it once we have the requested db2trace files as per above update. Thanks.