0

This has been happening in both the replicas (secondaries) at the same time ....Nothing shows on the primary replica.

Error: 976, Severity: 14, State: 1.

The target database is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access.

To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group.

For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online

Any ideas on where to start or what might be the problem?

  • What do the ERRORLOGs on these secondary servers show prior to this occurring? – John Eisbrener Oct 25 '17 at 13:28
  • Is this SQL Server 2012? – Sean Gallardy Oct 25 '17 at 13:35
  • Its a sql 2012 . I also get the 35206 connection timeout errors randomly on the primary but that sometimes happens when the 976 error happens and sometimes dont. There is no related logs prior to the error 976 – SqlNovice Oct 25 '17 at 17:16
3

You are attempting to connect to databases on secondary replicas when the availabilty group replica is not configured to allow connections on anything other than the primary replica.

The following script will tell you the state of the secondary replicas, and whether they will accept read connections:

SELECT ag.name,
       replica_server_name,
       secondary_role_allow_connections_desc
FROM sys.availability_replicas ar
    JOIN sys.availability_groups ag
        ON ag.group_id = ar.group_id;

The result of each replica with be:

  • NO - no connections allowed to the database (default behavior)
  • READ_ONLY - connections allowed when the ReadIntent flag is passed in a connection string
  • ALL - all connections to the databases are permitted.

To change the setting for a replica you can either use the GUI, or a script:

ALTER AVAILABILITY GROUP [AGName]
MODIFY REPLICA ON 'ReplicaName'
WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = 'TCP://ReplicaName:Port'))

For more details see the Microsoft documentation.

  • Thank you for your reply. Both of the secondaries are not read only. Do you think its a network issue (connection timeout) or a user trying to connect to the secondaries. If it was a user trying to connect then why am i getting the errors on both the servers at the same time , definitely the user wont try to connect to both at the same time. – SqlNovice Oct 25 '17 at 17:12
  • If you have setup read-routing on your primary, and the user is passing along the connection string with the ApplicationIntent=ReadOnly option then they could be hitting servers and getting that error. In particular if the users login has a default database of one that resides in the AG. – Nic Oct 25 '17 at 17:15
  • Our AG has only one database . – SqlNovice Oct 25 '17 at 17:45
  • Is there any way I can check the connection string whether that is read only or not as my secondary is not read only – SqlNovice Oct 25 '17 at 18:03
  • @farhanchy FYI It can also happen in 2012 if the replica becomes disconnected for any reason. This behavior was changed in 2014. – Sean Gallardy Oct 25 '17 at 18:14
0

I'm having the same issue. It is due to scheduled transaction log backups. These have been setup using standard SQL maintenance plans. I have it configured to take the backup on the primary only. The SQL generated by the transaction log backup subtask contains the logic to prevent the backup from taking place on the secondary and it works HOWEVER, these connection errors are still logged in SQL on the secondaries which saturates the SQL log...

  • I ended up implementing Ola Hallengren's backups. The defaults work great for AG setups. No more maintenance plan related errors... – SQLBBQMan Oct 11 '18 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.