July 17, 2019 at 8:00 am
Hi,
I'm having a problem with a Windows Server 2008 R2 Failover Cluster with a SQL Server 2008 Instance losing connection to the shared storage disks. It's an all flash netapp san which has been working fine.
To solve I was thinking about removing the SQL Instance from the failover cluster and just running the SQL Instance on one Node.
If I remove the SQL Instance from the failover cluster and want to keep the SQL Instance available, do I add a static dns entry for the Instance name to be the ip of the remaining node?
Thanks,
S.
July 17, 2019 at 9:33 am
S, there are several things which are not clear:
It's not necessary to remove SQL from the cluster to have it running on a specific node. Just select proper possible owner for the resource.
July 17, 2019 at 9:41 am
Hi,
Thanks for replying.
The disks are clustered, having problems with the 2nd Node seeing the disks though, validation on storage fails. I'm looking into resolving the issues on the 2nd Node.
Was just looking to see if taking the cluster out of the equation I can still run the SQL Instance on the one Node.
Thanks,
S.
July 17, 2019 at 10:09 am
Hi, Thanks for replying. The disks are clustered, having problems with the 2nd Node seeing the disks though, validation on storage fails. I'm looking into resolving the issues on the 2nd Node. Was just looking to see if taking the cluster out of the equation I can still run the SQL Instance on the one Node. Thanks, S.
It's easier to revoke a node than whole SQL.
Also, instead of touching your SQL, you can add test disk to the cluster which also resides on the external storage and try to fail it over between the nodes fixing the issue with the second node. Just amend possible owners and let SQL run clustered on the first node.
July 17, 2019 at 10:32 am
Hi,
Thanks for the response.
I'll give this a try.
S.
July 24, 2019 at 1:31 pm
If you are convinced that one of your cluster nodes is not fit for use, you should look at the safest way to decommission it, and also how you will retain resiliency.
If you try to remove SQL and leave the node in the cluster that might work, but if it causes problems you have a new set of issues to deal with.
The best approach to decommission is to shut the problem node down and evict it from the cluster. This gives a clean break and you can move on from there.
Looking at maintaining resilience, the best way is to build a new guest server and join it to the cluster. You can (and should) test disk failover after joining the server to the cluster and before you do the SQL install. This should increase confidence that things should work properly after SQL is running.
We have moved from W2012R2 to W2016 by adding new nodes to our cluster and evicting the old nodes. We also moved SQL from SQL2014 to SQL2017 using AGs, all on the same cluster. There are a lot of things you can do with adding new nodes and evicting old nodes, and if planned well experience shows it is a safe thing to do.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
July 24, 2019 at 1:35 pm
Hi,
Thanks for the reply.
I've since discovered my issue with a faulty port on the fibre channel switch.
Looks like my failover cluster will be okay.
Thanks,
S.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply