SQL Server Quorum Loss After Two Node Failures

When You See This Error

Your SQL Server failover cluster instance (FCI) stops working after two nodes go offline at the same time. It happens during a power outage that kills two servers in a three-node cluster. Or during patching when you reboot nodes A and B but C was already down for maintenance. You get this in the cluster log: 'Cluster service is shutting down because quorum was lost.' The database stops accepting connections. Users panic.

Root Cause — What's Actually Happening

Windows Server Failover Cluster (WSFC) uses a voting system to stay healthy. Each node gets one vote. The cluster stays alive when more than half the votes are present. In a three-node cluster, you need at least two nodes up. Lose two nodes, you lose majority. The cluster shuts down to prevent data corruption — split-brain scenario where two parts of the cluster try to own the same resources.

The fix is either bringing one of those nodes back online (fastest) or forcing quorum on the remaining node. You can't skip this step. If you try to restart the cluster service without quorum, it won't start.

Fix — Step by Step

Option 1: Restore a Failed Node

1. Check which nodes are alive: Open Failover Cluster Manager on any running node. Look at 'Nodes'. Dead ones show as 'Down'.
2. Power on the dead node: If it's just a power failure, turn it back on. Wait for Windows to fully boot — this can take 5-10 minutes on some hardware.
3. Verify cluster service starts: On the revived node, open Services.msc. Check 'Cluster Service' is running. If not, start it manually.
4. Check quorum: In Failover Cluster Manager, look at the cluster status. It should show 'Quorum: Healthy' with at least 2 votes present.

Option 2: Force Quorum on the Last Node

Use this when you can't bring back a dead node quickly — maybe it's a hardware failure and the replacement takes hours.

1. Open PowerShell as Admin on the surviving node.
2. Force quorum: Run this command:
   

   Stop-Service ClusSvc
   Start-Service ClusSvc -ForceQuorum

3. Wait 30 seconds. Then check cluster status with:
   

   Get-ClusterNode | Select-Object Name, State

4. Bring database online: If the SQL Server resource is offline, right-click it in Failover Cluster Manager and select 'Bring Online'.
5. Important — fix the dead node: Once you've restored quorum, you must repair or replace the dead node. Then add it back to the cluster with normal steps.

What to Check If It Still Fails

Sometimes forced quorum doesn't work. Here's what to check:

• Dynamic quorum: In WSFC 2019 and later, dynamic quorum can adjust votes automatically. If the cluster believes the last node lost its vote due to a misconfiguration, it won't accept forced quorum. Check with Get-ClusterQuorum — if it shows 'DynamicQuorum: True' but no votes, you might need to reset the quorum configuration.
• File share witness: If you use a file share witness, check that the file share is accessible from the surviving node. A network issue can block it. Run Test-Cluster -Include 'QuorumConfiguration'.
• Cluster logs: Always check them. Run Get-ClusterLog on a working node. Look for 'Event ID 1135' — that's the quorum loss event. It tells you exactly which nodes failed.
• SQL Server service account: After forced quorum, the SQL Server service might not start if the cluster service has permission issues. Check the SQL Server error log — it's usually in C:\Program Files\Microsoft SQL Server\MSSQLxx.MSSQLSERVER\MSSQL\Log\ERRORLOG.

One last thing — don't use the disk witness for quorum if you can avoid it. It's a single point of failure. File share witness or cloud witness (Windows Server 2019+) is way more reliable. I've seen too many quorum disk failures kill clusters that would've survived otherwise.