We’ve been in the process of building a team site in SharePoint 2013, and since I’m building I decided to investigate using AlwaysOn Availability Groups. This is slightly different than building a normal availability group—the application doesn’t use a listener.
First of all—you want to read the official Microsoft guidance here. It can be a little confusing, so here are the basics of what you need to.
- Create temp database—you need to create the Availability Group before the SharePoint install is kicked off, so you want to have a database to include in your AG.
- Build your AG and add your temp database to it. I’m not going to go into a great deal of detail on this, but if you need help check parts 1, 2, and 3 of my series on building an AlwaysOn Availability Group.
- After this is complete—go to Failover Cluster Manager and add a Client Access Point resource to the role for your Availability Group.
When you create the client access point, you will need to assign an IP address to it. Additionally, you will need to get an entry in DNS so that your SharePoint server can talk to the access point. You will see in “Other Resources” in your cluster role in Failover Cluster Manager. Unlike a Listener, this does not require an Active Directory Virtual Computer Object (VCO) to be created.
When you install SharePoint, and have the option to specify your database setting—use the client access point.
After the SharePoint installation is complete, add your SharePoint databases to your availability group, and then synchronize with your secondary. Failovers happen seamlessly once this is complete.
I do have one final note of concern—SharePoint creates a lot of databases, without notifying anyone (different applications in SharePoint create new DBs for themselves). I’m still working on a good strategy to automatically add new SharePoint databases to my Availability Group. I wouldn’t do this in any other application, and feel guilty about doing it here. My thoughts are leaning towards a system trigger that fires on new DB create, and then launches a stored procedure that will take a full backup and add the DB to the AG. That feels really ugly to me—does anyone have better ideas for a cleaner solution?
DId you ever find a good solution for this?
Not clear to your question–it pretty much just works as above. AS for the adding of new databases–no, there really isn’t a great automated way to do it. I need more time to script something.
So if a new site w/ new DB is created in SP, the DB will be created on one of the instances but will not be synced until you manually sync.
Yeah, additionally you need to add the database to the availability group on the primary.
Wonderful points uncovered!!!
However, I still have concern: How to deal with AlwaysOn Availability Groups with remote DR location.
If SQL will fail to remote location, what SharePoint server will do? Will it fail too or will struggle with slow network connection to the remote site?
What if SharePoint server will fail to remote location and SQL databases will be still in main data center?
In other words: How to make SQL and SharePoint servers always fail together?
Also, HA question: Is it OK to do automatic failover to the DR site or better to make the automation only in the same data center and “manual” failover for the remote site?
Thanks.