Wednesday 20 March 2013

AlwaysOn Availability Groups SQL 2012

Overview:  SQL 2012 offers AlwaysON Availability Groups (AOAG)

Notes:
  • All SP2013 dbs support Synchronous Replication via AOAG.
  • Most SP2010 excludes Search, Profiles and Syn (I think).  SP2010 needs SP 1 to use SQL2012 features including AOAG.
  • Synchronous replication requires 1GB+ bandwidth and less than a 10ms latency
  • For AOAG you need Windows 2008 R2 Enterprise edition.  SQL 2012 Enterprise edition
  • Databases need to be in the Full Recovery Model to use AOAG
Download the PS to add databases to existing AG's.

AOAG only support databases that are set to use the "FULL" recovery model.  Multiple SharePoint database are set to use the "Simple" recovery model.  I haven't found anything saying MS will support switching all the databases to the "Full" recovery model.  Performance wise "Simple" runs faster but the benefit of having AOAG is generally worth the change to the recovery model.

Note: SP2010 has several databases that use a simple recovery model (Search, Profile, sync, usageandhealth dbs). 

Note: SP2010 has several databases that use a simple recovery model (4 Search dbs: Search, search_analytics, search_Crawl, search_linkstore.  5) Profile 6) Sync 7) Social 8) UsageandHealth).

Note: The listener and the cluster are created within AD and are added as Computers, this will only use the 1st 16 characters for adding the listen and the cluster, it cuts off the rest.  Make sure the listen and cluster are less than 17 chars.

Note: FS4SP I added the Administrators database for resilience.
FASTSearchAdministors (Full Recovery model) - AOAG works
FAST_ContentService (Simple)
FAST_ContentService_CrawlStore (Simple)
FAST_ContentService_PropertyStore (Simple)
FAST_QueryService (Simple)
FAST_QueryService_CrawlStore (Simple)
FAST_QueryService_PropertyStore (Simple)

Tip: I was performing backups that we corrupting my databases.  Before doing the backup and
Restore to perform the AOAG sync, delete the old backups.

References:
http://www.slideshare.net/michaeltnoel/sql-2012-alwayson-availability-groups-for-sharepoint-2013-sharepoint-connections-amsterdam-2012
http://technet.microsoft.com/en-gb/library/jj715261.aspx
http://blogs.msdn.com/b/sambetts/archive/2013/04/24/sharepoint-2013-and-sql-server-alwayson-high-availability-sharepoint.aspx

"No need for Aliases..".  Aliase have 2 purposes:
1) the database goes down, you get pointed to the alternative database.  AOAG listener does the exact same function so I agree that there is no point in using an alaise for failover.
2) SQL Alaises allow you to split up which database you are working with.  So by having let's say a single AOAG with 2 aliases that point to the same AOAG listener is perfect as later you can move the Search databaases to another AOAG instance and you don't need to re-run the config wizard. 

Minor point but I'd still use aliases on top of AOAG listeners.

The script below runs thru the databases on the 1 server in the AOAG and if they are set to use the "Simple" Recovery Model, it changes the SQL Recovery Model to "FULL".  In my case I have used AutoSPInstaller to build my SP2013 farm.  This has prefixed all my databases with AutoSP_, this allows me to make sure I am only targeting SP database for my change to the recovery model (See line 11).
 

0 comments:

Post a Comment