January 29, 2019 at 11:28 am
Hello all,
We are in the process of upgrading a 2012 instance ( with alwaysOn ) over to 2016. We now have 4 failover nodes with FCI.
Question is ... would it be possible to add 4 more nodes to the same cluster with a instance of SQL Server 2016 using the same storage and then migrate to those and decommission the old 2012 nodes ?
Thank you !
Johnny
January 30, 2019 at 11:36 am
You can't add a 2016 node, AFAIK, but you can add a 2012 node and then upgrade that to 2016. The upgrade process is that you upgrade secondary nodes and eventually fail over to an upgraded node and then upgrade the last node. If you want to change hardware, you'd then be adding new hardware as 2012, then upgrade to 2016, then remove an old 2012 node.
This talks about R2, but I believe the process is the same with WS2012.
January 30, 2019 at 11:54 am
Steve Jones - SSC Editor - Wednesday, January 30, 2019 11:36 AMYou can't add a 2016 node, AFAIK, but you can add a 2012 node and then upgrade that to 2016. The upgrade process is that you upgrade secondary nodes and eventually fail over to an upgraded node and then upgrade the last node. If you want to change hardware, you'd then be adding new hardware as 2012, then upgrade to 2016, then remove an old 2012 node.This talks about R2, but I believe the process is the same with WS2012.
Thank you for the response !
Just to be clear I am referring to a SQL 2012 instance and a SQL 2016 NOT windows server OS
4 nodes on WS2012 with SQL 2012
Project is to add sharing same storage
4 more nodes on WS2012 with SQL 2017
January 30, 2019 at 12:48 pm
Ah, ok.
Then I believe the same principle applies. You can't add a new SQL node at 2016 because the database version is different. What you do is add a SQL 2012 node, then upgrade it. This means you have a cluster that if a failover occurs, you'll be in a one node cluster state because you can't fail back. The storage won't allow it.
You could add 4 new ones and then upgrade all 4 if your edition/license allows you 8 SQL nodes. Then failover to these nodes and eject the old ones from the cluster.
January 30, 2019 at 1:01 pm
Steve Jones - SSC Editor - Wednesday, January 30, 2019 12:48 PMAh, ok.Then I believe the same principle applies. You can't add a new SQL node at 2016 because the database version is different. What you do is add a SQL 2012 node, then upgrade it. This means you have a cluster that if a failover occurs, you'll be in a one node cluster state because you can't fail back. The storage won't allow it.
You could add 4 new ones and then upgrade all 4 if your edition/license allows you 8 SQL nodes. Then failover to these nodes and eject the old ones from the cluster.
Actually just an correction...
We would add 4 new nodes of WS2016 with SQL 2016 onto the WS2012 cluster and they would not be active only sharing the same storage until the cutover when we migrate the databases then we would disable the WS2012 nodes .
This is what we want to do ... feasible ?
January 30, 2019 at 1:56 pm
Again, I don't think you can add SQL2016 nodes. You'd add SQL 2012 nodes and upgrade them to SQL 2016 in place.
January 30, 2019 at 2:04 pm
Steve Jones - SSC Editor - Wednesday, January 30, 2019 1:56 PMAgain, I don't think you can add SQL2016 nodes. You'd add SQL 2012 nodes and upgrade them to SQL 2016 in place.
We just want to make it as seamless as possible using the same storage as present with SQL 2012 and building within the same cluster.
So no go I guess
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply