Share via

Always On–New Feature: “Availability Group” in Denali

  • Article

In Denali, there is a new feature called – Availability Group.  

With this feature you can setup –

  • Multiple Database mirroring as part of Availability Group – This is perfect for an application that uses multiple databases
  • Multiple Secondaries
  • Example:
  • one for HA with Synchronous with Automatic Failover -- in Same datacenter
  • 2nd one for HA with Synchronous with Manual Failover with Reporting capability (without doing Snapshor DB – this is a great feature where you can direct your Reporting Workload to while giving the best to your OLTP) -- in same datacenter
  • 3rd one for DR with Asynchronous with Manual Failover – in a different data center
  • ..
  • Up to 5 secondaries can be involved as part of Availability group
  • Active Secondary – as I mentioned earlier you can have Live Reporting going off of one of the Secondary
  • Fast Client Connection Redirect using DNS aliasing

Cool thing about this is – wizard does it all, as supposed to pre and post tasks with current Database Mirroring setup where we have to take a backup of database, copy the backup over to secondary, and then restore it with NORECOVERY option. In Denali, it does it all as part of Availability Group setup wizard. 

To illustrate above scenario, I created below diagram – should explain. As you can see, Availability Group is built upon WSFC (Windows Server Failover Cluster) technology, that means, each of this servers have to be part of WSFC configuration – no need for SQL Server Failover Cluster instance, though – that’s a totally separate HA architecture. 

image

Comments

  • Anonymous
    April 07, 2011
    Since the nodes use seperate disks and seperate data files what happens when a transaction is commited on the Active node but hasn't yet been transferred to the secondary node when the failure occurs? Or when a trigger hasn't yet commited off of a write. Seems like this is nothing more than a prettied up version of Replication wrapped in a gui and a new name.

  • Anonymous
    December 12, 2011
    I'm right there with Vince, I fail to see how this is a step up besides the ease of setup.  If you have to build a wsfc anyways, why not just install on the cluster and not have to worry about committed transactions on separate storage.  Plus, when dealing with HA it ALREADY gobbles up tons of resources, why add more disk space to that equation without a good benefit.  I don't consider reporting from a secondary database for performance reasons to really be a part of HA, it's a separate issue that replication already works fine for without needing wsfc...