Think of this as a contract between the Primary and it's replicas. In order for synchronous replication to take place a primary AND secondary must be set to synchronous. Having one set as synchronous is not enough for automatic failover OR to avoid data
loss.
In your scenario having the current primary set to synchronous is irrelevant - you get no level of protection from that.
Are you sure the synchronous commit was causing your performance problems? Did you see HADR_SYNC_COMMIT waits?
It should be synchronous to the local replica and asynchronous to the DR site.
What may happen is that the latency with an AG can get significant which apparently is what you were seeing in your dev environment.
This should not happen on a topology with ample network bandwidth - but that been said it can happen depending on your workload.
HTH
In your scenario having the current primary set to synchronous is irrelevant - you get no level of protection from that.
Ok, this is the answer I was looking for.
But: let's say that a strange AG has only the primary replica... why is given the possibility to set is asynchronous? It makes no sense. I thought the primary should always commit synchronously, since it is the only one. The attribute sync/async should be a property of the secondary replicas, which I can decide to set sync or async based on location, performance needed and other parameters. Furthermore, the sync/async property is configured on each host, not between two hosts. Am I wrong? What am I missing?
ps. thank you for your advices about the performance, but this is not a problem at the moment, our developers are only approaching AlwaysOn :)
- Edited by maurice7785 20 minutes ago
Hi Maurice
I agree that it might seem counter-intuitive that it allows you to set the primary to async and not control that purely from the secondary.
However you could think of this of an attribute of the host/replica *location* rather than of the primary/secondary role. When you have failover the sync/asyn setting stays with the host.
So imagine a DR situation where you've had to failover to an async remote site then eventually fail back to what you consider your 'primary' location. For the initial failover you only want async from that site as it's remote, however when you fail back you'll
want it to be sync for HA.
In theory you could (temporarily at least) have your 'primary' in a location where sync isn't possible due to bandwidth restrictions.
Does that make sense?