1

I have a multi-subnet AlwaysON AG with one primary and one secondary replica in synchronous commit mode. Due to hardware maintenance the IP address of the secondary node will change.

Is there any actions I should take or anything I should be aware of from a SQL Server, AlwaysON Availability Groups and WSFC perspective?

1

Due to hardware maintenance the IP address of the secondary node will change.

This shouldn't be a problem if the node ip itself is changing. It's only a slight issue if cluster resource ips are changing.

Is there any actions I should take or anything I should be aware of from a SQL Server, AlwaysON Availability Groups and WSFC perspective?

From the WSFC point of view, assuming that the subnet does not change, there shouldn't be anything needed here.

From SQL Server/AlwaysOn AGs... assuming the subnet does not change:

  • Double check the AG endpoint to see if it's bound to that specific ip. If it is, that will need changed. If it isn't (wizard generated, etc.) it'll say 'ALL' and that won't need changed.
  • If SQL Server was setup to listen on specific ip's and ports in configuration manager, this will need changed. If it's set for IPALL, nothing needs done.
  • If you're using read only routing, double check the read only routing urls and endpoints.
  • Service broker endpoints (similar to AG endpoint)

From an overall point of view:

  • Make sure the firewall rules have been edited for the new ip if needed.

This may not be an exhaustive list, but should give you an idea and the most critical areas to look at.

  • You've confirmed what I thought through testing in my own lab environment. No issues from a SQL Server / AG perspective as nothing bound to specific IPs. However, in my lab, after changing the IP of the node hosting the secondary replica, the node shows as offline in Failover Cluster Manager, the AG is no longer in a healthy state as the secondary replica is not synchronising as you'd expect. After a few seconds, the new IP of the secondary node is picked up, the node shows as online in FCM and the AG returns to a healthy state. Can anything be done to prevent this? – Fza Aug 4 '16 at 9:09
  • 1
    The only thing that could be done is to add the new IP address to the node before removing the old one. This would require having two different interfaces, which I doubt currently exists. This way the cluster would build the internal routes and health checks would still pass. Additionally you can pause the node and make changes, but it'll still have the blip since it's paused. – Sean Gallardy Aug 4 '16 at 14:48
  • There is only one secondary replica and cluster quorum is currently node majority and file share witness, would this work; alter cluster quorum settings to remove vote of secondary node, remove secondary replica from AG, secondary replica will be offline and come online with new IP, re-add secondary replica to AG, alter cluster quorum settings so secondary node has a vote. Do you forsee any issues with that? Or would you recommend instead of removing the secondary replica, just removing all the databases from the AG instead? – Fza Aug 4 '16 at 19:53
  • 1
    In the environment listed there will be no difference. – Sean Gallardy Aug 5 '16 at 4:36

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.