March 18, 2016 at 12:21 pm
I want to upgrade a cluster named instance from SQL Server 2008 to SQL Server 2008 R2. With that upgrade we would then have two instances with SQL 2008 (currently 3), 2 with SQL 2008 R2 (currently 1). Doing a standalone upgrade itself is straight forward. This is a cluster named instance.
Are the steps similar? I've googled this and frankly I'm confused. My reading initially suggested starting on the passive node - which by definition would not have an instance on it.
Looking at URL: https://msdn.microsoft.com/en-us/library/ms191295(v=sql.105).aspx seems more appropriate. This suggests upgrading an instance.
I'm not 100% certain on this. I'm still reviewing but if you have any comments, it would be appreciated.
Thanks.
March 21, 2016 at 8:57 am
Thought you might be interested:
Did some further investigation Friday. The method we used was for a two node cluster with 4 instances (we want to upgrade just one of the named instances):
1. Via failover cluster manager, move all instances over to active node. We designated node 1 as our primary/active node.
2. Login to passive node (there are no instances on the node).
3. Upgrade the passive node via SQL Server Installation Center software (which has upgrade option). During the upgrade you will be required to select the named instance you want to upgrade.
4. Upon completion - reboot node.
5. Install SQL server pack (you will be required to select the named instance you want to upgrade).
6. Upon completion - reboot node.
7. Login to active node. Via failover cluster manager move all instances over to passive node.
8. Active node no longer has any instances on it - it is in effect passive node.
9. Repeat steps 3 through 6.
10. Review content, update statistics, checkdb. And for me - do a version check.
URL that helped: https://msdn.microsoft.com/en-us/library/ms191295(v=sql.105).aspx
That's it.
March 29, 2016 at 11:32 am
Thanks for sharing the steps
April 1, 2016 at 12:34 pm
your steps are correct, just make sure you take full backup of all databases and backup up all master keys (if you have database encryption).
April 1, 2016 at 12:57 pm
Taking a database backup is an excellent point. I did that but forgot to mention.
Here's another issue which I was stuck on. With stand alone instances, any kind of major update, we take a snapshot of the server. If we have any kind of issue we just revert back to it. With a cluster environment, my understanding, you can't do that. You can shut the node down but your instances move over - that's the point of high availability. Net result, once you start making changes - you cannot go back.
As a precaution, I set up a VM, with the same SQL version. I could get away with this because the named instance right now is small (storage, memory and processing power requirements). Any alternative ideas I like to hear.
Another subject altogether, while MSFT SQL clustering is not a bad technology, I'd prefer to move to a VM farm. We have one more database migration, once that's done, we start discussions in earnest. Leave it on the cluster, VM farm or perhaps Azure.
April 1, 2016 at 1:08 pm
I am not sure if you are able to take a full image of your servers while it is clustered, I have only done it with standalone servers.
In case things go bad, you need to know exact version of SQL you are running in order to restore master DBs.
Always on is another option to consider for high availability (in future).
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply