October 12, 2015 at 11:31 am
We ran into a problem with our new SQL cluster where the failover node needed to be rebuilt. When it came back, there were other issues and the server team dissolved the entire cluster to rebuild it. (They did not rebuilt windows, just the cluster). But they did this after our SQL Server cluster nodes had been installed.
The cluster has just been released back to me. I've got a thing to do before I can log back on the servers and verify stuff, but now I'm wondering. They broke the cluster, how did that affect SQL Server?
Do I need to uninstall and reinstall SQL Server for this cluster? Will SQL just accept being added back into the cluster without issue?
Has anyone gone through something like this before?
October 12, 2015 at 12:54 pm
destroying the cluster without uninstalling is not a recommended option. Evicting a node and re adding without uninstalling has not produced issues for me in the past.
Personally, based on what you say they've done i would prefer a complete clean install.
Why did they destroy the cluster in the first place, bit of a knee jerk reaction IMHO?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 13, 2015 at 4:20 am
Perry Whittle (10/12/2015)
destroying the cluster without uninstalling is not a recommended option. Evicting a node and re adding without uninstalling has not produced issues for me in the past.Personally, based on what you say they've done i would prefer a complete clean install.
Why did they destroy the cluster in the first place, bit of a knee jerk reaction IMHO?
The node they had to rebuild wasn't recognized as a possible storage owner for the other nodes. So they blew up the cluster to figure out why and couldn't figure it out. Finally they realized a DLL didn't get registered.
So now I get to go back and clean up after them. And yes, I agree it was a knee jerk reaction. But I couldn't stop them.
October 14, 2015 at 6:02 am
Following up on this for future reference.
When they recreated the node, they created the SQL roles as windows roles (which they also did the first time around). And the storage was assigned to those roles, so not showing available to SQL Server. Because of this, I had to remove all the SQL nodes from the cluster and start over from scratch.
Note: I did NOT uninstall SQL Server as a whole. I just went into the setup tool, to Maintenance -> Remove Node and removed all the nodes, including the primary node of each server.
Now I am recreating the primary nodes, then will go in and add each node to the other servers, and hopefully that will resolve the issue. We'll see.
October 14, 2015 at 6:45 am
Interesting note. As I was attempting to install the 3 nodes at the same time (different servers), I was watching the Failover Cluster Management tool. It auto-flipped the available storage over to the latest SQL install as it started. So one of my node installs failed because it hadn't yet gotten an "ownership handle" on its storage when I started the next node's install.
This happened before I even reached the page where I choose the disks for the new node.
So, apparently nodes DO have to be done one at a time. Or at least, the next New Failover Cluster install can't start until that ownership handle grabs the chosen storage or all the available storage will flip to the other node and the install will fail.
Huh. The things one learns when one is paying attention to other tools.
October 14, 2015 at 6:57 am
Brandie Tarvin (10/14/2015)
Interesting note. As I was attempting to install the 3 nodes at the same time (different servers), I was watching the Failover Cluster Management tool. It auto-flipped the available storage over to the latest SQL install as it started. So one of my node installs failed because it hadn't yet gotten an "ownership handle" on its storage when I started the next node's install.This happened before I even reached the page where I choose the disks for the new node.
So, apparently nodes DO have to be done one at a time. Or at least, the next New Failover Cluster install can't start until that ownership handle grabs the chosen storage or all the available storage will flip to the other node and the install will fail.
Huh. The things one learns when one is paying attention to other tools.
Generally, I'll create the appropriate cluster roles and then move the required disks into each role before installation. This saves FCM doing all this for you, the roles are populated with IP, name, services, etc during the install of each FCI
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 14, 2015 at 7:10 am
Perry Whittle (10/14/2015)
Brandie Tarvin (10/14/2015)
Interesting note. As I was attempting to install the 3 nodes at the same time (different servers), I was watching the Failover Cluster Management tool. It auto-flipped the available storage over to the latest SQL install as it started. So one of my node installs failed because it hadn't yet gotten an "ownership handle" on its storage when I started the next node's install.This happened before I even reached the page where I choose the disks for the new node.
So, apparently nodes DO have to be done one at a time. Or at least, the next New Failover Cluster install can't start until that ownership handle grabs the chosen storage or all the available storage will flip to the other node and the install will fail.
Huh. The things one learns when one is paying attention to other tools.
Generally, I'll create the appropriate cluster roles and then move the required disks into each role before installation. This saves FCM doing all this for you, the roles are populated with IP, name, services, etc during the install of each FCI
We tried that. SQL didn't like that. It kept saying the roles were already in use by the Windows cluster. So we had to remove them and let the cluster install create the roles.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply