locked
Active-Active SQL Server 2012 Cluster, Active-Passive SQL Server 2012 Cluster, Asynchronous-Commit Availability Mode Availability Group, Synchronous-Commit Availability Mode Availability Group RRS feed

  • Question

  • I am trying to understand when to use
         Active-Active SQL Server 2012 Cluster
         Active-Passive SQL Server 2012 Cluster
         Asynchronous-Commit Availability Mode Availability Group
         Synchronous-Commit Availability Mode Availability Group

    Can someone point me to a web page that gives examples of when to use these?


    lcerni

    Tuesday, September 17, 2013 7:36 PM

Answers

  • Active-Active SQL Server 2012 Cluster (as it was commonly called before but now referred to as multi-instance clusters) is used if you want to run multiple clustered SQL Server instances in a Windows Server Failover Cluster. This is to maximize your hardware investments and provide availability and fault tolerance. Active-Passive SQL Server 2012 Cluster (as it was commonly called before but now referred to as single-instance clusters) is used if you simply want to provide fault tolerance and availability to a clustered SQL Server instance and have the other nodes act as standby. From a hardware cost (or bean counters') perspective, this is not efficient since the other nodes are doing nothing and just waiting for failures to happen. Both of these options provide protection on the instance-/server-level

    Synchronous Commit Availability Group is used if you want to minimize data loss and provide availability to your database. The transaction log records are copied and persisted to the replicas before an application receives a response from the database that the transaction has been committed. This configuration supports automatic failover with zero to minimal data loss. Asynchronous Commit Availability Group is used if you just want disaster recovery for your databases. Transaction log records are still being copied to replicas but the primary replica does not have to wait for confirmation that those records are persisted on disk on the secondary replicas before responding to the client application that the transaction has been committed. This configuration does not guarantee no data loss and does not support automatic failover.

    Hope this helps.


    Edwin Sarmiento SQL Server MVP Edwin Sarmiento SQL Server MVP
    Blog | Twitter | LinkedIn
    SQL Server High Availability and Disaster Recover Deep Dive Course

    • Proposed as answer by Fanny Liu Wednesday, September 18, 2013 6:37 AM
    • Marked as answer by lcerni Wednesday, September 18, 2013 5:27 PM
    Tuesday, September 17, 2013 7:48 PM