Always On

Availability Groups:
read-only
secondary replicas
Information in this document, including URL and other Internet website references, is subject to change without
notice. Unless otherwise noted, the companies, organizations, products, domain names, email addresses, logos,
people, places, and events depicted in examples herein are fictitious. No association with any real company,
organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering
subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the
furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other
intellectual property.

© 2017 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows Server, PowerShell, and SQL Server are either registered trademarks or trademarks of
the Microsoft group of companies.

All other trademarks are property of their respective owners.

 Contents

Introduction .............................................................................................................. 4
Objectives.................................................................................................................. 5
Overview of availability groups (AG) and read-only secondary replica...... 7
Configure Always On Availability Groups for SQL Server .............................. 8
Overview of Always On Availability Group Listeners ......................................16
Load-balance secondary replicas ...................................................................... 22
Monitor availability groups.................................................................................. 30
Appendix ................................................................................................................. 33

Always On Availability Groups: read-only secondary replicas

Introduction
Microsoft SQL Server Availability Groups brings together best-in-class, high-availability (HA) capabilities, while
also providing a comprehensive integrated scaling solution. In a typical database application, multiple clients run
various workload types, which can lead to bottlenecks due to resource constraints. However, it is possible to free
up resources and gain higher throughput for the online transaction processing (OLTP) workload—or deliver
higher performance and scale on read-only workloads. This can be achieved by leveraging the fastest replication
technology for SQL Server, creating a group of replicated databases to offload reporting and analytics workloads
to read-only replicas.
With availability groups, one or more secondary replicas can be configured to support read-only access to
secondary databases. You can configure a read-scale availability group for SQL Server on either Windows or
Linux. The client applications running analytics or reporting workloads can connect directly to secondary
databases. As another option, applications can be set up using a read-only routing list and connect to the primary
server to forward the connection request to each secondary replica from the routing list in a round-robin fashion.

Always On Availability Groups: read-only secondary replicas 4

Objectives
SQL Server 2017 introduces read-scale availability groups without a failover cluster. This approach conserves
resources for mission-critical workloads running on the primary server while enabling users to connect directly to
readable secondary replicas—without depending on integration with any clustering technology.
The objective of this hands-on lab is to help you understand the features of availability groups in SQL Server 2017
for read-scale access. By the end of this lab, users should understand how to enable Always On Availability Groups
for SQL Server on Windows Server 2016, and configure an availability group with a read-only secondary replica to
support read-scale workloads. You will learn how to configure and execute a failover on the sample application to
demonstrate connecting to a read-only secondary replica as a data mart for analytical workloads. Finally, you will
gain an understanding of “chatter” across replicas to show a balanced load in action.

Lab details and prerequisites

This exercise assumes that you already have a solid understanding of Always On Availability Groups. For more
information, see Always On Availability Groups (SQL Server).
For this lab, we will need the following:
1. Four Windows Server 2016 machines, three of which are running SQL Server 2017 in a non-clustered
availability group
2. SQL Server Management Studio to view and manage SQL Server instances and databases, as well as
execute TSQL queries
Prerequisites include:
• Before creating the availability group, you will need to set your environment so that all servers hosting
availability replicas can communicate

Always On Availability Groups: read-only secondary replicas 5

Understanding the environment
Here are the architecture details of the lab environment:
• A virtual network containing multiple subnets, including a front-end and a back-end subnet

• Three SQL Servers (deployed on Windows Server) with details deployed to the back-end subnet and joined
to the domain

• One domain controller (Windows Server 2016)

- SQL Server Management Studio to connect to SQL Server instances

- Visual Studio (VS) code to modify application configuration

- Node application to read data

Note: It is not a best practice to run SSMS on a domain controller, or log on to a domain controller to modify
source code or administer a database. This configuration is for lab purposes only.

Domain
Controller
WIN-AGDC
AG Node AG Node AG Node
WIN-AGNODE01 WIN-AGNODE02 WIN-AGNODE03
SSMS
Node.js
SQL Server SQL Server SQL Server
MyExpenses

aoag.sqlserver.labs Domain Network 10.0.1.0

Clustering Network 10.0.2.0

iSCSI Network 10.0.3.0

Always On Availability Groups: read-only secondary replicas 6

Overview of availability groups (AG) and read-
only secondary replica
An availability group supports a replicated environment for a discrete set of user databases, known as availability
databases. This availability group can be configured with applications, which are transparently redirected to the
corresponding read-only replica when a read intent parameter is specified.
With availability groups, one or more secondary replicas can be configured to support read-only access to
secondary databases. To create the read-scale availability group, configure the availability group with the
CLUSTER TYPE as NONE. In this case, we will specify the NONE value to use for read-scale scenarios.
The steps to create an availability group on Windows servers for read-only secondary replica include:
1. Configure SQL Server on each node
2. Enable and create the availability group
3. Join a secondary SQL Server to the availability group
4. Connect to read-only secondary replicas
It’s important to note that the use of read-scale availability groups is not part of a high-availability/disaster-
recovery (HA/DR) scenario. Failover and recovery require a clustered environment such as Windows Server
Failover Clustering (WSFC) or Pacemaker. Availability group replicas outside of a cluster do work well for the
following:
• Data replication across domains/regions

• Read-only data mart for data warehouse/analytical workloads

• Data migration

Always On Availability Groups: read-only secondary replicas 7

Configure Always On Availability Groups for
SQL Server
This section covers the steps for configuring Always On Availability Groups. In this configuration, the availability
group does not provide HA, but it does provide read-scale. The client applications running analytics or reporting
workloads can directly connect to the secondary databases. The customer can also set up a read-only routing list
and connect to the primary server, which will forward the connection request to each of the secondary replicas
from the routing list in round-robin fashion.
Availability groups have already been enabled on all three SQL Servers in the pre-built lab environment. If you are
creating your own environment, refer to the steps in the appendix.

Creating an availability group

We will create the availability group on the instance of SQL Server that hosts the databases to be added to the
availability group. At least one of the databases you wish to include in your availability group needs to be present
and fully backed up.
For the purposes of this lab, the Expense database to be used in our MyExpenses sample application has been
created on the primary node (WIN-AGNODE01), and a full backup has been created. If you are building your own
environment, or find that the expense database is missing, see “Setting up the application database” in the
appendix for instructions to create and populate the required database.
Create the initial primary replica on the instance of SQL Server where you create the availability group. You can
specify from one to four secondary replicas. For information about availability group and replica properties, see
CREATE AVAILABILITY GROUP (Transact-SQL).
To create an availability group, you can use any of the following tools:
• New Availability Group Wizard
• Transact-SQL
• SQL Server PowerShell
In this lab, we will be using the New Availability Group Wizard. We recommend that you read the Prerequisites,
Restrictions, and Recommendations before attempting to create your first availability group.
SQL Server Management Studio is installed on our Windows Server 2016 Domain Controller (Win-AGDC). We will
be using the SSMS installed on this server for creating the availability group with the New Availability Group
Wizard.
Using the New Availability Group Wizard on the Windows Server 2016 Domain Controller machine:
1. In Object Explorer, connect to the server instance that hosts the primary replica (win-agnode01).

Always On Availability Groups: read-only secondary replicas 8

 2. Expand the Always On High Availability node and the Availability Groups node.

3. To launch the New Availability Group Wizard, select the New Availability Group Wizard command.

4. The first time you run this wizard, an introduction page appears. To bypass this page in the future, you can
click Do not show this page again. After reading this page, click Next.

5. On the Specify Availability Group Options page, enter the name of the new availability group in the
Availability group name field. This name must be a valid SQL Server identifier that is unique on the
cluster and in your domain. The maximum length for an availability group name is 128 characters.

6. Next, specify the cluster type. Here we will choose WSFC. For details, see Specify Availability Group Name
Page.

7. On the Select Databases page, the grid lists user databases on the connected server instance that are
eligible to become the availability databases. You can select one or more of the listed databases to
participate in the new availability group. The primary database for the MyExpense application has been
created and populated, as well as fully backed up. Select the Expenses database.

Note: These databases will be the initial primary databases. For each listed database, the Size column
displays the database size, if known. The Status column indicates whether a given database meets the
prerequisites for availability databases. If you change a database to make it eligible, click Refresh to

Always On Availability Groups: read-only secondary replicas 9

 update the databases grid. If the database contains a database master key, enter the password for the
database master key in the Password column.

8. On the Specify Replicas page, specify and configure replicas for the new availability group. This page
contains four tabs. Below are the details:

Replicas Use this tab to specify each instance of SQL Server that will host a secondary
replica. Note that the server instance to which you are currently connected must
host the primary replica.
In this lab, we will be using our second node as a secondary replica (win-
agnode02).
To set this up, click Add Replica and use win-agnode02 for the secondary
replica.

