New High Availability and Disaster Recovery Features in SQL Server 2019

ApplicationFrameHost 2018 05 20 17 01 29

While it has been in preview for quite some time, at Ignite 2019, Microsoft announced the general availability of SQL Server 2019. It seems hard to believe but this newest release marks the 25th anniversary of SQL Server. In retrospect, I’ve been working with SQL Server since the 6.5 release and there’s no doubt that it has come a long way. The latest release of SQL Server 2019 has several important enhancements for high availability (HA) and disaster recovery (DR). Let’s take a look at some of the main HA and DR changes in SQL Server 2019.

Accelerated Database Recovery

Newly added to SQL Server 2019, Accelerated Database Recovery (ADR) enables faster database recovery through a redesign of the SQL database engine recovery process. With previous versions of SQL Server the committed transactions are written to disk during the redo phase and the uncommitted transactions are rolled back during the undo phase. Recovery time is impacted by the largest transaction in the undo phase. ADR uses a new Persisted Version Store (PVS) in the data file that contains previous versions of the data that was modified by transactions. This enables the transaction log to only be processed from the last checkpoint. ADR accelerates transaction rollback and long-running transactions do not impact the total recovery time. ADR is available in both SQL Server 2019 on-premise and Azure SQL Database and it is included in both the Standard and Enterprise editions.

Software Assurance Licensing Changes

While not technically a feature, Microsoft also announced some licensing changes that have a significant impact on HA and DR. Previously, a SQL Server customer with Software Assurance was able to deploy one passive instance for either HA or DR with no additional licensing costs. The main caveat being that this passive instance did no production work at all. With SQL Server 2019, SA customers can now have three fail-over instances or what Microsoft licensing calls OSEs (Operating System Environments). Essentially, this means that you can have one passive OSE that you can use for any purpose but most companies will use it for HA and then you can have two additional passive OSEs that can be used for DR. For instance, you could have one synchronous HA Availability Group node that’s used for fast local failover and then up to two asynchronous Availability Group nodes that are used for DR. The new licensing also enables you to deploy your passive OSEs in Microsoft Azure.

In addition, previously the passive server could not be used for any type of production work. With the new SQL Server 2019 licensing changes you can perform the following operations on the passive servers:

  • Database consistency checks
  • Log backups
  • Full backups
  • Monitoring resource usage data

Being able to run consistency check and backups on the passive servers can be a big benefit. These licensing changes will be extended to all SQL Server customers with SA which means that you can take advantage of this even if you’re not running SQL Server 2019. You can find more information on SQL Server 2019 licensing at How to license SQL Server.

Enhancements to AlwaysOn Availability Groups

SQL Server 2019 also increases the maximum number of synchronous replicas that are supported by AlwaysOn Availability groups from three to five. In addition, a new secondary-to-primary replica connection redirection feature enables client applications to be connected to the primary replica regardless of the target server specified in the connection string.

Kubernetes MIA

Interestingly, one of the HA/DR features that was pulled from the general release of SQL Server 2019 was SQL Server AlwaysOn Availability Groups support for Kubernetes. This feature was in the early CTPs and Release Candidates but it was pulled from the last Release Candidate and the general release. It is currently in preview and will probably be added as an update to SQL Server 2019 later in the year.

Related Article: