Can I Have a Single Node SQL Server Cluster

I occasionally hear the question of whether you can create a one node SQL Server cluster. That basically means you have a virtualized instance of SQL Server with a virtual IP and virtual name that are differerent from the host box, but that there is only one “possible owner” of that SQL Server. Yes, this is allowed and supported. Often it is used for testing or when you have to get the system up and running now but only have one physical server available at the moment. You can add additional nodes to the Windows cluster later, then optionally add those nodes as potential owners of the SQL Server instance. See the “add node” topics in BOL, the exact steps will vary by version. Basically “add node” means that setup adds the SQL binaries and some registry keys to the new node and updates a few cluster related registry keys so that the cluster “service” becomes aware of the additional node as a “possible owner” of that instance of SQL Server. You still only have one copy of the SQL Server databases no matter how many nodes are possible owners.

Choose “Other Versions” if you want to view the BOL topic for something other than the most recent version of SQL Server:
How to: Add or Remove Nodes in a SQL Server Failover Cluster (Setup)

5 thoughts on “Can I Have a Single Node SQL Server Cluster

  1. Yes! This is also important for people to know since it means that if you need to break your cluster, you can still run with just the one node without having to disable or remove all the clustering stuff.

  2. Great! I am just in the second case because at the moment we only have one node available. But later we will have more nodes in different sites.


  3. What about the Windows Cluster portion of all of this? I would like to see an all-encompassing document that covers complete replacement of a SQL Server 2008 R2 SP2 node in a Windows Server 2008 R2 2-node cluster. I have 2 nodes, one crossover cable… so… where/when do I do any removal of the Windows Cluster node; switch the crossover cable to the new node, and so forth?

  4. Sounds like we do NOT run the setup of SQL unless/until we have the new server physically connected; does that sound correct? If so, does SQL itself handle all of the 'Windows Clustering' portions as well? Do I have to have my 2nd NIC (heartbeat/failover NIC) pre-set with it's IP address and so forth; i.e., if I am replacing a node, I could pre-configure the 2nd (heartbeat) NIC with the same private IP (i.e. as my previous node that is being removed, right?

    AND, more importantly, if I don't run setup until physically connected, what about the fact that the setup I will be running is for SQL version "prior to" SP2 (though my cluster currently is on SP2, cu1); so, how do I handle that "matching the versions" trick (because you have to do SQL, then SQL SP2, then cu/hotfix, etc.; to make SQL match the version currently on my existing cluster). So, you can see how this whole topic is much more than just "run setup and click remove sql node."

Leave a Reply to What is "BOL?"Cancel reply

%d bloggers like this: