SQL alwayson sometime not syn data between primary and standby

Question

Hello Everyone

I have two SQL instances running on Window Server 2016 Standard, SQL cluster having 2 Node without shared storage.
SQL sever version is running on SQL 2016 Enterprise. But I got issue 3 times ready for data between DC and DR not syncronize (It's late 30 min or more than this). Everytime that issue happen, I need to restart sql service at standby server. After restart everything come back to normal.

Message error in log cluster at primary show like below:

Cluster failed to start. The latest copy of cluster configuration data was not available within the set of nodes attempting to start the cluster. Changes to the cluster occurred while the set of nodes were not in membership and as a result were not able to receive configuration data updates. .

Votes required to start cluster: 1
Votes available: 0
Nodes with votes: Standby Server Name

Guidance:
Attempt to start the cluster service on all nodes in the cluster so that nodes with the latest copy of the cluster configuration data can first form the cluster. The cluster will be able to start and the nodes will automatically obtain the updated cluster configuration data. If there are no nodes available with the latest copy of the cluster configuration data, run the 'Start-ClusterNode -FQ' Windows PowerShell cmdlet. Using the ForceQuorum (FQ) parameter will start the cluster service and mark this node's copy of the cluster configuration data to be authoritative. Forcing quorum on a node with an outdated copy of the cluster database may result in cluster configuration changes that occurred while the node was not participating in the cluster to be lost.

---

Anyone used to face issue like this?

Answer 1

hi, i am Vishal and i try to understand your problem and i will try to solve it in case it doesn't work then answer me,
Hardware failures are a nightmare on standalone servers. If a server starts having problems in a fail over cluster, you can easily run your SQL Server instance from another node while you resolve the issue.
Applying security patches on a standalone server can be very tedious and annoying to the business: the SQL Server is offline while you wait for the server to reboot. By using fail over clustering, you can apply patches with only brief downtime for your application as you move your SQL Server instance to a different node.
Fail over clusters can also give you an additional tool in your troubleshooting toolkit. Example: if you start seeing high latency when using storage and you’ve ruled out all the immediate candidates, you can fail to another node to try to rule out if it’s a problem with a per-node component like an HBA.
Clustering is transparent to the calling application. Lots of things with SQL Server “just work” with clustering, whereas they’re a little harder with other alternatives. With clustering, all of my databases, logins, agent jobs, and everything else that’s in my SQL Server instance fail over and come up together as a single unit— I don’t have to script or configure any of that. I can also cluster my distributed transaction coordinator and fail it over with my instance as well.

Answer 2

HI,

What the type of your cluster quorum? Disk witness or file share witness.

For this error message, please check following post if help:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/2137f953-8102-462d-b5d9-d75d2735b7de/windows-ms-cluster-2016-windowsfailoverclustering-event-id-1561?forum=ws2016

===============================================
If the response helped, do "Accept Answer" and upvote it.