• Basic high availability

  • 2 replicas (1 primary, 1 secondary).

    DB01 => initial primary.

    DB02 => initial secondary

  • Synchronous commit on both

  • Both are in synchronized state

  • There is no listener configured

  • Cluster type None

When we stop the DB01 (initial & current primary) SQL service using services.msc (simulating a friendly server crash) and then initiate a forced failover on DB02 (initial & current secondary) using:


The secondary database comes online, which is what we want.

However, when the DB01 SQL Server service is started again, using services.msc, the DB01 db assumes primary role again.

So currently there are 2 instances readable/writable and out of sync. We were expecting that the initial primary would detect that a secondary has taken the primary role and assume a secondary role or at least be inaccessible so apps cannot work on old data.

The same procedure, but using the deprecated mirror setup, does behave this way.

  • No quorum was forced
    – MichaelD
    Commented Aug 10, 2021 at 15:11
  • Cluster type was set to None
    – MichaelD
    Commented Aug 10, 2021 at 15:29

1 Answer 1


Since this is a clusterless (read-scale) availability group, there is nothing automatically coordinating which role each node is in - that process is completely manual.

This is why the former primary comes back up as the primary - nothing has told it to change its role.

You'll want to follow the instructions outlined here:

Fail over the primary replica on a read-scale availability group - Forced manual failover with data loss

...if the original primary replica recovers after failover, it will assume the primary role. To avoid having each replica be in a different state, remove the original primary from the availability group after a forced failover with data loss. Once the original primary comes back online, remove the availability group from it entirely.

In the end, you can add that former primary back as a secondary manually:

  1. (Optional) If desired, you can now add N1 back as a new secondary replica to the availability group AGRScale.
  • It does work in the deprecated mirroring config. So in this situation, deprecated mirror is better ?
    – MichaelD
    Commented Aug 10, 2021 at 15:46
  • @MichaelD As you said, mirroring is deprecated, so it's probably not a good idea to use it 😀 As far as "better" it depends on what your goals are. If you want automatic failover and role management, you need to set the AG up using a Windows Server Failover Clustering (WSFC) cluster type. Commented Aug 10, 2021 at 15:49
  • Manual failover is ok, but a primary that comes back online and accepts traffic on it's out of sync DB is not ok. But as I understand this is behavior by design with this set of features.
    – MichaelD
    Commented Aug 11, 2021 at 5:58

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.