principlesqlMinor
Availability mode - manual failover mode, best practice for availability mode?
Viewed 0 times
practicemodemanualfailoveravailabilityforbest
Problem
We don't want automatic failover for our availability group, but I have set availability mode to Synchronous, was that a mistake?
The availability group runs on vmware with windows 2012R2, and I got the error messages below after the cluster "crashed". (There was some manual migration off the vmware at the same time)
Can I related the crash to availability mode settings?
Thank You in advance.
Regards Odd
Kl 13:58:56 – Critical : Cluster node ‘' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Kl 13:58:56 – Critical : Cluster node '' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Kl 13:59:58: -Critical: File share witness resource 'File Share Witness' failed to arbitrate for the file share '\\Quorum'. Please ensure that file share '\\Quorum' exists and is accessible by the cluster.
Kl 13:59:58: - Error: Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed.
Based on the failure policies for the resource and role, the cluster service may try to bring the resource
The availability group runs on vmware with windows 2012R2, and I got the error messages below after the cluster "crashed". (There was some manual migration off the vmware at the same time)
Can I related the crash to availability mode settings?
Thank You in advance.
Regards Odd
Kl 13:58:56 – Critical : Cluster node ‘' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Kl 13:58:56 – Critical : Cluster node '' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Kl 13:59:58: -Critical: File share witness resource 'File Share Witness' failed to arbitrate for the file share '\\Quorum'. Please ensure that file share '\\Quorum' exists and is accessible by the cluster.
Kl 13:59:58: - Error: Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed.
Based on the failure policies for the resource and role, the cluster service may try to bring the resource
Solution
Can I related the crash to availability mode settings?
No. By the looks of your log messages, you actually lost cluster quorum due to the removal of two nodes' votes, and then your witness (file share). Is this a 3 node cluster with a file share witness perchance? In that case, if you pulled these events from one of the node's event logs, then it may appear to each of the nodes that there is a lack of communication with all voters. That would generate a similar, if not same, error footprint like you have above. Nobody can talk to anybody, if that is the case.
During that time, the quorum will be lost as you are currently seeing. There is a level of assuming here, as I'd need to see way more diagnostic information to pinpoint the cause of voter removal, but that is why the quorum was lost.
Regardless, this appears to be a problem that surfaced in a down cluster, in which case your availability mode would have nothing to do with the WSFC cluster failing.
As for "best practices" for the availability mode to go with, you need to determine requirements for data loss, performance impact, and a few other factors that are best described in this BOL reference on Availability Modes.
No. By the looks of your log messages, you actually lost cluster quorum due to the removal of two nodes' votes, and then your witness (file share). Is this a 3 node cluster with a file share witness perchance? In that case, if you pulled these events from one of the node's event logs, then it may appear to each of the nodes that there is a lack of communication with all voters. That would generate a similar, if not same, error footprint like you have above. Nobody can talk to anybody, if that is the case.
During that time, the quorum will be lost as you are currently seeing. There is a level of assuming here, as I'd need to see way more diagnostic information to pinpoint the cause of voter removal, but that is why the quorum was lost.
Regardless, this appears to be a problem that surfaced in a down cluster, in which case your availability mode would have nothing to do with the WSFC cluster failing.
As for "best practices" for the availability mode to go with, you need to determine requirements for data loss, performance impact, and a few other factors that are best described in this BOL reference on Availability Modes.
Context
StackExchange Database Administrators Q#65702, answer score: 3
Revisions (0)
No revisions yet.