Always On Availability Groups: read-only secondary replicas 10

 Endpoints Use this tab to verify any existing database mirroring endpoints and, if this
endpoint is lacking on a server instance where service accounts use Windows
Authentication, to create the endpoint automatically.

Always On Availability Groups: read-only secondary replicas 11

 Backup Use this tab to specify your backup preference for the availability group, and
preferences your backup priorities for individual availability replicas.

Listener Use this tab to create an availability group listener. By default, the wizard does
not create a listener. We will create the listener later in our lab

Always On Availability Groups: read-only secondary replicas 12

 9. On the Select Initial Data Synchronization page, choose how you want your new secondary databases
to be created and joined to the availability group. We choose the Automate Seeding option. SQL Server
will automatically create the secondary replicas for every database in the group. Automatic seeding
requires that the data and log file paths are the same on every SQL Server instance participating in the
group.

• You can also do Full database and log backup. Select this option if your environment meets the
requirements for automatically starting initial data synchronization.
• Join only: If you have manually prepared secondary databases on the server instances that will host
the secondary replicas, you can select this option. The wizard will join the existing secondary databases
to the availability group.
• Skip initial data synchronization: Select this option if you want to use your own database and log
backups of your primary databases. For more information, see Start Data Movement on an Always On
Secondary Database (SQL Server).

10. The Validation page verifies whether the values you specified in this wizard meet the requirements of the
New Availability Group Wizard. To make a change, click Previous to return to an earlier wizard page to
change one or more values. Then, click Next to return to the Validation page, and click Re-run
Validation.

11. On the Summary page, review your choices for the new availability group. To make a change, click
Previous to return to the relevant page. After making the change, click Next to return to the Summary
page.

12. The Progress page displays the progress in creating the availability group (configuring endpoints, creating
the availability group, and joining the secondary replica to the group).

Always On Availability Groups: read-only secondary replicas 13

 13. When these steps are complete, the Results page displays the result of each step. If all steps succeed, the
new availability group is completely configured. If any steps result in an error, you might need to manually
complete the configuration or use a wizard for the failed step. For information about the cause of a given
error, click the associated Error link in the Result column.

14. When the wizard completes, click Close to exit. As an alternative to using the New Availability Group
Wizard, you can use Transact-SQL or SQL Server PowerShell cmdlets. For more information, see Create an
Availability Group (Transact-SQL) or Create an Availability Group (SQL Server PowerShell).
15. Now we need to verify that the database is created on the secondary servers. For this, connect to On our
secondary SQL Server replica (win-agnode02).

16. Finally, validate that the Expenses database has been created and is synchronized by opening the sql script
at C:\HOL Files\SQLScript\DBSynchronized.sql.

SELECT * FROM sys.databases WHERE name = 'Expenses';

GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM
sys.dm_hadr_database_replica_states;

Always On Availability Groups: read-only secondary replicas 14

Next, you will learn about load balancing to secondary replicas on the AG listener.

Always On Availability Groups: read-only secondary replicas 15

Overview of Always On Availability Group
Listeners
You can provide client connectivity to the database of a given availability group using Always On Availability
Group Listeners. An availability group listener is a virtual network name (VNN) to which clients can connect to
access a database in a primary or secondary replica of an Always On availability group. An availability group
listener enables a client to connect to an availability replica without knowing the name of the physical instance of
SQL Server to which the client is connecting. The client connection string does not need to be modified to
connect to the current location of the primary replica.

Configuring Always On Availability Group Listeners

To create or configure Always On Availability Group Listeners:
1. In Object Explorer, connect to the server instance that hosts the primary replica of the availability group,
and then click the server name to expand the server tree.

2. Expand the Always On High Availability node and the Availability Groups node (MyExpenseAG).

3. To create a listener, right-click the Availability Group Listeners node, and then select the New Listener
command to open the New Availability Group Listener dialog box. For more information, see Add
Availability Group Listener (Dialog Box).

Always On Availability Groups: read-only secondary replicas 16

 4. Specify the name of the listener and port. Here we specified MyExpenseList as the Listener DNS name and
Port as 1433. Click Network Mode and select Static IP. Specify 10.0.2.125 as IP. Click Availability Group
Listener, and specify the IP from the available IP range. Here we have used 10.0.2.125. Click OK. This will
take some time while your listener for this availability group is created.

