Building Always On Availability Groups—Part 3 of 3

Spread the love

At this point all of the instances in your cluster should be enabled for AlwaysOn. The first step is to take a full backup to a database. Ideally (but not a necessity) backup to a location that is accessible by all of the nodes in the cluster.

From the Node that you would like to initially be the Primary, expand AlwaysOn High Availability and select the “New Availability Group Wizard”

 Select a name for your Availability Group–note this will be the name internal to SQL Server, not the external name that clients connect to (we will address that later)

Select the databases you would like to add to the Availability Group. Note: In order to be eligible for an Availability Group a database must be in Full Recovery Mode and have a full backup completed and available.

Add the instances you would like in your Availability Group as Replicas. The option to add Automatic Failover and Synchronous commit are on this screen. Note: Automatic Failover should only be used within the same data center. Otherwise latency on the secondary will affect the primary. This is also where we set the ability to read the secondary replicas with the option Read-Intent only (Only allows Read Intent Connections from SQL 11 clients) or Yes (allows read-only connections from any client)

Verify the endpoints tab–these are the endpoints for the communication used by AlwaysOn. There isn’t a need to change them

For the backup preference tab, here I select primary. However if you choose to backup the secondary server, it  will need to have backup drives presented and created. There are other considerations to this–are you backing up to a common location, how you will manage distributed endpoints.


The Listener, this is the DNS name that your application will use to connect to the availability group. Note: This step requires a Virtual Computer Object (VCO) to be created in Active Directory. Put in a request for your listener name to the Windows SE to create the object. Additionally, a DNS request for this name will be required. Use the IP address and Name that you requested for DNS. And then go ahead and create the listener.

The next screen is the data synchronization screen. This is the wizard can restore you backup of the databases in your Availability Group or just skip the initial synchronization and restore afterwards. If the backups are in a shared location accessible by all nodes, I recommend doing the synchronization now.

To check on the status of your new Availability Group–right click on it in SSMS and launch the dashboard.

1 thought on “Building Always On Availability Groups—Part 3 of 3

  1. Pingback: AlwaysOn Availability Groups and SharePoint 2013 « The SQL Herald

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.