SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error
We got this Microsoft SQL Server error 35250 while configuring Alwayson Availability Group on one of the SQL Server Instance. There could be multiple reasons behind this SQL error 35250. You can find multiple solutions to fix this issue based on the nature of the issue. Here I will show you, how to fix this Alwayson error 35250 that came due to SQL Server service accounts.
Microsoft SQL Server Error 35250
We generally get this error whenever there is a communication issue between endpoints of both replicas or any replica unable to connect to the endpoints cause this error to generate. You will see below error texts if you are getting this issue.
Alwayson Error 35250
Failed to Join the database ‘DBName’ to the availability group ‘AOAG-Name’ on the availability replica ‘Availability Replica Name’
There are many reasons behind this error that we will discuss in next section. You might also get below text if you are using T-SQL.
The connection to the primary replica is not active. The command cannot be processed. (microsoft sql server, error: 35250)
Below is the screenshot of this error.
You should check below points based on attached article MSDN link whenever you get this error.
- Inbound Port 5022 Traffic is Blocked
- Endpoint is not created or started
- Endpoint permissions
- SQL Server is not listening on port 5022
But if everything is ok and you are still not able to diagnose this issue, then you should keep reading this article.
I checked everything and all was well on both replicas. As we know that there should be Grant CONNECT permission on Always On endpoint. I was reassigning GRANT CONNECT on the endpoint and came to know that the SQL Server service account was not added to the SQL Server instance of secondary replica. That is why we faced this error. Let’s first get the endpoint and then we will run Grant connect on endpoint to see the issue. Run below command to get the name of endpoint that is using in this alwayson configuration.
We can see endpoint name is hadr_endpoint. Now run below command to grant connect permission on endpoint hadr_endpoint. The login name is the service account that is used to run SQL Server services.
You can see, error is saying that the account doesn’t exist on SQL Server.
Although you can directly check this step in SSMS as a prerequisite once error is reported. The SQL Server service accounts should be added to SQL Server Instances. I checked this account on both replica and found that it was very much there on primary replica but it was not created on secondary replica. That was the missing point which caused this issue.
Now create this service account on secondary replica as well or where it was missing on any of the replica then you can try to re-add the database to the AOAG configuration. This time your database will be added to the AOAG configuration. If you are facing issue during joining database to the AOAG configuration then you can remove the existing AOAG and reconfigure it.
Your issue will be fixed if you check and follow all above suggested points including the one mentioned in MSDN link. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.
- Fix AOAG Error 976:Cannot Connect to Secondary Replica
- How to fix AOAG Listener Issue 19471: The handle is Invalid
- Fix Listener Issue that came during AOAG Configuration
- How to fix Error 15141: The Server Principal owns one or more endpoints
- Fixing Application connectivity Issue after AOAG automatic failover
- How to Fix SQL Error 1005: A Comprehensive Guide - April 9, 2023
- How to Fix SQL Server Error 207 – Invalid Column Name - April 9, 2023
- How to Fix SQL Error 1045: Resolving Access Denied Issues - April 8, 2023