SQL Sever High Availability - 3 nodes configuration

Question

We have already configured SQL Server High Availability group (Windows Cluster grouping) with 2 different sub nets 10.x.x.x and 192.168.x.x (data center - more than 30 miles away). At present, there are 5 databases configured for High Availability. We would like to introduce an additional server in both Windows Cluster and SQL High Availability. We plan to use the additional server only for readonly operations and this server will be residing in the 10.x.x.x sub net.

We have not configured fileshare/diskmajority in the windows cluster configuration.

The below article https://techcommunity.microsoft.com/t5/failover-clustering/understanding-quorum-in-a-failover-cluster/ba-p/371678#:~:text=Node%20%26%20Disk%20Majority,of%20nodes%20in%20the%20cluster.

recommends even number of nodes in SQL Server HA.

What are the issues/implications of configuring 3 nodes in SQL Server HA ? Would there be any disadvantages of configuring 3 nodes in the SQL Server HA ? Would you recommend this ?

Any help in this regard will be much appreciated.

At present we are replicating selected tables to another server for readonly operations. Our customer is looking for both both schema and data to be in the target server.

Answer 1

What are the issues/implications of configuring 3 nodes in SQL Server HA ?

Since there is no witness configured, this leads (everything defaulted) to having an odd number of votes, which is what you want. Clustering allows for quite a large number of nodes in a cluster, three is not a problem.

Having nodes distributed across sites and/or across distances is generically not a problem. High latency connections (not distance) are the causes of most issues.

Having three nodes, by itself, is not a concern.

Would there be any disadvantages of configuring 3 nodes in the SQL Server HA ?

Same as above.

Would you recommend this ?

There's nothing wrong. I'd recommend 3 nodes (without a witness) over 2 nodes (without a witness) in general, just for availability and disaster recovery.

This is a very common setup, as David has already specified.