Search This Blog & Web

Friday, August 30, 2013

SQL SERVER 2012 HIGH AVAILABILITY SOLUTION (Always On availability Group Configuration)

In my last post I have covered how to install Windows Cluster environment and Windows Server 2012. To review have a look at this link

  1. SQL Server 2012 high availability solution (Windows Server Cluster Configuration)
  2. SQL Server 2012 High availability solution ( SQL Server 2012 Installation)

SQL SERVER Always On availability Group Configuration

Once SQL Server installed on both nodes (SQL01, SQL02). For testing purpose I have created AlwaysOn_TestPSO database on primary node SQL01. Database must be created with full recovery mode

A SQL Server Availability Group enables you to specify a set of databases that you want to fail over together as a single entity. When an availability group fails over to a target instance or target server, all the databases in the group fail over also. Because SQL Server 2012 can host multiple availability groups on a single server, you can configure AlwaysOn to fail over to SQL Server instances on different servers. This reduces the need to have idle high performance standby servers to handle the full load of the primary server, which is one of the many benefits of using availability groups.
An availability group consists of the following components:
·         Replicas, which are a discrete set of user databases called availability databases that fail over together as a single unit. Every availability group supports one primary replica and up to four secondary replicas.
·         A specific instance of SQL Server to host each replica and to maintain a local copy of each database that belongs to the availability group.
Replicas and failover
The primary replica makes the availability databases available for read-write connections from clients and sends transaction log records for each primary database to every secondary replica. Each secondary replica applies transaction log records to its secondary databases. All replicas can run under asynchronous-commit mode, or up to three of them can run under synchronous-commit mode.

Before starting Always on availability group you need to enable this feature from SQL Server service. 

Now try to create availability group

Error still shows there is some problem. We need to restart sql server service.

Make sure you will perform this step on both nodes.

For testing purpose I have created a table and then take a full backup of this database. Place this backup on share folder \\DomainServer\ClusterShareFolder path

Start setup using Availability Group Wizard

Specify name of availability Group.

Primary instance is already there you need to add other replicas and all your replicas are from different nodes as in our case SQL02 is secondary node and act as replica. Check options and look at the last column Readable Secondary that is selected as [No]. If you select it as [Yes] then your secondary replicas and then 3rd and 4th replicas are in readable form as well. This approach can be used for reporting purposes

If port 5022 is enabled or firewall is blocked then this step will automatically fill are data

These options are for Backup references, by default [Prefer Secondary] is selected I will leave as is.

You need create listener either user DHCP or TCP. You can get this from your network person

You need to set DNS name, default port and IP address that is not using in domain for any other VM or server. Network person will help you in this. You need to remember
  1. DNS name must not be any system or VM name in domain
  2. Port must be enabled through firewall
  3. IP Address must not in use

All validation steps are complete

Backup location is displayed in this screen. I have missed out its screen shot during installation wizard

Once setup is completed you can view primary database as Synchronized. Notice availability group objects
  1. SQL_Group: is our availability group for this database. You can add more groups that use different databases to handle
  2. Replicas: can be added more up to 4 replicas
  3. Database: more than one database can be grouped here under SQL_Group and all follows combined point of failure i.e if one database fails all other will also moves to its next replica
  4. Listener: This listener verifies database sync state and moves data between its objects

No comments: