In the previous Post(part-2) we have seen prerequisites for Installing SQL Server Instances participating in an AG. In this post, let’s see how to configure an actual AG…Am alllllllll excited 🙂
Before proceeding any further, Few points to be noted:
1.I’ve created a share on Node “SreeSQLA” which all the 3 Instances need visibility to.(Hence added SQL Service account(s) with Read/Write access).
2.All the Databases participating in AG should be in Full Recovery Model and a Full backup should be taken(Same as DB Mirroring Requirements we had). Well, the whole concept of AG’s was built on top of DB Mirroring. Same EndPoints concept is used here, In fact it uses the same TCP Ports for endpoints which Mirroring uses by default.
3.We have to enable “AlwaysOn Avaiability” option on all the Instances in SQL Server configuration Manager(Service Restart is required).
Here is the Snapshot of my Cluster manager before I enable AlwaysOn on SQL Instances…(Just keep this in mind that there are no Roles for now)
Now, Where can I enable AlwaysOn Availability?
Open your SQL Server Config Manager and go to Services and select SQL Server Properties and you can see a new tab as shown below.
As you can see it automatically detected my Windows Cluster name! All you’ve to do is Enable, Apply, Okay and Restart SQL Services.(Also make sure you enabled TCP/IP under your network Protocols)
We are all set to begin our Database(s) part now. For my lab am creating 3 User Databases as “Sales1,2 and 3”. (As I mentioned earlier make sure to use Full Recovery Model and Take a Full backup for the first time and I will place it in my share which I created, Note- You can manually sync databases Initially as you did for DB Mirroring)
In my Lab, SreeSQLA is my primary(prod) Instance and SreeSQLB is sitting in the same datacenter(for HA), where I’ll be using Synchronous Mode and assuming SreeSQLB is my DR Site and I’ll be using Asynchronous Mode. (So, I have 3 Replicas in total…Primary replica at my Production Site and 2 Secondary Replicas at SreeSQLB and SreeSQLDR).
Step1: I created 3 Databases on my Production Server(SreeSQLA) and placed full backups on my share.
Step2: Navigate to AlwaysOn High Availability Node in your Object Explorer and select “New Availability Group Wizard” as shown below.
Step3: Name your AG.
Step4: Select your Databases you want in your AG. (You can see below where it says all the Prerequisites are met 🙂 )
Step5: This is Interesting, where you’ve to select all your replicas, Backup preferences, Create End Points and Create/Assign an IP for your Listener.
Adding Replicas – I Clicked on Add Replica Button and connected to SreeSQLB and SreeSQLDR and chosen Primary and Secondary roles as per my requirement as shown below.
EndPoints: I left it to defaults. ( Make sure your Firewall is not blocking this port)
Backup Preferences: I selected to allow Backups only on My Secondary replicas and I avoided SreeSQLB as shown below. ( You can select as you wish depending on your requirement)
Listener: This is the one which clients connect to and which floats across machines. As you can see I specified a Name, Port and IP for this Listener. Note – Each AG can have only one Listener. Recommended not to use DHCP for IP in your Prod Environments. We’ll be using different subnet for our DR site in real world, for that all you have to do is, add another Static IP from your DR Server Subnet. – Starting SQL Server 2012 we’ve OR Dependency for your IP’s! ( Well, you may need to work with your Network Team for this for all your Static IPs mumbo jumbo)
Now..It’s time to select how you want to initiate Data Synchronization. I’ll provide my Share and let wizard to take care of it as needed, since my database are tiny!
Click Next and it validates our configuration and I got all Green Check Marks as you can see below..Hurray 🙂
All you are left with now is clicking Next and Finish and keep your fingers crossed as I did for this setup(This is my very First AG I ever setup…Very exciting stuff! )
After few seconds I got success message and now Object Explorer on my Production Instance Looks like this.
Huhuuuuuuuuuu….I Did it! See, it’s not that difficult. Now it’s time to understand all the nuts and bolts of this awesome technology.
Before concluding, let me tell you this…From now on, your clients/Applications should connect to Listener Name(not the SQL Instance Name). See below for what it looked like when I connected using Listener Name.
Also, take a look now how my Failover Cluster manager looks like.
It created a Role for the Listener which we created via SSMS and NodeA is the current owner(Principal) of it. Perfect…Everything looks as expected 🙂
Have fun exploring AG guys..Make your self very familiar with this technology, you never know when your boss might say “Okay, Now it’s time to move on to SQL Server 2012”