Distributed Availability Groups Praveen Kumar

What we will cover Availability group refresher The HA/DR solution Distributed availability groups – what is it Configuring a SQLDAG solution Failover a SQLDAG Monitoring and health

Availability Groups Refresher

Availability Group Requirements Requires a Windows Server Failover Clustering (WSFC) cluster. An instance of SQL Server must reside on a WSFC node Each availability replica of a given availability group must reside on a different node of the same WSFC cluster. Relies on WSFC to monitor and manage the current roles of the availability replicas Overall health is based on all nodes in the cluster Quorum configuration – node and disk majority sys.dm_hadr_cluster sys.dm_hadr_cluster_members

Example Configuration (GEO Cluster)

Configuring Quorum

Availability Group Basics Contains one or more databases Database must be in Full Recovery Model One Unit of Failover SQL Server Agent Jobs, Logins, Linked Servers do not fail over Create Availability Groups then add database

Creating the HA/DR Solution Make sure Failover Clustering is installed on nodes by going to Administrator Tools, Failover Cluster Manager Perform a Cluster Validation Configure Quorum Node Votes (powershell script) Primary Data Center Nodes have vote set to 1 Secondary Data Center Nodes have vote set to 0 Install stand-alone or failover cluster instance Enable AlwaysOn Availability Group for each SQL Server Service

Creating the HA/DR Solution Add login and grant connect to SQL Create endpoint Create database or restore to primary instance Create full/log backup Create availability group Restore full/log backup to each secondary Join availability group

Primary Replica with 4 Secondaries

Distributed Availability Group (SQLDAG) One of the new features in SQL2016 is the ability to distribute availability groups across clusters. This solution makes high availability and disaster recovery geographically dispersed. Distributed Availability groups allows you to associate availability groups on two different Windows Server Failover Clusters.

Distributed Availability Group Two or more clusters Mix of standalone and FCIs Secondary cluster only knows that it is a secondary and does not know which is primary (DMV is coming for visibility with this) No GUI No Alerts

Creating the HA/DR Solution using SQLDAG (…continued) Add login and grant connect to SQL Create endpoint Create database or restore to primary instance Create full/log backup Restore full/log backup to each secondary including secondary cluster(s) Create availability group Join availability group on primary cluster (may contain just one replica) Create availability group on secondary (primary instance) cluster Join availability group on primary cluster (may contain just one replica)

Now for the FUN PART! Go to the Primary Cluster Primary Instance and create SQLDAG CREATE AVAILABILITY GROUP [distributedag] WITH (DISTRIBUTED) AVAILABILITY GROUP ON 'AG_1' WITH ( LISTENER_URL = 'tcp:// :5022', --Use listener name when there is a standalone AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ), 'AG_2' WITH ( LISTENER_URL = 'tcp:// :5022', --Use SQLVNN not listener name when there is an FCI --check port to make sure it is 5022/5023/5024 etc AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ); GO

Now for the FUN PART…again! Go to the Secondary Cluster Primary Instance and join SQLDAG CREATE AVAILABILITY GROUP [distributedag] JOIN AVAILABILITY GROUP ON 'AG_1' WITH ( LISTENER_URL = 'tcp:// :5022', --Use listener name when there is a standalone AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ), 'AG_2' WITH ( LISTENER_URL = 'tcp:// :5022', --Use SQLVNN not listener name when there is an FCI --check port to make sure it is 5022/5023/5024 etc AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ); GO

Now Let’s Get Synchronized ALTER DATABASE D000DB1 SET HADR AVAILABILITY GROUP = xxxx Then WAIT…. Check the health of the distributed availability group to see if all replicas are synchronizing select r.replica_server_name, r.endpoint_url, rs.connected_state_desc, rs.last_connect_error_description, rs.last_connect_error_number, rs.last_connect_error_timestamp from sys.dm_hadr_availability_replica_states rs join sys.availability_replicas r on rs.replica_id=r.replica_id where rs.is_local=1 There is no GUI for SQLDAG so you will need to rely on DMVs

Gathering Information About Availablity Groups dm_hadr_automatic_seeding dm_hadr_physical_seeding_stats dm_hadr_automatic_seeding dm_hadr_availability_replica_cluster_nodes dm_hadr_availability_group_states dm_hadr_availability_replica_states

Manual Failover of SQLDAG 1.ALTER AVAILABILITY GROUP of SQLDAG (secondary cluster) to SYNCHRONOUS_COMMIT 2.Verify from dm_hadr_database_replica_states that status is SYNCHRONIZED and end_of_log_lsn matches from primarys in both clusters 3.On instance that hosts primary SQLDAG, set SQLDAG role to Secondary ALTER AVAILABILITY GROUP xxx SET (ROLE = SECONDARY) At this point the SQLDAG is unavailable 4.Verify again readiness to failover 5.Issue failover – ALTER AVAILABILITY GROUP xxx FORCE_FAILOVER_ALLOW_DATA_LOSS After this step the SQLDAG is available again 6.Set SQLDAG back to ASYNCHRONOUS_COMMIT

Configuration Example 2 sets of clustered VMs Availability group in each VM cluster Automatic Failover Synchronous Distributed availability group between each cluster set

Monitor SQLDAG Replication Health State SELECT * FROM (SELECT… FROM sys.availability_replicas r LEFT JOINsys.availability_groups ds ON r.group_id = ds.group_id WHERE ds.name = ' ' ) a inner join ( SELECT … FROM sys.availability_groups ag JOIN sys.dm_hadr_availability_group_states as ags ON ag.group_id=ags.group_id LEFT JOIN sys.dm_hadr_database_replica_states ds ON ds.group_id = ag.group_id ) b ON b.availability_group = a.replica_server_name

Health State

Alert on Unhealth SQLDAG State 1.Record health state with query in a set interval using a job (5 minutes is a suggestion). 2.Use a job to check latest health state in comparison to prior health state 3.Repeated unhealthy SQLDAG replication to trigger alerting mechanism (such as ).

Worth Mentioning 1.SQL2017 Read-scale availability groups  Not for HA or DR, just for synchronization, no WSFC 2.The official abbreviation for distributed availability groups is not DAG. DAG is used for Exchange Database Availability Groups.

Questions

Thank You