None of the IP addresses configured for the availability group listener can be hosted by the server ”

-> I was configuring Alwayson availability group on a database server JBSERVER1 with replicas to JBSERVER2 and JBSERVER3.

-> The setup can be identified with below design,

Blog43_1.PNG

-> I was able to create the availability group and add the required database onto it. I tried adding the listener and got the below error,

TITLE: Microsoft SQL Server Management Studio
——————————
Create failed for Availability Group Listener ‘JBS_APP’. (Microsoft.SqlServer.Smo)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=14.0.17199.0+((SSMS_Rel).171004-0254)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Create+AvailabilityGroupListener&LinkId=20476
——————————
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
——————————
None of the IP addresses configured for the availability group listener can be hosted by the server ‘JBSERVER1’. Either configure a public cluster network on which one of the specified IP addresses can be hosted, or add another listener IP address which can be hosted on a public cluster network for this server. (Microsoft SQL Server, Error: 19456)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=14.00.3022&EvtSrc=MSSQLServer&EvtID=19456&LinkId=20476
——————————
BUTTONS:
OK
——————————

-> JBSERVER1 and JBSERVER2 IPAddress belonged to a subnet and JBSERVER3 IPAddress belonged to a different subnet.

-> I noticed that the IPAddress, I have provided for the Listener was from the subnet same as JBSERVER1 and JBSERVER2 and I did not added any IPAddress for this listener for Subnet with respect to JBSERVER3.

-> I then added 1 IPAddress from each subnet for the Listener and that resolved the issue.

-> Another workaround will be to remove JBSERVER3 from Availability group and just add the listener with IPAddress that belongs to JBSERVER1 and JBSERVER2 subnet. Once we have the other IPAddress, we can add JBSERVER3 to the availability group and then include the second IPAddress from different subnet to the Listener.

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 – 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.

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.

AlwaysON – Working through Crashed Synchronous Secondary Replica

Environment

Blog29_1

-> JBSERVER2 Crashes. The Server is expected to be online after 2 days.

Blog32_2.PNG

-> Checking the SQL Server Management Studio and the Cluster Administrator,

Blog32_3

Blog32_4

-> JBSERVER3 which is an Asynchronous replica, will be changed to a Synchronous replica.

-> Removing the Crashed Replica from Availability group,

Blog32_5.PNG

Blog32_6

Blog32_7.PNG

-> Remove the Node JBSERVER2 from Cluster Administrator,

Blog32_8.PNG

Blog32_9

Blog32_10

-> Server JBSERVER2 comes online after the Rebuild. Lets Add it back to the Availability group.

-> Adding JBSERVER2 to the Failover Cluster,

Blog32_11.PNG

Blog32_12.PNG

Blog32_13.PNG

-> Adding JBSERVER2 as a Replica,

Blog32_14.PNG

Blog32_15.PNG

Blog32_16.PNG

Blog32_17.PNG

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.

AlwaysON – Login Synchronization across Replicas

Environment

Blog29_1

-> Create a Job called “Login Synchronization” on all the Database Servers as part of your Alwayson Availability group. In my Environment, the Job will be created on Database Server JBSERVER1, JBSERVER2 and JBSERVER3. The Job “Login Synchronization” will have the below script executed as part of it.

set nocount on
create table #Sync_Logins (Script varchar(max))
Declare @sql nvarchar(max)
Declare @Primary_Replica varchar(20)
SELECT @Primary_Replica = primary_replica
FROM sys.dm_hadr_availability_group_states a INNER JOIN sys.availability_group_listeners b
ON a.group_id=b.group_id where b.dns_name=’PPN-VDBSL’
IF (@Primary_Replica= @@servername) BEGIN;
Print N’Script cannot run on primary Replica’;
drop table #Sync_Logins
RETURN;
END;
SET @sql=N”;
set @sql = ‘SELECT ”If not Exists (select loginname from master.dbo.syslogins where name = ””” +name +”””’+’) BEGIN CREATE LOGIN ” + QUOTENAME(name) + ” WITH PASSWORD=”
+ sys.fn_varbintohexstr(password_hash) + ” HASHED, SID=”
+ sys.fn_varbintohexstr(sid) + ”, ”
+ ”DEFAULT_DATABASE=”+ QUOTENAME(COALESCE(default_database_name, ”master”))
+ ”, DEFAULT_LANGUAGE=” + QUOTENAME(COALESCE(default_language_name,
”us_english”))
+ ”, CHECK_EXPIRATION=” + CASE is_expiration_checked WHEN 1 THEN ”ON” ELSE
”OFF” END
+ ”, CHECK_POLICY=” + CASE is_policy_checked WHEN 1 THEN ”ON” ELSE ”OFF” END + ” END”
FROM [‘+@Primary_Replica+’].master.sys.sql_logins
WHERE name<>”sa”
UNION ALL
–Windows logins:
SELECT ”If not Exists (select loginname from master.dbo.syslogins where name = ”””+ name +”””’+’) BEGIN CREATE LOGIN ” + QUOTENAME(name) + ” FROM WINDOWS WITH ”
+ ”DEFAULT_DATABASE=”+ QUOTENAME(COALESCE(default_database_name, ”master”))
+ ”, DEFAULT_LANGUAGE=” + QUOTENAME(COALESCE(default_language_name,
”us_english”))+ ” END”
FROM [‘+@Primary_Replica+’].master.sys.server_principals
WHERE type IN (”U”,”G”)
AND name NOT LIKE ”%\SQLServer2005MSSQLUser$%$%”
AND name NOT LIKE ”%\SQLServer2005SQLAgentUser$%$%”
AND name NOT LIKE ”%\SQLServer2005MSFTEUser$%$%”
AND name NOT IN (”BUILTIN\Administrators”, ”NT AUTHORITY\SYSTEM”);’
insert into #Sync_Logins
execute sp_executesql @sql
SET @sql=N”;
SET @sql = ‘SELECT ”EXEC sp_addsrvrolemember ” + QUOTENAME(L.name) + ”, ” +
QUOTENAME(R.name)
FROM [‘+@Primary_Replica+’].master.sys.server_principals L JOIN [‘+@Primary_Replica+’].master.sys.server_role_members RM
ON L.principal_id=RM.member_principal_id
JOIN [‘+@Primary_Replica+’].master.sys.server_principals R
ON RM.role_principal_id=R.principal_id
WHERE L.type IN (”U”,”G”,”S”)
AND L.name NOT LIKE ”%\SQLServer2005MSSQLUser$%$%”
AND L.name NOT LIKE ”%\SQLServer2005SQLAgentUser$%$%”
AND L.name NOT LIKE ”%\SQLServer2005MSFTEUser$%$%”
AND L.name NOT IN (”BUILTIN\Administrators”, ”NT AUTHORITY\SYSTEM”, ”sa”);’
insert into #Sync_Logins
execute sp_executesql @sql
SET @sql=N”;
SELECT @sql=@sql+’ ‘+[Script] FROM #Sync_Logins;
EXECUTE master.sys.sp_executesql @sql;
drop table #Sync_Logins

-> Create a Linked Server to query the primary Replica. In my Environment, Linked servers JBSERVER2 and JBSERVER3 will be created on JBSERVER1. Linked servers JBSERVER1 and JBSERVER3 will be created on JBSERVER2. Linked servers JBSERVER1 and JBSERVER2 will be created on JBSERVER3.

-> The job will gracefully exit with a message “Script cannot run on primary Replica” if the job executes on Primary Replica. If the Job executes on the Secondary replica, It queries the list of Logins on the primary replica and will create the logins that are missing on the Secondary Replicas.

-> This solution just adds the missing Logins on the Secondary Replicas, but will not Drop logins on the Secondary Replica that are not present on the Primary.

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.

Difference between Readable Secondary setting Yes and Read Intent only

-> Readable Secondary setting in AlwaysON is discussed in article “https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-read-only-access-on-an-availability-replica-sql-server” is as below,

No
No user connections are allowed to secondary databases of this replica. They are not available for read access. This is the default setting.

Read-intent only
Only read-only connections are allowed to secondary databases of this replica. The secondary database(s) are all available for read access.

Yes
All connections are allowed to secondary databases of this replica, but only for read access. The secondary database(s) are all available for read access.

Environment

Blog29_1.PNG

-> Creating the Read-Only routing list using below query,

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER1′ WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER1′ WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N’TCP://JBSERVER1.JBS.COM:1433′));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER2′ WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER2′ WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N’TCP://JBSERVER2.JBS.COM:1433′));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER3′ WITH
(SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER3′ WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N’TCP://JBSERVER3.JBS.COM:1433′));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER1′ WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=(‘JBSERVER3′,’JBSERVER2’)));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER2′ WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=(‘JBSERVER3′,’JBSERVER1’)));
ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON
N’JBSERVER3′ WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=(‘JBSERVER2′,’JBSERVER1’)));

-> The Readable Secondary is set to “Read-intent only”,

Blog29_2.PNG

-> Connecting to the secondary Replica JBSERVER3 on database JB1 directly and trying a select query,

Blog29_3

-> It is pretty clear that we are not able to make a connection to database JB1 on Server JBSERVER3 directly. Let us try a connection using ApplicationIntent=ReadOnly and it connects fine,

Blog29_4Blog29_5Blog29_6

-> This advises us that we cannot read the readable secondaries without a ApplicationIntent = ReadOnly.

-> The Readable Secondary is set to “Yes”,

Blog29_7.PNG

-> Connecting to the secondary Replica JBSERVER3 on database JB1 directly and trying a select query. It works fine without any issues,

Blog29_8.PNG

-> In short, Readable Secondary = “Read Intent only” requires ApplicationIntent=ReadOnly to execute a select query on the secondary. Readable Secondary = “Yes” allows us to execute a select query on the seocndary directly.

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.