1

Topic: Failure working off in AlwaysOn

Good afternoon!
The task: to test operation AlwaysOn at a failure.
It is given: Tuned synchronous AlwaysOn in  Failover a cluster, one basis, is synchronized, the second  is adjusted on reading (ApplicationIntent=ReadOnly)
The check scenario: the cluster (the first  thus works and there transactions are theoretically possible) falls, we lift AlwaysOn on the second  with possible loss of the data, we work there, we lift reversely a cluster, we are returned on the first  with loss of the data on the first .
At scenario implementation we rest against a problem at a reset stage on the first  with loss on them the data.
The situation is visible on the enclosed picture.
The first  . As it to synchronize reversely - it is not clear. To deduce basis from AlwaysOn and reversely to add synchronizing from zero -  (on  it occupies some days).
Found such to dock , there write:

If loss of the data is comprehensible to your business purposes, it is possible to restart bases of the data-addressees.
At renewal of basis of the data-addressees, the first step of its synchronization is rollback.
If sending queue contained any log records at the moment of failure of the server,
Appropriate transactions will be lost, even if they have been fixed.

However it did not happen.
How it is possible to synchronize repeatedly the first  the data with the second without breaking AlwaysOn and without deducing from it basis?
In technology beginners, do not kick strongly. If  , I will be grateful.

2

Re: Failure working off in AlwaysOn

After made failover with  the data - only from zero.

3

Re: Failure working off in AlwaysOn

Sergey Alekseevich wrote:

After made failover with  the data - only from zero.

It is sad...
The general setting of the task: out of operation there is the first  together with the witness of a cluster. It is necessary to leave on the second , to work there, and at recovery of the first  and the witness to return reversely with that data that appeared on the second  for down time.
Can we is initially wrong a problem solved? It can is possible to do without raising AlwaysOn on the second  with possible loss of the data?

4

Re: Failure working off in AlwaysOn

Oblom wrote:

the General setting of the task: out of operation there is the first  together with the witness of a cluster. It is necessary to leave on the second , to work there, and at recovery of the first  and the witness to return reversely with that data that appeared on the second  for down time.

If you want to make that wrote simply enough to lift basis in AlwaysOn on standard procedure through full  bases.
If you suddenly want "" two remarks after them uncoupled, are not present, the server of it is not able and it is necessary to do manually.
Well and if do not want such problems, include already synchronous commit. Does not help in this case, but it is better to include, problems will be less.

5

Re: Failure working off in AlwaysOn

Sergey Alekseevich wrote:

it is passed...
If you want to make that wrote simply enough to lift basis in AlwaysOn on standard procedure through full  bases.
If you suddenly want "" two remarks after them uncoupled, are not present, the server of it is not able and it is necessary to do manually.
Well and if do not want such problems, include already synchronous commit. Does not help in this case, but it is better to include, problems will be less.

Clearly, thanks!
And synchronous  is already included, without it automatic moving is impossible

6

Re: Failure working off in AlwaysOn

Oblom wrote:

at recovery of the first  and the witness to return reversely

Here a key error. "Died so died." After failure about  it is possible to forget and if something there and it was repaired, return to a cluster it can only as absolutely new .