0

I am using a 2 node SQL AG (2014 EE) (each on a different subnet) and the Listener is configured with 2 Static IPs. The client application uses SQL Native Client 11.4. My understanding is that this driver is legacy and hence should not support failover with RegisterAllProvidersIP as 1 and default HostRecordTTL( 20 minutes). Although I am unable to failover when RegsiterAllProvidersIP is 0 and TTL is 20 minutes (I am able to when TTL is lowered to say, 2 minutes), the application successfully fails over with RegisterAllProvidersIP set as 1. According to the blog here, https://blogs.msdn.microsoft.com/alwaysonpro/2014/06/03/connection-timeouts-in-multi-subnet-availability-group/ It is recommended to set RegisterAllProvidersIP to 0 and HostRecordTTL to 2 minutes to achieve failover, but in my case I found that it is not needed as I am able to failover with RegisterAllProvidersIP set as 1. Am I completely missing the point of recommended settings from MS blog or my multi subnet setup has any issues?

2
  • SQLNCLI11 should be the first version to support multisubnetfailover, you shouldn't need to touch the registerallproviderip setting - even if you did, you'd need to wait for the cache to timeout and cleanup for the failover to work properly. – Sean Gallardy - Retired User Mar 6 '19 at 11:28
  • We are using the OLEDB flavor of SQLNCLI11 which does not support multisubnetfailover out of the box. My concern is that even with RegisterAllProvidersIP set to 1 failover is happening consistently without any noticeable delay/latency (not inline with MS recommended settings ). – Shubha Lakshmi Mar 6 '19 at 17:28
0

We are using the OLEDB flavor of SQLNCLI11 which does not support multisubnetfailover out of the box.

Microsoft has deprecated the native client, however, they have released a new OLE DB driver which supports all the native client features plus adds MultiSubnetFailover and TLS1.2 support. See the announcement here. It may be worth looking at upgrading OLE DB to take advantage.

My understanding is that this driver is legacy and hence should not support failover with RegisterAllProvidersIP as 1 and default HostRecordTTL( 20 minutes). Although I am unable to failover when RegsiterAllProvidersIP is 0 and TTL is 20 minutes (I am able to when TTL is lowered to say, 2 minutes), the application successfully fails over with RegisterAllProvidersIP set as 1.

With the RegisterAllProvidersIP = 0 and TTL = 20 combo, you would need to wait up to twenty minutes post-failover for the new listener IP to be registered in DNS and picked up by your clients. It is still technically 'working' it's just very slow.

According to the blog here, https://blogs.msdn.microsoft.com/alwaysonpro/2014/06/03/connection-timeouts-in-multi-subnet-availability-group/ It is recommended to set RegisterAllProvidersIP to 0 and HostRecordTTL to 2 minutes to achieve failover, but in my case I found that it is not needed as I am able to failover with RegisterAllProvidersIP set as 1. Am I completely missing the point of recommended settings from MS blog or my multi subnet setup has any issues?

  • How are you testing to validate that failover works?
  • What is your connection timeout?

With RegisterAllProvidersIP set to 1, the native client will try and connect to each IP address returned by DNS serially. If the first IP returned by DNS is the correct one it connects, if not it takes ~20 seconds to timeout, then waits ~20 seconds then tries the next IP.

What this means is if your connection timeout is greater than ~40 seconds, its quite possible that you're seeing the behaviour in question but a high connection timeout value is masking it.

Either way, the true fix here is to start using MultiSubnetFailover to make the best use of the rapid failover capabilities provided by RegisterAllProvidersIP=1. If you don't want upgrade the OLE DB driver, you should set a low TTL for the listener DNS entry and set RegisterAllProvidersIP=0. It may work for you now with it set to 1, but conditions in your environment could change and cause this to suddenly stop working.

1
  • Thanks, as of now we are not planning to upgrade the driver. We are verifying that failover is working by reading content from DB through our Application. I think we will go with Publishing only the active IP and lower TTL approach. – Shubha Lakshmi Mar 7 '19 at 8:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.