SQLShorts : AlwaysOn Availability Group Configuration for SQL 2012
Today's SQLShort is on how to configure SQL 2012 Availability Groups and some gotchas.
An availability group supports a failover environment for a discrete set of user databases, known as availability databases, that fail over together. An availability group supports a set of primary databases and one to four sets of corresponding secondary databases. An availability group fails over at the level of an availability replica. Failovers are not caused by database issues such as a database becoming suspect due to a loss of a data file, deletion of a database, or corruption of a transaction log.
Each set of availability database is hosted by an availability replica. Two types of availability replicas exist: a single primary replica and one to four secondary replicas. The primary replica makes the primary databases available for read-write connections from clients and, also, sends transaction log records for each primary database to every secondary replica. Each secondary replica maintains a set of secondary databases. Every secondary replica applies transaction log records to its own set of secondary databases and serves as a potential failover targets for the availability group. Optionally, you can configure one or more secondary replicas to support read-only access to secondary databases, and you can configure any secondary replica to permit backups on secondary databases.
Deploying AlwaysOn Availability Groups requires a Windows Server Failover Clustering (WSFC) cluster. Each availability replica of a given availability group must reside on a different node of the same Windows Server Failover Clustering (WSFC) cluster.