Monday, September 10, 2012

Failover\Fallback SQL Mirror in Lync Server 2013

NOTE: The following post is based on Lync Server 2013 Preview. Procedures and screenshots are subject to change when Lync Server 2013 is RTM.

In my previous post, I described how to add a SQL mirror to your back-end database for SQL high availability.  In this post, I will describe how to failover and then fallback the SQL databases between the mirror.

Before failing over the SQL mirror, you need to determine whether or not your back-end database is hosting the Central Management Store (CMS) database.  You can determine this by running the following command:

Get-CsService –CentralManagement

Lync 2013 - SQL M failover - get-csservice

If the output shows the pool that you are failing over the back-end for then you must failover the CMS database.  In my lab I have all databases as part of the mirror configuration: User, CMS, Archiving, Monitoring, Apps, PersistentChat, PersistentChatCompliance:

Primary SQL Node:

Lync 2013 - SQL M failover - pricipal

Mirror SQL Node:

Lync 2013 - SQL M failover - mirror

You can also check the state of your mirror status by running the following:

Get-CsDatabaseMirrorState –PoolFQDN pool01.w15lab.local –DatabaseType User

Lync 2013 - SQL M failover - get-mirrorstate user

The supported –DatabaseType values are: App, Archiving, CentralMgmt, Monitoring, Provision, User, PersistentChat, PersistentChatCompliance

I need to run the following commands to failover all databases:

Invoke-CsDatabaseFailover –PoolFQDN pool01.w15lab.local –DatabaseType User –NewPrincipal mirror

Lync 2013 - SQL M failover - invoke-failover user

Now I run the similar command for the rest of my database types:

Invoke-CsDatabaseFailover –PoolFQDN pool01.w15lab.local –DatabaseType App –NewPrincipal mirror

Invoke-CsDatabaseFailover –PoolFQDN pool01.w15lab.local –DatabaseType CentralMgmt –NewPrincipal mirror

Invoke-CsDatabaseFailover –PoolFQDN pool01.w15lab.local –DatabaseType Archiving –NewPrincipal mirror

Invoke-CsDatabaseFailover –PoolFQDN pool01.w15lab.local –DatabaseType Monitoring –NewPrincipal mirror

Invoke-CsDatabaseFailover –PoolFQDN labad03lyse01.w15lab.local –DatabaseType PersistentChat –NewPrincipal mirror (note that my persistent chat pool is my Standard Edition server)

Invoke-CsDatabaseFailover –PoolFQDN labad03lyse01.w15lab.local –DatabaseType PersistentChatCompliance –NewPrincipal mirror (note that my persistent chat pool is my Standard Edition server)

After all commands have been executed, I can look at my SQL nodes again and see that my mirror node now has the active database:

Primary SQL Node:

Lync 2013 - SQL M failover - primary - post failover

Mirror SQL Node:

Lync 2013 - SQL M failover - mirror - post failover

When you are ready to fallback to the primary SQL node, just run the same commands but change the –NewPrincipal parameter to “primary”

Invoke-CsDatabaseFailover –PoolFQDN pool01.w15lab.local –DatabaseType User –NewPrincipal primary

Lync 2013 - SQL M fallback- invoke-failover user

This post describes how to manually fail your mirror databases over to the secondary SQL node and then fall back.