Your recovery site does not need to share one stretched Windows cluster with the primary site. SQL Server distributed availability groups link two existing groups while each keeps its own local cluster.
Why Distributed Availability Groups Start as Two Groups
Start with two ordinary availability groups. Each has its own local replicas and Windows Server Failover Cluster. The distributed group is the SQL Server link between those groups. It is not a new cluster spanning both sites.
That separation lets each site manage its own local infrastructure. Local replica health still matters. Removing the stretched-cluster requirement does not remove network dependencies, endpoint authentication, or the need for a tested recovery plan. The intersite link carries database changes and needs adequate capacity.
I draw the local groups separately before reviewing the recovery design. It helps people stop treating every replica as one interchangeable target. The physical drawing can be simple. Four boxes and two boundaries explain more than a server list that requires a second cup of coffee.
The Forwarder Has Two Different Roles
Only the global primary supplies the writable database copy in this arrangement. It sends changes to its local secondary replicas and to the other group's primary replica. That receiving replica is the forwarder. It then sends the received changes to its own local secondary replicas.
The forwarder is primary within its local group, but secondary in the distributed relationship. Those roles are compatible because they describe different layers. Do not interpret its local primary role as permission for independent application writes to the distributed databases.
A local failover changes which replica leads one underlying group. A distributed failover changes which group owns the global writable role. Keep those procedures separate. The two layers also require separate monitoring, since a healthy local pair does not prove the remote link is current.
Where Distributed Availability Groups Fit
A separate recovery site is a natural fit when you want local clusters in each location. A hardware migration is another use: build the destination group, establish data movement, then plan a controlled switch. The link keeps the database copy moving while preparation continues.
Do you need a recovery copy, a planned migration, or automatic site switching? Distributed failover is manual. Do not promise automatic intersite failover merely because local replicas use an automatic failover policy. Application reconnection and ownership procedures still need deliberate planning.
Cross-version migrations require a supported version sequence. Newer receiving servers and database upgrade behavior can limit the return path. Verify the exact versions, editions, and failback support before creating the link. A migration plan that ends at the first successful switch is missing an important chapter.
The Demo Needs Existing Groups
This demonstration needs two existing availability groups, their listeners, working endpoints, and an edition supporting this layout. It does not create Windows clusters, replicas, or application databases from scratch. Prepare the supported seeding configuration and permissions on both sides first. On a standalone instance, the catalog queries below still run and simply return no rows.
Use a lab with group names SiteAG1 and SiteAG2 for the shown commands, or substitute approved names. The listener hostnames resolve to the corresponding local primary. In LISTENER_URL, the port is the database-mirroring endpoint port. It is not the application's listener connection port.
Confirm DNS resolution, endpoint reachability, endpoint authentication, and available storage. For automatic seeding, configure the documented database-creation permissions and local-group requirements. A blocked endpoint cannot be repaired by repeatedly reissuing CREATE. Check the actual prerequisite that failed.
SELECT name AS GroupName, group_id, is_distributed
FROM sys.availability_groups
ORDER BY name;
SELECT ag.name AS GroupName, ar.replica_server_name,
ar.endpoint_url, ar.availability_mode_desc,
ar.failover_mode_desc, ar.seeding_mode_desc
FROM sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar ON ar.group_id = ag.group_id
ORDER BY ag.name, ar.replica_server_name;
Create the Link on the Global Primary
Run the next command on SiteAG1's primary replica after completing those prerequisites. It shows the CREATE AVAILABILITY GROUP shape for the distributed link. The names are illustrative lab identifiers, and the endpoint port is the lab's chosen 5022. Substitute the actual approved endpoint port.
Both sides use asynchronous commit across the link in this example. That keeps remote acknowledgment out of the primary's commit path, but allows a lagging recovery copy. It does not promise zero data loss. Choose the mode from measured network behavior and the recovery requirement.
CREATE AVAILABILITY GROUP [SiteBridge]
WITH (DISTRIBUTED)
AVAILABILITY GROUP ON
N'SiteAG1' WITH
(
LISTENER_URL = N'tcp://SiteAG1Listener:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
),
N'SiteAG2' WITH
(
LISTENER_URL = N'tcp://SiteAG2Listener:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
);Join From the Forwarder
Run the corresponding JOIN on SiteAG2's primary replica. The distributed name and underlying definitions must match. This attaches the receiving group to the relationship created at SiteAG1. It is not an instruction to join arbitrary preexisting writable databases with conflicting contents.
Automatic seeding transfers data and consumes network, log, and storage resources. Monitor the seeding process as well as later synchronization. Plan initial database preparation using the documented distributed-group procedure. The short commands express the link, not every installation and seeding prerequisite.
ALTER AVAILABILITY GROUP [SiteBridge]
JOIN
AVAILABILITY GROUP ON
N'SiteAG1' WITH
(
LISTENER_URL = N'tcp://SiteAG1Listener:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
),
N'SiteAG2' WITH
(
LISTENER_URL = N'tcp://SiteAG2Listener:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
);Read Health of Distributed Availability Groups From Both Sites
Inspect catalog configuration and replica state on the global primary and the forwarder. These DMVs expose information visible to the local instance. A missing remote row is not proof that the remote side is healthy. Combine observations from both sites when diagnosing the relationship.
The first query reports the distributed layer's roles and connectivity. The second reports locally visible database state across the underlying and distributed groups. Run with approved server monitoring permissions. Queue sizes and redo rates are values to measure, not numbers to assume from the architecture drawing.
SELECT ag.name AS GroupName, ar.replica_server_name,
s.is_local, s.role_desc, s.connected_state_desc,
s.synchronization_health_desc
FROM sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar ON ar.group_id = ag.group_id
LEFT JOIN sys.dm_hadr_availability_replica_states AS s
ON s.replica_id = ar.replica_id AND s.group_id = ag.group_id
WHERE ag.is_distributed = 1
ORDER BY ag.name, ar.replica_server_name;
SELECT ag.name AS GroupName, DB_NAME(d.database_id) AS DatabaseName,
d.synchronization_state_desc, d.synchronization_health_desc,
d.is_suspended, d.suspend_reason_desc,
d.log_send_queue_size, d.redo_queue_size, d.redo_rate,
d.last_hardened_lsn
FROM sys.dm_hadr_database_replica_states AS d
JOIN sys.availability_groups AS ag ON ag.group_id = d.group_id
WHERE d.is_local = 1
ORDER BY ag.name, DatabaseName;Plan the Switch Beyond Database Movement
A growing send queue signals changes waiting to reach another replica. A growing redo queue signals received log waiting to be applied there. Examine sustained trends together with link throughput and workload volume. One snapshot cannot establish the achievable recovery objective.
I include application connections, logins, jobs, and external dependencies in every site-switch review. Ordinary database availability groups do not automatically copy all instance-level objects. Test the chosen endpoint, the application's reconnection behavior, and the ownership of scheduled work after a switch.
For distributed availability groups, document who authorizes the switch and how synchronization is confirmed first. A forced recovery of a lagging copy accepts data-loss risk and needs a separate decision. For planned migration, verify the supported procedure, stop writes as required, and confirm the destination before reopening work.
Keep backups and restoration tests alongside distributed availability groups. Replicated mistakes still reach the other site. The link supplies another live copy, while recoverable history supplies a different protection. Test both, and keep the two local clusters' responsibilities clear.
Related reading on this blog: Monitoring Availability Group Health and Testing a Failover Before You Need One.
A distributed group is not one stretched cluster, it is a database link between two local groups.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
