AlwaysON – Unable to access the ‘JB1’ database because no online secondary replicas are enabled for read-only access. (Microsoft SQL Server, Error: 982)

Environment

Blog29_1

-> The Application makes a connection to the Database JB1 with ApplicationIntent=ReadOnly and receives below message,

Unable to access the ‘JB1’ database because no online secondary replicas are enabled for read-only access. Check the availability group configuration to verify that at least one secondary replica is configured for read-only access. Wait for an enabled replica to come online, and retry your read-only operation.
Changed database context to ‘JB1’. (Microsoft SQL Server, Error: 982)

-> The message indicates that there are no active Read-Only partners. When checked further it is clear that Server JBSERVER2 and JBSERVER3 were down.

-> We were advised that the Servers JBSERVER2 and JBSERVER3 will not be up for next 6 Hours. Now the Application team doesn’t want to change their connection string by dropping ApplicationIntent=ReadOnly and wanted us to make sure that the primary accepts Read connections.

-> The Alwayson Availability group setting is as below,

Blog35_1.PNG

-> We changed the setting “Connections in Primary Role” from “Allow read/write connecions” to “Allow all connections” as below,

Blog35_2.PNG

-> The Application started connecting to the Primary Replica even with ApplicationIntent=ReadOnly.

-> This now brings up the question, why can’t we have the setting “Connections in Primary Role” set to “Allow all connections” instead of “Allow read/write connecions”. “Allow all connections”  can be an issue as Connections where the Application Intent is set to ReadOnly are not disallowed on the Primary Replica anymore. With this setting in place the read workloads may execute on both Primary and the secondary, If server JBSERVER2 which is on the same data centre as the PRIMARY goes down and we have intermittent network issues between DataCenters which makes JBSERVER3 to be offline Intermittently for JBSERVER1. So the Read workload might run on both JBSERVER1 and JBSERVER3.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Advertisements

AlwaysON – How to disable Read-Only routing for an Availability Group

-> We have configured Read-Only routing list for an availability group. Now the requirement changes and the Read-Only routing needs to be disabled. If you have a scenario like this in your hand, then this post is for you!

-> Please refer article “https://jbswiki.com/2017/09/06/configuring-read-only-routing-list-for-alwayson-availability-group/” to create read-Only routing list for you Availability group.

Environment

Blog29_1

-> Looking at SSMS,

Blog_34_1.PNG

-> Checking the Read-Routing List that is setup currently on the Primary Replica using below query,

SELECT ag.name as "Availability Group", ar.replica_server_name as "When Primary Replica Is",
rl.routing_priority as "Routing Priority", ar2.replica_server_name as "RO Routed To",
ar.secondary_role_allow_connections_desc, ar2.read_only_routing_url
FROM sys.availability_read_only_routing_lists rl
inner join sys.availability_replicas ar on rl.replica_id = ar.replica_id
inner join sys.availability_replicas ar2 on rl.read_only_replica_id = ar2.replica_id
inner join sys.availability_groups ag on ar.group_id = ag.group_id
ORDER BY ag.name, ar.replica_server_name, rl.routing_priority

Blog_34_2.PNG

-> Trying a connection with Switch -KReadonly to see if it Read-Routing list works and connects to JBSERVER3.

Blog_34_3.PNG

-> We will Disable the Read-Routing list using below query,

ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'JBSERVER1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=NONE));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'JBSERVER2' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=NONE));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON
N'JBSERVER3' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=NONE));

-> Checking the Read-Routing details on the Primary Replica after it is removed,

SELECT ag.name as "Availability Group", ar.replica_server_name as "When Primary Replica Is",
rl.routing_priority as "Routing Priority", ar2.replica_server_name as "RO Routed To",
ar.secondary_role_allow_connections_desc, ar2.read_only_routing_url
FROM sys.availability_read_only_routing_lists rl
inner join sys.availability_replicas ar on rl.replica_id = ar.replica_id
inner join sys.availability_replicas ar2 on rl.read_only_replica_id = ar2.replica_id
inner join sys.availability_groups ag on ar.group_id = ag.group_id
ORDER BY ag.name, ar.replica_server_name, rl.routing_priority

Blog_34_4.PNG

-> It is evident from the above screenshot that the Read-Routing listi ndeed is removed. Lets check what happens if we connect the listener using -KReadonly switch,

Blog_34_5.PNG

-> It connects to the primary Replica. this proves that read-only routing is indeed disabled.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Creating Linked Server to a Multi-Subnet Availability Group Listener with ReadOnly routing

-> A multi-subnet environment is defined when the OS cluster used for AlwaysOn has server nodes that are located in multiple, different subnets. By default, the behavior of the SQL client libraries is to try all IP addresses returned by the DNS lookup – one after another (serially) until the all of the IP addresses have been exhausted and either a connection is made, or a connection timeout threshold has been reached.

-> Microsoft added a new connection string parameter that can be added to change the connection behavior. This new parameter, MultiSubnetFailover, should be used and set to “TRUE.” When set to TRUE, the connection attempt behavior changes. It will no longer attempt all of the IP addresses serially, but in parallel.

-> The parameter MultiSubnetFailover cannot be used in the Linked Server as part of the provider string. We will have to create a Data Source and then use the Data Source in the Linked Server.

Blog33_1.PNG

Blog33_2.PNG

-> I am using Windows Aunthentication to connect the Listener. If you want to use SQL Server Authentication, select as appropriate.

Blog33_3.PNG

-> Change “Change the default database to:”  as indicated in the below screenshot from database Master to a database that is part of Alwayson Availability group that is part of the listener. Make sure the Application Intent is READONLY and Multi-subnet failover is checked.

Blog33_4

Blog33_5.PNG

Blog33_6.PNG

Blog33_7.PNG

-> Once the Data Source is created and tested. Move onto creating the Linked server.

Blog33_8.PNG

-> Select “Be made using this security context” and provide the SQL Server Authentication Credential if required. I am using Windows authentication, so using “Be made using the login’s current securoty context”.

Blog33_9.PNG

-> Once the Linked server is created. Execute the below query and check if the output returned is your readable secondary and not pointing to the primary.

select * from openquery([JBSERVER1],'select @@servername')

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.