Recently, I was working on a database using HADR with failover handled by TSAMP. The database was configured to use a virtual IP (VIP) address. However, when I tested the failover with the application team, some of the applications were getting SQL1776N errors from the database. We quickly recognized that the applications were trying (and failing) to connect to the same physical server (which had become the standby copy) instead of the new primary, even though TSAMP had moved the VIP to the standby server. It was clear that some of the applications had not been configured to use the VIP.<\/p>\n
In an environment with tens or hundreds of client machines that connect to a database, it’s relatively easy for someone to make a mistake when setting up a database connection on one of the machines. In a production environment, though, it’s not always feasible to wait until a failover occurs (whether scheduled or unscheduled) in order to validate that all of the applications have been configured correctly.<\/p>\n
Fortunately, it is possible to verify, from the database server, which IP address clients are using to connect to the database.<\/p>\n
First, take a look at which IP addresses are in use on your system. The ip<\/span> command is used on Linux systems to display configuration information:<\/p>\n In this example output, the physical server’s IP address is 172.16.171.15<\/strong>, and the VIP is 172.16.171.25<\/strong>. Knowing both of these IP addresses is important when reviewing the list of active connections.<\/p>\n The netstat<\/span> command lists open network and socket connections on the server, showing the source IP address and port, as well as the target IP address and port. By filtering specifically for the Db2 TCPIP port(s), we get this information:<\/p>\n In the output above, the 4th column shows the IP address\/port on the database server, and the 5th column represents the IP address\/port on the client workstation.<\/p>\n Looking in the 4th column, note that all connections except for one are using the VIP (172.16.171.25). However, one connection is coming via the physical IP address (172.16.171.15):<\/p>\n The fifth column indicates that the machine 172.16.171.22<\/strong> has been configured to connect to Db2 using the physical IP address instead of the VIP. Using this information, the team responsible for the application on this server can review and resolve the configuration problem.<\/p>\n The commands in this post will work on Linux systems; however, this methodology can be applied to other UNIX platforms and Windows. On UNIX forms you will need to use the ifconfig<\/span> command to display the database server’s IP addresses; Windows has the ipconfig<\/span> command. The netstat<\/span> command is available on all platforms, the -n<\/span> option is particularly useful as it displays IP addresses rather than (truncated) hostnames.<\/p>\n Fortunately, the misconfiguration I encountered occurred during a failover test, meaning that there was no real impact to the business as a result of the misconfiguration. Finding these problems is exactly the reason why testing is so important for any environment that has high availability requirements. However, using the methods from this blog post, you should be able to identify issues in your environment \u2013 before they become problems.<\/p>\n","protected":false},"excerpt":{"rendered":" Recently, I was working on a database using HADR with failover handled by TSAMP. The database was configured to use a virtual IP (VIP) address. However, when I tested the failover with the application team, some of the applications were getting SQL1776N errors from the database. We quickly recognized that the applications were trying (and […]<\/p>\n","protected":false},"author":37,"featured_media":37309,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","content-type":"","footnotes":""},"categories":[4166,17],"tags":[4156,4088,3930,3992],"class_list":["post-37303","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-db2","tag-db2-high-availability","tag-failover","tag-hadr","tag-tsamp"],"yoast_head":"\n\n$ ip address show \n1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 \n link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 \n inet 127.0.0.1\/8 scope host lo \n valid_lft forever preferred_lft forever \n2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 \n link\/ether 00:0c:29:b2:70:12 brd ff:ff:ff:ff:ff:ff \n inet 172.16.171.15\/24 brd 172.16.171.255 scope global eth0 \n valid_lft forever preferred_lft forever \n inet 172.16.171.25\/24 brd 172.16.171.255 scope global secondary eth0:0 \n valid_lft forever preferred_lft forever \n3: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 \n link\/ether 00:0c:29:b2:70:1c brd ff:ff:ff:ff:ff:ff \n inet 192.168.242.15\/24 brd 192.168.242.255 scope global eth1 \n valid_lft forever preferred_lft forever\n<\/code><\/pre>\n\n$ netstat -tn | grep 50000 \ntcp 0 0 172.16.171.25:50000 172.16.171.18:62586 ESTABLISHED \ntcp 0 0 172.16.171.25:50000 172.16.171.17:62380 ESTABLISHED \ntcp 0 0 172.16.171.25:50000 172.16.171.18:62531 ESTABLISHED \ntcp 0 0 172.16.171.25:50000 172.16.171.18:62337 ESTABLISHED \ntcp 0 0 172.16.171.25:50000 172.16.171.19:62647 ESTABLISHED \ntcp 0 0 172.16.171.25:50000 172.16.171.19:62311 ESTABLISHED \ntcp 0 0 172.16.171.15:50000 172.16.171.22:62912 ESTABLISHED \ntcp 0 0 172.16.171.25:50000 172.16.171.17:61344 ESTABLISHED \n<\/code><\/pre>\n\ntcp 0 0 172.16.171.15:50000 172.16.171.22:62912 ESTABLISHED <\/code><\/pre>\nPlatform Portability<\/h4>\n
Conclusion<\/h4>\n