5. You can see that the listener is created.

Always On Availability Groups: read-only secondary replicas 17

Registering DNS names for Always On Availability Group Listeners
For the application to access our data by using the listener’s DNS name, we will need to add a DNS entry for the
listener. Alternatively, we can use the IP address when configuring the MyExpense application. To add a new DNS
entry:
1. Open Server Manager, and select Tools -> DNS.

Always On Availability Groups: read-only secondary replicas 18

 2. In DNS Manager, expand the tree on the left-hand pane: DNS -> WIN-AGDC -> Forward Lookup Zones,
and select aoag.sqlserver.labs.

3. Click the Action menu, and select New Host (A or AAAA)…

Always On Availability Groups: read-only secondary replicas 19

 4. Type the values for the listener name ExListener and the IP address (10.0.2.125). Ensure that Create
associated pointer (PTR) record and Allow any authenticated user… are unchecked, and then click
Add Host.

5. Right-click the domain node in the tree (aoag.sqlserver.labs), and select Reload.

Always On Availability Groups: read-only secondary replicas 20

 6. Click Yes to continue.

7. Right-click the WIN-AGDC node in the tree, and select Clear Cache.

The Availability Group listener should now be reachable, once we configure our application.

Always On Availability Groups: read-only secondary replicas 21

Load-balance secondary replicas
To configure an Always On availability group to support read-only routing in SQL Server 2017, you can use either
Transact-SQL or PowerShell. Read-only routing refers to the ability of SQL Server to route qualifying read-only
connection requests to an available Always On readable secondary replica (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. 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.
In this section, we will walk the user through setting up read-only routing and load balancing to secondary
replicas on the AG listener.
Before you begin with the configuration of a read-only routing list, refer to the following:
• Prerequisites

• What Replica Properties Do You Need to Configure to Support Read-Only Routing?

• Security

Configuring a read-only routing list

Follow these steps to configure read-only routing using Transact-SQL:
1. Connect to the server instance that hosts the primary replica.
2. Adding or modifying a replica for an existing availability group, use the ALTER AVAILABILITY GROUP
Transact-SQL statement. To configure read-only routing for the secondary role, in the ADD REPLICA or
MODIFY REPLICA WITH clause, specify the SECONDARY_ROLE option, as follows:

SECONDARY_ROLE ( READ_ONLY_ROUTING_URL ='TCP://system-address:port')

3. The parameters of the read-only routing URL are as follows:

a. system-address: A string, such as a system name, a fully qualified domain name, or an IP address, that
unambiguously identifies the destination computer system.
b. Port: A port number that is used by the Database Engine of the SQL Server instance.

Always On Availability Groups: read-only secondary replicas 22

Configuring load-balancing across read-only replicas
1. You can configure load-balancing across a set of read-only replicas. To take advantage of this feature, use
one level of nested parentheses around the READ_ONLY_ROUTING_LIST server instances in the CREATE
AVAILABILITY GROUP or ALTER AVAILABILITY GROUP commands.
2. Run the sql script command to modify two availability replicas of an existing availability group, such as
AG1 to support read-only routing if one of these replicas currently owns the primary role. To do this, open
the C:\HOL Files\SQLScript\AlterAG.sql. In this script, replace the availability group with your availability
group name.

ALTER AVAILABILITY GROUP ExpenseReadOnly

MODIFY REPLICA ON
N'win-agnode01' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP [ExpenseReadOnly]
MODIFY REPLICA ON
N'win-agnode01' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://win-
agnode01.aoag.sqlserver.labs:1433'));

ALTER AVAILABILITY GROUP [ExpenseReadOnly]

MODIFY REPLICA ON
N'win-agnode02' WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP [ExpenseReadOnly]
MODIFY REPLICA ON
N'win-agnode02' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://win-
agnode02.aoag.sqlserver.labs:1433'));

ALTER AVAILABILITY GROUP [ExpenseReadOnly]

MODIFY REPLICA ON
N'win-agnode01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('win-agnode02','win-agnode01')));

ALTER AVAILABILITY GROUP [ExpenseReadOnly]

MODIFY REPLICA ON
N’win-agnode02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('win-agnode01','win-agnode02)));
GO

Always On Availability Groups: read-only secondary replicas 23

Always On Availability Groups: read-only secondary replicas 24
Access read-only secondary replicas using a sample application
In this section, we will connect an availability group listener to a secondary replica that is configured to allow
read-only workloads. We will walk the user through connecting to a read-only secondary replica as a data mart
for analytical workloads, and then take a look at the “chatter” across replicas to show a balanced load in action.

Setting up the sample application project

1. In Visual Studio Code, open the web app folder File -> Open Folder… [Ctrl+K Ctrl+O] -> C:\HOL
Files\AlwaysonAg\MyExpense.Web.
2. Next, restore the npm packages before running the application by pressing CTRL+SHIFT+P or the F1 key
in Visual Studio Code.
3. In the command palette, type task, and select Tasks: Run Task.

Always On Availability Groups: read-only secondary replicas 25

 4. Execute the prepare procedure for our application.

5. Be sure to update the database connection details for this app as well by opening the file
./server/config/server.config.js and updating the login password and port information accordingly.
6. Here you need to specify the logon information:
Username: sa and password: Pass@word1
Change the port: 1433
Change the ‘host’ value from ‘localhost’ to ‘ExListener’

Next, we will configure the application with an availability group listener for an Always On availability group.
Always On Availability Groups: read-only secondary replicas 26
Requirements and recommendations for client connection strings
For a client application to use read-only routing, its connection string must satisfy the following requirements:
• Use the TCP protocol

• Set the application intent attribute/property to read-only

• Reference the listener of an availability group that is configured to support read-only routing

• Reference a database in that availability group

In addition, we recommend that connection strings enable multi-subnet failover, which supports a parallel client
thread for each replica on each subnet. This minimizes client reconnection time after a failover. The syntax for a
connection string depends on the SQL Server provider an application is using.

The following sample 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 for read-only routing:

Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI;ApplicationIntent=ReadO
nly;MultiSubnetFailover=True

1. On Visual Studio Code, click F5 to run the application. You can see it executing and listening on port 8000.

Always On Availability Groups: read-only secondary replicas 27

 2. Open your browser and go to http://localhost:8000.

Always On Availability Groups: read-only secondary replicas 28

 3. Click SIGN IN to check that the app shows the information.

Note: The application is not authenticated.

For more information about read-only application intent and read-only routing, see Availability Group
Listeners, Client Connectivity, and Application Failover (SQL Server).

Always On Availability Groups: read-only secondary replicas 29

Monitor availability groups
To monitor the properties and state of Always On Availability Groups, you can use the following tools.
System Center Management Pack for SQL Server: This pack for SQL Server (SQLMP) is the recommended
solution to monitor availability groups, availability replica, and availability databases for IT administrators.
Features that are particularly relevant to Always On Availability Groups include:
• Automatic discoverability of availability groups, availability replicas, and availability databases from
hundreds of computers, which lets you easily track your Always On Availability Groups inventory

• Fully capable System Center Operations Manager (SCOM) alerting and ticketing to provide details that
enable faster issue resolution

• A custom extension to Always On health monitoring using policy-based management (PBM)

• Health roll-ups from availability databases to availability replicas

• Custom tasks that manage Always On Availability Groups from the System Center Operations Manager
console
For more information, see System Center Management Pack for SQL Server.
SQL Server Management Studio: The Object Explorer Details pane displays basic information about the
availability groups hosted on the instance of SQL Server to which you are connected. Visit Use Object Explorer
Details to monitor availability groups for more information. Properties dialog boxes enable you to view the
properties of availability groups, replicas, or listeners and, in some cases, to change their values. For more
information, see Availability Group Properties and Availability Replica Properties for more information.
For this lab, however, we will use Dynamic Management Views (DMVs) to execute predefined, built-in views to
monitor replicas.
The Transact-SQL (DMVs) Always On Availability Groups catalog and dynamic management views provide a
wealth of information about your availability groups and their replicas, databases, listeners, and WSFC cluster
environment. For more information, see Monitor Availability Groups (Transact-SQL).
1. To monitor Always On Availability Groups, a feature on a server instance, use the SERVERPROPERTY
built-in function:

SERVERPROPERTY (‘IsHadrEnabled, HadrManagerStatus)

This returns server property information about whether Always On Availability Groups is enabled and, if
so, whether it has started on the server instance.
2. To monitor the WSFC cluster that hosts a local server instance and is enabled for Always On Availability
Groups, use the view:

sys.dm_hadr_cluster
If the WSFC node that hosts an instance of SQL Server enabled with Always On Availability Groups has
WSFC quorum, then sys.dm_hadr_cluster returns a row that exposes the cluster name and quorum
information. If the WSFC node has no quorum, no rows are returned.

Always On Availability Groups: read-only secondary replicas 30

 3. To monitor the availability groups for which the server instance hosts an availability replica, use the
following view:

sys. availability_groups
This returns a row for each availability group for which the local instance of SQL Server hosts an availability
replica. Each row contains a cached copy of the availability group metadata.

Always On Availability Groups: read-only secondary replicas 31

Summary and additional information
In this lab, we demonstrated how Availability Group secondary replica databases can be configured to allow read-
only access to applications. We also demonstrated how to enable load-balancing among the secondary replicas,
to route requests in a round-robin fashion. These capabilities can be used to reduce read-only queries on the
primary replica, allowing resource to focus on read-write operations.
Read-scale replicas are not part of a HA/DR solution, but can be useful in those scenarios in which data is read for
reporting or BI, or source data for ETL operations into a large-scale data warehouse.
With SQL Server 2017, read-scale availability groups can operate without a failover cluster. This approach
conserves resources for mission-critical workloads running on the primary server while enabling users to connect
directly to readable secondary replicas—without depending on integration with any clustering technology.
You can find more information on Always On Availability Groups on Microsoft’s documentation site. And
download the latest version of SQL Server from the SQL Server downloads page at Microsoft.com

Always On Availability Groups: read-only secondary replicas 32

Appendix
Enabling Always On Availability Groups
The Always On Availability Groups feature must be enabled on every instance of SQL Server 2017 that is to
participate in an availability group. Before you begin, see the Enable and Disable Always On Availability Groups
(SQL Server) prerequisites page to understand everything that is required to enable the Always On Availability
Groups feature.
Follow these steps to enable Always On Availability Groups:
1. Connect to the Windows Server Failover Clustering (WSFC) node that hosts the SQL Server instance where
you want to enable Always On Availability Groups.

2. On the Start menu, point to All Programs -> Microsoft SQL -> Server 2016 -> Configuration Tools,
and then click SQL Server Configuration Manager.

3. In SQL Server Configuration Manager, click SQL Server Services. Right-click SQL Server (<instance
name>), where <instance name> is the name of a local server instance for which you want to enable
Always On Availability Groups, and then click Properties.

4. Select the Always On High Availability tab.

5. Verify that the Windows failover cluster name field contains the name of the local failover cluster. If this
field is blank, the server instance currently does not support Always On Availability Groups. It might not be
supported because the local computer is not a cluster node, the WSFC cluster has been shut down, or this
edition of SQL Server 2016 does not support Always On Availability Groups.

6. Select the Enable Always On Availability Groups check box, and click OK.

SQL Server Configuration Manager saves your change. Then, you must manually restart the SQL Server service.
This enables you to choose a restart time that is best for your business requirements. When the SQL Server service
restarts, Always On will be enabled, and the IsHadrEnabled server property will be set to 1.
You can also use PowerShell: Enable and Disable Always On Availability Groups (SQL Server).
Repeat steps 1‒6 for each SQL Server in your cluster.

Setting up the application database

We will begin by setting up the application database. The MyExpense app includes a data generation tool in the
repository that will create the Expenses database, and populate it with sample data.
To begin, follow these steps:
1. Open the Node.js command prompt from the start menu. Change directory to C:\HOL
Files\src\Expenses.SQLLinux\MyExpenses.DataGenerator, type npm install, and hit Enter. This will
download the dependency modules for the data generator app.
2. Open the project folder in Visual Studio Code. From there, open File -> Open Folder… [Ctrl+K Ctrl+O] ->
/home/labuser/HandsOnLabs/Apps/developer-immersion-data-
master/source/Expenses.SQLLinux/MyExpenses.DataGenerator

Always On Availability Groups: read-only secondary replicas 33

 3. In the Explorer panel, expand the config sub folder, and highlight the file db.config.js.

4. You will need to supply the SA password you provided in provisioning the SQL Server.
5. The default port in the sample db.config.js file expects tcp port 11433. In db.config.js, change this value to
1433.
6. Return to the Node.js command prompt, and enter node app.js.
7. You will be presented with two data load options. Choose option 1, which will take a few seconds to run.
This will create a database named Expenses, and populate data needed for the app to run.

Always On Availability Groups: read-only secondary replicas 34