January 4, 2021 at 6:59 am
Hello,
I'm looking for the best way to go from existing 2012 Enterprise AlwaysON Cluster to SQL 2016 Enterprise AlwaysON .
Existing setup:
2 nodes with OS 2012R2 and SQL Server 2012 Enterprise on latest service pack.
Goal for new setup:
Purchased 2 new servers that I want to be the final 2 new servers.
Have built the new servers with OS Server 2012 R2
Have installed SQL server 2016 Enterprise on both.
https://creditcardsupportx.com
https://creditcardsupportx.com/target-red-credit-card
https://creditcardsupportx.com/baby-r-us-credit-card
Theory:
1: Move the primary role to the secondary node, and upgrade the existing node to SQL 2016 Enterprise
2: Move the primary role back to the primary node that I just upgraded, and then upgrade node 2 to SQL 2016 Enterprise
3: Add one off the new server to the existing cluster and join it to the AlwaysON cluster. Ensure synchronization.
4: Add the second new server to the existing cluster and join it to the AlwaysON cluster. Ensure synchronization.
5: Remove the old servers from the cluster.
Reality as we speak - and current problem:
As soon as I move the primary role back to the primary node, I experience problems with the server unable to synchronize the database:
Error is: "At least one availability database on this availability replica has an unhealthy data synchronization state. If this is an asynchronous-commit availability replica, all availability databases should be in the SYNCHRONIZING state. If this is a synchronous-commit availability replica, all availability databases should be in the SYNCHRONIZED state."
Does anyone know the best way to upgrade existing AlwaysON SQL 2012 setup to SQL 2016 on new hardware?
thanks
jackyjoy
January 4, 2021 at 7:53 pm
You should review the following articles:
https://mssqltrek.com/2020/02/12/always-on-availability-groups-rolling-upgrades/
https://sqlha.com/2019/08/15/ags-and-wsfc-os-rolling-upgrades-what-works-and-what-doesnt/
In general, the way to upgrade is the following:
So - in your scenario it would be much easier to add the new nodes to the cluster, add the new instances on those nodes to the AG and let them synchronize. Once synchronized, failover to the new primary node...at this point you cannot failback to the old primary or old secondary - so remove them from the AG and evict them from the cluster.
Review the AG configuration and verify everything is correct.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply