During the keynote for TechEd North America 2013, Microsoft announced the planned release of SQL Server 2014. As part of this announcement, AlwaysOn Availability Groups will now support up to 8 readable secondaries, and include a number of improvements that will improve stability. While it hasn’t been announced yet, it is probably safe to assume that many of these changes will primarily benefit the Enterprise Edition of SQL Server 2014.
Over drinks on Monday night, a few of us were left wondering, will SQL Server 2014 include a supported, non-deprecated, high-availability solution in Standard Edition?
Who Deserves High Availability?
Before I talk about high availability solutions, I first want to talk about high availability in general. Specifically, should high availability solutions only be available for the 1%? Of course, reading that brings back memories of the Occupy movement. But, that’s the idea I’m going for. Do only those environments with lots of money and the capital to afford Enterprise edition deserve solid, robust high availability features from SQL Server?
The answer is no. Every database and instance of SQL Server needs the ability to easily deploy high availability features. These solutions don’t need to be as robust between the editions of SQL Server, but there do need to be options. And these options need to provide high availability.
SQL Server 2012 Standard Edition High Availability
Before I advocate for a specific high availability request for SQL Server 2014 in standard edition, let’s first take a look at what’s available in SQL Server 2012. There are a number of options that are often brought up when discussing high availability solutions, but not all of them are created equal and some I wouldn’t consider high availability solutions.
One of the first items that gets brought up is database mirroring. True, SQL Server 2012 allows database mirroring. The problem with database mirroring, is that it is deprecated. If the deprecation follows the normal path, SQL Server 2014 is the last version of SQL Server that will have database mirroring as a feature. Because of this, I would not consider database mirroring as a valid option for new SQL Server deployments, because the solution, while functional, has no future.
Next, there is failover clustering for SQL Server; which allows up to 2 nodes in standard edition. Truth be told, this is a high availability solution that works, and provides most everything that one could hope for from high availability. So contrary to what many may say about high availabilty in SQL Server standard edition, there is a solution that is non-deprecated, and likely to remain supported into the future.
Another solution often mention with high availability is by using transnational or merge replication. No, this isn’t a high availability solution. No matter how clever you are, you can’t change replications reliance on a primary that doesn’t switch between instances. Any high availability solution that is based on replication, is likely to be a different sort of cluster.
The last solution that people will often try to include with high availability solutions is log shipping. Log shipping is not high availability. It is a disaster recovery solution, but that is not high availability. Log shipping relies on manual failovers; which doesn’t not pass the muster.
As a result, in SQL Server 2012, there are two actual high availability solutions native to standard edition. Of those, only failover clustering is future proof and can be expected to be around well into future SQL Server releases.
Should Microsoft Do More?
Yes, Microsoft needs to do more. With the deprecation of database mirroring, there is a huge future feature gap in SQL Server. Right now, the story for database mirroring customers is to continue using database mirroring, until it isn’t there anymore.
When SQL Server 2014 is released, will this be the continued answer moving forward? If so, as a customer, looking to the future, knowing that database mirroring will not be available changes the conversation on what a future architecture could look like. The chances that other database platforms will become an option increase when you don’t know what the future on your environment will allow. We need to know the story for database mirroring customers going into the future.
One option would be to tell all database mirroring customers that going forward, they should consider failover clustering as the standard edition high availability solution. While this would satisfy the high availability need in Standard edition, it brings on issues of cost. Failover clustering requires additional hardware investments that the customer may not be able to afford. Those additional costs might be directly related to why they chose to purchase standard edition.
Also, failover clustering is an instance level high availability solution, your applications might need the ability to only move specific database between instances. For instance, if two databases become active to the point where a failover is needed to split the workload and ensure that the databases remain available. In this scenario, failover clustering would not provide the availability required.
The solution to this, is to make a subset of AlwaysOn Availability Groups available within standard edition. Availability Groups is the next generation for database mirroring, and many customers today are surprised that there isn’t a subset of the feature available in standard edition. When we talk about a subset, I would propose that in standard edition, there is support for one local synchronous secondary. No backup support for the secondary or any other of things that make Availability Groups cool, except maybe read access. Just another location where the database can reside in the event of a failure. This seems like a simple request and, for the most part, is a just providing a replacement for database mirroring.
Now one of the things you may have noticed was in the argument against failover clustering, the primary argument against was the additional hardware cost. This brings about a conundrum, because database mirroring and an availability group secondary would also incur a hardware cost, but it shouldn’t need to. Microsoft can do a little bit more with SQL Server 2014 Standard edition to help with this. As an addition to the one secondary, Microsoft should also allow an asynchronous Azure-hosted secondary that supports read-only access. This additional instance aligns with Microsoft’s desire to move to the cloud and would provide a little bit more than database mirroring to standard edition customers.
Conclusion
Microsoft needs a SQL Server 2014 Standard edition path for database mirroring customers. The most logical and useful of these would be to migrate those customers to a subset of Availability Groups that maps to database mirroring features. Along with that, Microsoft should expand on those features and provide an Azure enabled feature set to help drive their internal cloud plans and to provide customers with new and interesting ways to deploy their applications. It is critical that this is done with SQL Server 2014 to provide customers with a full version cycle to adopt the changes and work with barriers to the deployment while being able to rely on features that they currently use and will lose in the future.
