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.
Strate SQL 
If we (users) as a group, want something we MUST apply the “squeaky wheel gets the grease” method by communicating our desires to Microsoft and others, often and loudly. We should all try to remember “what makes the world go ’round” and that’s market share. ALL publicly owned companies are based on this simple principle and when they receive enough emails to reach a tipping point, they take action to please their customer base.
Let me use a homegrown example: A decade ago many large companies began to use BP based plastics for their products including the well known Rubbermaid co. But many customers became aware of the health risks and complained. It did not take Rubbermaid long at all to decide on bringing out a line of BP free products to recover those customers. The principle works the same way for every company that doesn’t have a monopoly. Thanks to this principle MS responded in the past by offering their express editions of products so students could have access as they learn how to use their software. So Let’s all continue to voice our needs and desires and when enough of us have spoken they will respond.
LikeLike
Its really a nice post, the content of this blog is really awesome and extraordinary. It’s good to visit your website. And also please Read link http://www.woodstone.nu/salive which provide information server monitoring software & Network monitoring tools
LikeLike
I just think that despite cluster options, that involves other kinds of configuration, I love db mirroring because it’s easy to deploy on simple environments, and you can use Express Edition as Witness. It’s a perfect option that does not tie you up on the Windows Cluster and works very well as an HA implementation for SMB. Just my 2 cents!
LikeLike
The interesting thing is that Standard Edition FCI cannot be used as an HA strategy on the Azure cloud. FCI setup requires having a shared clustered volume set up on the Windows Cluster. Based on my research, it is not possible to use an Azure storage object (disk) as a shared clustered disk between the FCI instances in the cluster.
http://social.msdn.microsoft.com/Forums/windowsazure/en-US/f3e38072-53f7-4589-8218-0e921016df7a/is-it-possible-to-have-a-cluster-disk-from-cloud-storage?forum=windowsazuredata
That leaves only one choice on Azure – database mirroring. Now with mirroring, you need 3 SQL Server VM instances (including the witness), for automatic failover. This increases the cost steeply. Looks like MS is trying to push folks towards (1) Enterprise Edition (2) Azure SQL.
LikeLike
I completely agree.. I am looking into migrating to MySql or MariaDB in our company if they don’t offer this. We can’t afford the enterprise edition. And the Standard edition without a supported mirroring (or AlwaysOn solution) is just not good enough.
I have looked into the features of sql server 2014 and AlwaysOn will NOT be included again:
http://msdn.microsoft.com/en-us/library/cc645993(v=sql.120).aspx#High_availability
LikeLike
I’ve just come across this massive insult from Microsoft to SMEs today as I’ve been looking at ways to move our business away from our perfectly adequate Mirroring solution (because it’s deprecated and because we want to use FILESTREAM). It staggers me that Microsoft have basically said that anyone without a huge IT budget will just have to live without a decent high availability option, especially when we had one before in Database Mirroring!
As you said, if they could, in Standard Edition, just allow a very basic implementation of High Availability Groups, just enough to replicate what Database Mirroring gives us now, that’d be completely acceptable. Do we know yet whether SQL Server 2014 has such a feature?
LikeLike
Great post. I only hope that someone at
MS will read it and react. We’re looking at moving apps to Azure and require
some form of HA to get descent SLA. We’re currently using WSFC with Standard Ed
on prem and the comparable solution for Azure will cost us 5x what we’re paying
today = no go. There is nothing else in Ent Ed that is of interest to us.
LikeLike
If only this were like Microsoft vs. VMware but for databases, you better believe AlwaysOn AG would be made a standard feature and Microsoft would be saying how DB HA should be a basic feature “for free” just so MS could make a splash and steal some market share. But without such motivation, I don’t see MS doing this in the near term. Long-term, sure, but they’re not going to be in a rush. They are entrenched enough here that the only thing that could motivate them is Wall St.
You bring up a really good idea. A basic AlwaysOn AG feature for the masses, especially to tie in with Azure. Since Windows Server 2012 (and presumably R2) has built in failover clustering, there should be some sort of support in a SQL Server version going forward.
LikeLike
Clarification: Windows Server 2012 – both Standard and Datacenter editions – has built in failover clustering, unlike previous editions which only had it in the highest level edition. So my point is if clustering can be become a “standard” feature, then so should some kind of AlwaysOn AG.
LikeLike
I totally agree!!
With new per-core licensing and mirroring deprecation, it seems like people are paying MORE to get LESS.
I’m fortunate to have mostly Enterprise editions at my work (what a luxury to not worry about Backup compression or Ent. features). But we are looking to reduce cost by using more STANDARD instead of ENTERPRISE editions. Honestly, who isn’t, given the economy and budget cuts?
LikeLike