Availability Group Changes

Allan Hirt digs into SQL Server 2016 Availability Group changes:

What is a distributed availability group? Distributed availability groups allows you to create two different AGs on different Windows Server failover clusters (WSFCs) but join them together – if you will, an AG of AGs. This is great for disaster recovery scenarios where you do not want to worry (more than you should) about things like voters and quorum in a  single WSFC which could make the configuration more complex. This also allows for different versions of Windows Server (one WSFC is Windows Server 2012 R2 and another Windows Server 2016). Heck, it could even facilitate migrations to new hardware/the public cloud/virtualization assuming the same major version of SQL Server. It’s a cool feature. You can only manually fail over the AG between the WSFCs, but that’s OK, and you do need a listener for each AG. If you do not plan on using a listener, you cannot create a distributed AG.

Side note:  when I read DAG, I think directed acyclical graph.  Maybe I’m just weird that way…

Main note:  the idea of “seeding” an Availability Group sounds wonderful.

Related Posts

Considerations Before Failing Over an AG

David Fowler points out a few things to look at before failing over an Availability Group: What about your SQL Agent jobs? Have you got jobs that perform actions on your data? If you have, do those jobs exist on the new primary? If they don’t then I’m happy to bet that whatever function that […]

Read More

Connecting with Read Intent

John McCormack shows two ways to connect to an Availablity Group listener with read-only intent: SQLCMDThe -Kreadonly switch is your key to success here but remember to also specify the database using -d. When not set (and with an initial catalog of master for my login), I found I always got the primary instance back during my check. […]

Read More

Categories

March 2016
MTWTFSS
« Feb Apr »
 123456
78910111213
14151617181920
21222324252627
28293031