1

So we're having an issue whereby any loss of communication between our 2 HA nodes causes the primary node to temporarily go into a 'resolving' state. This is for all of 1-3 seconds however we serve a DB to an application which doesn't retry connection and requires users to close and reopen meaning they lose work in progress.

This cluster is comprised of 2 nodes, one active and one non-readable secondary with a fileshare witness. All of our other applications don't mind this temporary blip however as mentioned this has a huge visible impact on other users. Is this a given when running HA in synchronous commit?

My concern is also when patching the secondary, I will be kicking users off when the secondary goes down. Would switching to async remove this constraint or is this an issue with how it has been configured?

Improve this question
3
  • 1
    You know that there is some network issue, so why are you not focusing on resolving the the network issue. Your issue is not because of sync mode its more to do with network configuration and blip. Please add the contents of errorlog which you see when state goes into resolving mode.
    – Shanky
    Commented Jul 9, 2018 at 11:13
  • @Shanky A historic network event highlighted this, there isn't an on-going network issue, apologies for my lack of explanation. I'm of the mind that if I were to patch my secondary node, this would cause the same temporary resolving state and wanted to know if this is deemed as normal? Plus my question stands, even if we did have an on-going network issue, is it normal for my primary to go into a resolving state when it loses sight of the secondary replica?
    – R. Elms
    Commented Jul 9, 2018 at 11:25
  • Its not normal for primary to go into resolving mode this would defeat the whole purpose of AG. Please share the logs that would help us in getting better idea. If you want to patch secondary, take application downtime, pause the data movement and apply the patch, this will still keep primary up and running.
    – Shanky
    Commented Jul 9, 2018 at 12:27

1 Answer 1

Reset to default
1

It's difficult to answer the first part of your question as it seems to be related to the network and/or cluster configuration and not related to the availability mode. You should take a good luck at your cluster logs to see what is the root cause.

1. Checking cluster status a. Login to failover cluster manager console b. Click on the cluster name c. Check the summary details for errors d. Click on networks under the cluster name e. Check the summary and network connections tab at bottom of the window for errors f. Since this appears to be a 2 node cluster w/file share witness supporting AlwaysON, make sure each node and the FS has a vote in the cluster.

2. Checking for file share witness errors a. Confirm the share is online and available to the network

3. Obtaining cluster logs a. Login to a cluster node as an Administrator b. Examine both the System and Application event logs. c. Use powershell commandlet: get-clusterlog -uselocaltime ***this will save a cluster.txt file to C:\Windows\Cluster\Reports examine the log

As to your second question regarding patching, I assume that the nodes and the FS each have a vote. If the secondary node is getting patched (windows patching or SQL SP/CU), the AG on the primary node will be available provided quorum is maintained between the primary node and the file share witness. If quorum is not maintained, the AG will shutdown in order to protect the databases. The Availability mode is not a factor.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.