Avoid Availability Group Database Data Loss: Do not Deploy File Share Witness From DFS Namespace

First published on MSDN on Aug 29, 2017

Cluster Quorum File Share Witness Should Not be Part of a DFS Namespace

When deploying AlwaysOn availability groups you may decide to add a vote to Windows Cluster quorum by configuring a File Share Witness. A requirement when configuring that File Share Witness is that it is not part of a Distributed File System (DFS) namespace. Adding a file share witness which is part of a DFS can result in split brain and ultimately data loss. It is documented in the section ‘Requirements and recommendations for clusters using Node and File Share Majority’ of Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster

• Do not use a file share that is part of a Distributed File System (DFS) Namespace.

Avoid Data Loss In Your Availability Group Databases

If a File Share Witness for your Windows Cluster is incorrectly configured as part of a DFS, in the event of a communication between Windows Cluster nodes hosting availability group replicas, quorum may be arbitrated independently, resulting in split brain condition in the Windows Cluster.

The result is two or more availability group replicas will have independent views of the availability group state and may attain the primary role simultaneously, or automatic failover can occur to an availability replica that is not in a truly synchronized state. These are states and behaviors that can lead to the loss of data in your availability group databases.

Microsoft SQL Server support has worked with several customers who have experienced data loss due to split brain or the automatic failover of availability groups that were not synchronized as a result of this configuration.