In this blog I will go through step by step how to configure Read-Only routing for scale-out report workloads using SQL Server 2012 Always On Database Availability Groups.
In SQL Server 2012, AlwaysOn Availability Groups provides group level high availability for any number of databases on up to four secondaries known as ‘replicas’. The secondary replicas
allow direct read-only querying or can enforce connections that specify ‘ReadOnly’ as their Application Intent. The secondaries primary use is to provide high availability or disaster recovery for the groups of databases being replicated. The secondaries can
also be used to offset backup operations, DBCC checks, and to offload reporting workloads. The secondary copies of these databases known as secondary replicas have the ability to be read when they are in the secondary role. This is unlike Database Mirroring
which requires a Database Snapshot in order to read a static view of the database at the Database Snapshot was created.
AlwaysOn brings in the strengths of Clustering, Log Shipping and Database Mirroring together where the method to transmit data is very similar to Database Mirroring with much more
functionality and flexibility. AlwaysOn requires Windows Server 2008 clustering features, but does not require that SQL Server itself be clustered.
In AlwaysOn, Read-Only routing refers to the ability of SQL Server to route qualifying read-only connection requests to an available AlwaysOn
readable secondary replica (http://msdn.microsoft.com/en-us/library/ff878253.aspx)
that is, a replica that is configured to allow read-only workloads when running under the secondary role. To support read-only routing, the availability group must possess an
availability group listener (http://msdn.microsoft.com/en-us/library/hh213417.aspx).
Read-only clients must direct their connection requests to this listener, and the client's connection strings must specify the application intent as "read-only." That is, they must be
read-intent connection requests.
This can be seen in the connection string, an example is shown below:
Provider=SQLNCLI11.1;Integrated Security=SSPI;Persist Security Info=False;User ID="";Initial Catalog="";Data Source=AGListner;Initial File Name="";Server SPN="";ApplicationIntent=READONLY
Read-Only routing is a great new feature that can be leveraged to scale out reporting workloads such as SQL Server Reporting Services reports. All of your reports hosted in SharePoint or on a Native Mode installation
of Report Server can specify read-only intent and can be serviced by your secondary replicas. This takes the heavy read workload that typically causes SQL Server blocking and consumes memory and CPU from your primary read/write database and frees up those
To facilitate Read-Only routing I setup three SQL Server 2012 instances and then setup a database availability group using two Adventure Works databases.
Always On Database Availability Group Diagram:
Diagram of Server Manager:
My Windows 2008 R2 server names are
listed below (3 node cluster):
I have loaded a SQL 2012 named instance on each server with the following names:
Note: With AlwaysOn Availability Groups it is a good practice to make all of the named instances the same name for data synchronization.
Availability Group Listener (This is required to be setup for read-only routing):
The Availability Group Listener is much like a virtual network name in traditional SQL clustering as it is a pointer to the SQL Instance that currently hosts the database availability group.
View from SQL Server Management Studio:
In this post we are using the new SQL Server Data Tools which replaces Business Intelligence Development Studio. SQL Server 2012 RTM has the correct client driver for .NET 4.0.2 that will expose
the connection string property ApplicationIntent.
The syntax for a connection string depends on the client provider an application is using. The following example connection string for the .NET Framework Data Provider 4.0.2 for SQL
Server illustrates the parts of a connection string that are required and recommended to work for read-only routing:
Read-Only routing requires that the availability replica be enabled for read access. This can be done at the time the Always On Availability Group is setup. You can also change and view this
property by looking at the properties of the Availability Group:
Availability Group property dialogue:
Availability Group property dialogue:
Note: In the above screen shot you can see that the two replicas are marked to allow read connections.
To setup the Read-Only routing list you must be using an Availability Group Listener. In essence, you are essentially creating a SQL Server routing table for AlwaysOn that redirects connections
to the secondary when the Application Intent is set to Read-Only. Below is the script that I used to setup the list for each replica based on whether it is in the Primary Role or the Secondary Role:
Note: For a deeper explanation and a VERY handy script that will generate the ROR URL for you please see Matt Neerincx’s blog post
I have created a report in SQL Server Data Tools which is the new Business Intelligence Development Studio. Within SQL Server Data Tools I created a simple Report Project and a simple report to show how a reporting type of
workload can be routed by SQL Server to a secondary read-only replica.
The above screenshot shows that I have two data sets. DataSet1 represents the result set that I am displaying in the report. DataSet2 is a simple “SELECT @@SERVERNAME” which returns the current
instance name of the SQL Server for which the data source connection is currently connected to. I am using this to populate a text box with the SQL Server instance name so that I can show you which instance in my AlwaysOn environment executes the query for
Now let’s take a look at how the SSRS report data source is configured for Read-Only Routing:
The above screen shot shows the properties of the shared data source in my report. Notice the use of the Availability Group Listener name
SQL1 as the Data Source property and the ApplicationIntent=ReadOnly option. These are both required for SQL Server to use the Read-Only routing list I configured earlier.
Another view of the data source properties in SQL Server Data Tools:
Now that the data source is configured properly let’s run the report. Before I run the report I want to verify which instance is in the primary role.
With the Read-Only Routing capabilities SQL Server is now more scalable than ever. Customers can utilize secondary replicas for scaling reporting type workloads, increasing the value of their
SQL Server infrastructure while increasing performance by offloading heavy read workloads that commonly cause contention. Applications like SQL Server Reporting Services in SharePoint mode or Native mode can now easily take advantage of using secondary replicas
Read-Only routing is yet another great feature of SQL Server 2012!
Version 1.0 SQL Server Always On Read-Only Routing for scaling reporting workloads.
Nice article Kevin.
This article is a great deep dive into read-only routing.
So, sooner or later the secondary read-only needs to become writable to get new data, then how does the report react? Does it return an error in this case?
@ArthurZ - Think in terms of Database Mirroring. Writes to Always On secondary's are done via a process called Data Synchronization. The only writes that occur on the secondary are writes that first occur on the primary and become synchronized to the secondary by way of Data Synchronization. This is transparent to end users.
Writes can never occur on an Always On Read-Only secondary by anything other than the Data Synchronization process.