When Always On Isn’t: Handling Outages in Your Application

Today’s brief Stack Overflow outage reminded me of something I’ve always wanted to blog about:

Stack Overflow is in limp-home mode

There’s agray bar across the top that says, “This site is currently in read-only mode; we’ll return with full functionality soon.”

That’s not a hidden feature of Always On Availability Groups. Rather, it’s a hidden feature of really dedicated developers whose application:

Tries to connect to the SQL Server, and if that fails, shows a total-site-down page Checks to see if the database is writeable via DMVs like sys.dm_hadr_availability_group_states and sys.dm_hadr_availability_replica_states If it’s not writeable, shows a polite banner across the top of the site, and still gracefully runs readable queries only

This is no small feat. For example, if you’re calling stored procedures to render a page, those stored procedures cannot do any writes. You can’t log page views inside a stored proc, or log execution times. You have to assume that the database may not be writeable. (That’s great practices anyway, since you can then use replicas to scale out all page rendering.)

For bonus points, your application can still do logging and writes but just not to SQL Server. You might cache writes temporarily to a NoSQL store.

This is all left as an exercise for the reader. Always On Availability Groups give you a limp-home capability for your web site, but it’s up to you to make your web site as functional as possible when the database is degraded.