Distributed Availability Groups and Multi-Site Disaster-Recovery Concepts

Learning outcomes

A normal Availability Group is one AG with its own cluster integration. A distributed Availability Group (distributed AG) connects two separate AGs. The primary of the first AG becomes the global primary; the primary of the second AG acts as the forwarder. This creates an AG-of-AGs data path suitable for site separation, migration and disaster-recovery designs without requiring one WSFC to span both sites.

1. Two local HA domains, one inter-AG data stream

SELECT SERVERPROPERTY('ProductVersion') AS product_version,       SERVERPROPERTY('ProductUpdateLevel') AS update_level,       SERVERPROPERTY('Edition') AS edition,       SERVERPROPERTY('EngineEdition') AS engine_edition,       SERVERPROPERTY('IsHadrEnabled') AS hadr_enabled,       SERVERPROPERTY('InstanceDefaultBackupPath') AS default_backup_path,       SERVERPROPERTY('ServerName') AS server_name;GOSELECT name, compatibility_level, recovery_model_desc,       is_published, is_subscribed, is_merge_published, is_distributorFROM sys.databasesWHERE name IN (N'ServiceHubLab', N'master', N'msdb') OR is_published=1 OR is_subscribed=1 OR is_merge_published=1 OR is_distributor=1;GO

Each underlying AG keeps its own cluster/resource model. This is a major reason to use a distributed AG across independent sites: the WAN does not have to be one WSFC failure domain. However, there is still an end-to-end data dependency. A slow or disconnected WAN can grow queues even while both local AGs remain healthy.

USE ServiceHubLab;GOIF SCHEMA_ID(N'lab17') IS NULL EXEC(N'CREATE SCHEMA lab17 AUTHORIZATION dbo;');GODROP TABLE IF EXISTS lab17.DeliveryQueue;DROP TABLE IF EXISTS lab17.SiteState;DROP TABLE IF EXISTS lab17.MovementRequirement;GOCREATE TABLE lab17.DeliveryQueue(  queue_id bigint IDENTITY PRIMARY KEY,  technology varchar(20) NOT NULL,  source_commit_id bigint NOT NULL,  created_at datetime2(3) NOT NULL DEFAULT SYSUTCDATETIME(),  delivered_at datetime2(3) NULL,  status varchar(16) NOT NULL DEFAULT 'PENDING');CREATE TABLE lab17.SiteState(  site_name varchar(30) NOT NULL PRIMARY KEY,  role_name varchar(30) NOT NULL,  last_commit_id bigint NOT NULL,  writable bit NOT NULL,  last_refresh_at datetime2(3) NOT NULL DEFAULT SYSUTCDATETIME());CREATE TABLE lab17.MovementRequirement(  requirement_name varchar(80) NOT NULL PRIMARY KEY,  whole_database bit NOT NULL,  subset_filtering bit NOT NULL,  multiple_writers bit NOT NULL,  automatic_failover bit NOT NULL,  target_rpo_seconds int NULL,  notes nvarchar(300) NULL);GO

INSERT lab17.SiteState(site_name,role_name,last_commit_id,writable)VALUES ('East','GLOBAL_PRIMARY',91000,1),('West','FORWARDER',90970,0);SELECT *, last_commit_id - MIN(last_commit_id) OVER() AS commits_ahead_of_slowestFROM lab17.SiteState;GO

The 30-commit difference is not how SQL Server reports distributed-AG lag; it is a teaching proxy. In a real topology, use sys.dm_hadr_database_replica_states, sys.availability_groups, sys.availability_replicas and relevant log-send/redo queue rates/LSNs on both global primary and forwarder.

2. Edition and SQL Server 2025 requirements

The SQL Server 2025 on-premises edition matrix lists distributed Availability Groups for Enterprise, not Standard or Express. Use free Enterprise Developer for a non-production lab. Real reproduction still requires two underlying AGs and therefore multiple SQL Server instances plus their platform/cluster prerequisites. Microsoft documents some Azure-connected distributed-AG scenarios that can have different edition combinations; do not generalize those cloud-specific exceptions to ordinary boxed SQL Server.

SQL Server 2025 improves distributed-AG synchronization, especially reducing network saturation when the forwarder is asynchronous; the behavior is enabled by default. Microsoft also recommends matching the availability modes of the two underlying AGs rather than intentionally mixing synchronous and asynchronous modes. SQL Server 2025 additionally supports distributed contained AGs when the contained-system-database requirements are met.

SELECT ag.name, ag.is_distributed, ar.replica_server_name,       ar.availability_mode_desc, ar.failover_mode_descFROM sys.availability_groups AS agLEFT JOIN sys.availability_replicas AS ar ON ar.group_id=ag.group_idORDER BY ag.name, ar.replica_server_name;GOSELECT DB_NAME(database_id) AS database_name, is_primary_replica,       synchronization_state_desc, synchronization_health_desc,       log_send_queue_size, redo_queue_size, last_hardened_lsn, last_redone_lsnFROM sys.dm_hadr_database_replica_statesWHERE is_local=1;GO

3. Failover is a role-reversal procedure, not a button

Distributed-AG failover changes which underlying AG is authoritative. Cross-site lag must be understood first. A forced transition can require FORCE_FAILOVER_ALLOW_DATA_LOSS; that name is intentionally explicit. Even with synchronous settings, verify hardened state and the documented sequence rather than promising no data loss from a single configuration word.

INSERT lab17.MovementRequirement(requirement_name,whole_database,subset_filtering,multiple_writers,automatic_failover,target_rpo_seconds,notes)VALUES ('Regional DR',1,0,0,0,30,N'Two local AGs; WAN failover is operator-governed');SELECT * FROM lab17.MovementRequirement WHERE requirement_name='Regional DR';GO

1. Confirm which site is authoritative and fence/isolate the old global primary when required.2. Record underlying AG roles, synchronization mode and database queue/LSN evidence on both sites.3. Estimate possible data loss from the last hardened/received state.4. Follow the documented distributed-AG role-transition sequence for your version.5. Redirect clients through the correct local listener/application routing plan.6. Validate writable primary, business commit marker, backups, jobs and security objects.7. Rejoin/resynchronize the former site before returning to normal topology.

4. Production judgment

Production judgment. Distributed AGs fit whole-database multi-site HA/DR or migration where two local AGs must remain independent. They do not provide row filtering, multi-writer conflict resolution, ETL transformation or automatic global application routing. Chapter 17 Lesson 5 compares those contracts directly.

Authoritative references

• Distributed availability groups — architecture, SQL Server 2025 changes and requirements
• Configure a distributed availability group — creation/failover sequencing
• SQL Server 2025 editions and supported features — Enterprise distributed-AG boundary
• Contained availability groups overview — SQL Server 2025 distributed-contained AG support