SQL Server AlwaysOn Availability Group introduction

For starters, AlwaysOn Availability Group is a brand new feature of SQL Server 2012. In a nutshell, it serves to maximize the availability of the group of user databases. It is proved to be a good high availability, as well as disaster recovery solution used as an alte
ative to database mirroring. As mentioned above, this exciting new feature reduces the downtime (both planned and unplanned) of the system and serves to increase it's availability. Along with availability, it provides protection for your data. It's somewhat a hybrid solution for both high availability and disaster recovery.

What is Availability Group all about?

Availability group is a set of users databases, also known as availability databases, designed to support a failover environment. It supports a set of read-write primary databases and one to four sets of secondary databases which are only available for read-only access. Moreover, each availability database is hosted by an availability replica.
Two types of availability replicas exist:
• One primary replica – Primary replica hosts primary databases. It serves to send transaction log records of each primary database to every secondary database. Moreover, it makes primary databases available for read-write connections from users.
• One to four secondary replicas – Each secondary replica hosts secondary databases and also serves as a potential availability group for a failover. Every secondary replica caches the transaction log and applies them to its corresponding secondary database.
Bare in mind, as the synchronization occurs between the primary database and each connected secondary database independently - secondary database can fail without having an impact on other secondary databases, same thing with primary databases.

Types of failovers

The process of a secondary replica becoming a primary replica is called a failover. During this process, secondary replica transitions to the primary role thus becoming the new primary replica. This new primary replica brings its databases online as the primary ones and users can connect to them. When the former primary replica becomes available, it changes its role to secondary one and the data synchronization resumes.
There are three forms of failover – manual, automatic and forced (with forced failover being the one with possible data loss). However, synchronous-commit mode supports two forms of failover – planned manual failover and automatic failover. The support for these forms of failover depends on the setting of the failover mode property on the failover partners.
• Planned manual failover (without data loss) – If failover mode is set to manual on either replicas (primary or secondary), only manual failover is supported for the secondary replica. Manual failover preserves all the data in the secondary databases that are joined to the availability group on the target secondary replica. What is important here is that both primary and secondary replicas must run under synchronous-commit mode and that the secondary replica must already be synchronized. Once the former primary replica switches to the secondary role, its databases become secondary databases and begin synchronizing with the new primary databases. Once they all switch to the synchronized state, the new secondary replica becomes available to be used as the target of a future planned manual failover.
• Automatic failover (without data loss) – When a failover mode is set to automatic on both replicas (primary and secondary), both automatic and manual failover are supported on that secondary replica. In a nutshell, automatic failover occurs when primary replica collapses (becomes unavailable) and the secondary replica automatically switches to the primary role. In other words, it occurs in response to a failure that causes a synchronized secondary replica to transition to the primary role. After the former primary replica becomes available again, it gains the functions of a secondary replica. Just like manual failover, secondary replica must already be synchronized and automatic failover requires that both primary and secondary replica run in a synchronous-commit mode as well, but with the failover mode set to automatic being the only difference.

To conclude, this new integrated, flexible and most importantly cost-efficient feature can provide data and hardware redundancy within and across data centers, and improve application failover time to increase the availability of your applications. Also, unlike database mirroring and clustering this solution offers you the availability for live querying and moreover, you can place replicas in different geographical areas. AlwaysOn provides flexibility in configuration and enables reuse of existing hardware investments.