patternsqlMinor
SQL Server Always-On Availability Groups Patching
Viewed 0 times
groupssqlalwaysavailabilityserverpatching
Problem
My SQL server farm has been neglected with patching OS level & SQL server level (because they are critical systems, outages are hard to come by).
An option is to patch the secondary nodes of our AOAG clusters up to the latest patch one month, then the next month the business agree to schedule a fail over out of hours.. I can then patch the new secondary (old primary). This will mean the nodes wont be on the same patch level for a month.. is this “a no no”?
An option is to patch the secondary nodes of our AOAG clusters up to the latest patch one month, then the next month the business agree to schedule a fail over out of hours.. I can then patch the new secondary (old primary). This will mean the nodes wont be on the same patch level for a month.. is this “a no no”?
Solution
This is an unsupported configuration as per the docs
Mixing versions of SQL Server instances in the same AG is not supported outside of a rolling upgrade and should not exist in that state for extended periods of time as the upgrade should take place quickly. The other option for upgrading SQL Server 2016 and later is through the use of a distributed availability group.
What does this mean practically? It might be completely fine - there may be zero compatibility issues and it could go swimmingly. It also might not. Microsoft has not tested the configuration you are running if you choose to mix versions between instances. At that point for me personally, the risks far outweigh the advantages.
It's also worth noting that using the rolling upgrade process as defined in the link I posted reduces downtime to a minimal figure anyway. If that's still not good enough, why not build two new servers and a new AG, and migrate to them, rather than patching? It's a lot more work but you should be able to minimise downtime even further.
Mixing versions of SQL Server instances in the same AG is not supported outside of a rolling upgrade and should not exist in that state for extended periods of time as the upgrade should take place quickly. The other option for upgrading SQL Server 2016 and later is through the use of a distributed availability group.
What does this mean practically? It might be completely fine - there may be zero compatibility issues and it could go swimmingly. It also might not. Microsoft has not tested the configuration you are running if you choose to mix versions between instances. At that point for me personally, the risks far outweigh the advantages.
It's also worth noting that using the rolling upgrade process as defined in the link I posted reduces downtime to a minimal figure anyway. If that's still not good enough, why not build two new servers and a new AG, and migrate to them, rather than patching? It's a lot more work but you should be able to minimise downtime even further.
Context
StackExchange Database Administrators Q#248866, answer score: 6
Revisions (0)
No revisions yet.