none
Distributed availability group RRS feed

  • Question

  • Hello Experts,

    I have gone through white papers but still have few queries regarding Distributed AG as below.

    1) how distributed AG is different from traditional AG (functionality wise).

    2) what is the benefit of distributed AG which can not be availed from traditional AG.

    Thanks ...


    SQL Server DBA

    Friday, July 28, 2017 7:30 AM

All replies

  • Hi Zeal DBA,

    Please correct me if I’m wrong:

    >>1) how distributed AG is different from traditional AG (functionality wise).

    You cannot compare DAG to AG directly, as they are on different level. Thinks this as a availability group of two availability groups. With DAG, you’ll have two AGs(on separate WSFC) and a DAG sits on top of them. Only the primary replica of the primary AG is allow to accept insert/update/delete operations if you are talking about differences, other than that, I see it’s just working as normal AGs.

    >>2) what is the benefit of distributed AG which cannot be availed from traditional AG.

    The most important thing I can think of, is that you can have separate WSFC in DR site, which means the availability of DC site would no longer affect DR site(compare to the old solution where you put witness in DC site or a third site). 

    If you have any other questions, please let me know.

    Regards,
    Lin

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Proposed as answer by SANTHOSH_DBA Friday, July 28, 2017 12:52 PM
    Friday, July 28, 2017 9:40 AM
    Moderator
  • In addition to what Lin Leng has already mentioned, Distributed Availability Groups can be

    • a viable alternative if you want to upgrade the underlying OS together with SQL Server. Note that you cannot do an in-place upgrade of the OS in a Failover Cluster. You have to spin up a new cluster, configure database mirroring or log shipping to copy the databases over prior to cutover. Even with traditional Availability Groups, you still need to have the OS of the failover cluster nodes to be the same
    • used as a single-master replication for multi-data center deployments. In environments where the Availability Group replicas span multiple data centers, this reduces replication traffic since it is sending it to just one secondary instead of multiple. For example, if you have a 4-replica Availability Group with 2 replicas in the primary data center and 2 in the DR data center, transaction log records are only sent to one replica across data centers instead of 2. The target secondary replica on the DR data center for the Distributed Availability Group will take care of replicating the transaction log records for the other.

    Edwin Sarmiento SQL Server MVP | Microsoft Certified Master/Solutions Master
    Blog | Twitter | LinkedIn
    Learn SQL Server High Availability and Disaster Recovery


    Friday, July 28, 2017 3:31 PM
    Moderator
  • hi Edwin,

    i understood few things from your above points but still bit confused, if you can explain little more on both the points it will be great, as i am new to configure distributed AG since i used to understand traditional AG can achieve the same as distributed AG then what is additional to set distributed AG whether internally it works different manner?

    thanks


    SQL Server DBA

    Wednesday, August 2, 2017 8:40 AM
    • In a traditional AG, every replica has to be in the same Windows Server Failover Cluster (WSFC). In a distributed AG, they don't need to be. In traditional AG, you can have automatic failover (synchronous) but not in a distributed AG.
    • In a traditional AG, the primary replica sends transaction log records on all secondary replicas. In a distributed AG, the primary replica only sends transaction log records on the primary replica of the secondary AG. It still sends transaction log records on all of the secondary replicas within it's own traditional AG. This reduces the amount of transaction log records sent between the AGs. Plus, you cannot write data to the primary replica of the secondary AG. Only the primary replica of the primary AG can write data - even if it is considered a primary replica.

    Edwin M Sarmiento Microsoft Data Platform MVP | Microsoft Certified Master/Solutions Master
    Blog | Twitter | LinkedIn
    Learn SQL Server High Availability and Disaster Recovery


    Thursday, August 3, 2017 5:25 AM
    Moderator
  • this information mentioned by you is really good, only one clarification would need to understand that is

    1) what is the high availability benefit which we can not leverage with traditional AG, if you can explain one scenario of fail over which we can not avail in traditional AG?

    2) in which scenario this design is preferable? 

      

     

    SQL Server DBA

    Thursday, August 3, 2017 10:40 AM
    1. Distributed AG is not an HA solution - it is a DR solution. You cannot automatically failover from the primary AG to the secondary AG. A traditional AG is both an HA and a DR solution.
    2. Refer to my first post

    Edwin M Sarmiento Microsoft Data Platform MVP | Microsoft Certified Master/Solutions Master
    Blog | Twitter | LinkedIn
    Learn SQL Server High Availability and Disaster Recovery


    Thursday, August 3, 2017 3:35 PM
    Moderator