Database Mirroring - Techyaz.com

Fix Error 1418: The server network address cannot be reached or does not exist.

Manvendra Deo Singh — Tue, 27 Mar 2018 16:53:07 +0000

We got error 1418 while configuring Database Mirroring on one of the SQL Server database instance. The error details are given below:

The server network address “TCP://ServerName.abc.local:5022″ cannot be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational. (Microsoft SQL Server, Error: 1418)

Reason behind Error 1418

Main reason behind database mirroring error 1418 is because the specified server network address cannot be reached or does not exist. The server network address cannot be reached because of multiple reasons. Some of them are given below.

Principal, Mirror and Witness servers are not talking to each other.
Wrong network address name, mirror server instance name or port number.
Mirror database is not ready for mirroring.
Principal or mirror server instance is behind a firewall.
You are using local system account to run SQL Server services and not using certificates for authentication.
SQL Server services are running with different domain accounts on Principal and Mirror server and service accounts don’t have enough permission on endpoints.
Different endpoint encryption value set on Principal, Mirror and Witness server.
Endpoints are not started on the partner servers.
Principal server instance is not listening on the port assigned to its database mirroring endpoint.

We need to verify each option mentioned above carefully to fix this error.

Solution

The solution of this issue may vary case to case depending on the nature of issue. To fix this issue we need to find out the main root cause behind error 1418. The root cause may be anything that is given in above section. Here I will describe each probable reason given above and its solution to fix this issue. Make sure to go through with each point given in this article.

Principal, Mirror and Witness Servers Should be Accessible

Make sure that SQL Server Instances installed on Principal, Mirror & Witness servers are accessible to each other. If remote login for any SQL Server instance is not enabled then you might get this issue. You can enable remote connectivity by enabling TCP/IP and Named Pipes protocols in SQL Server Configuration Manager. Each system must access the ports of the other SQL Server instances over TCP. You can try telnet the SQL Server ports of other partners.

Verify Correct System Details

Sometimes we entered wrong details that end up with throwing errors. Make sure to verify the network address name, mirror server instance name and its port numbers are correct. You can recheck all the details whether you have entered them correctly or not.

Mirror Database Preparation

Verify that the mirror database is ready for database mirroring. We should prepare mirror database before configuring or during configuring database mirroring. It is suggested to keep identical drive path for mirror database files. Below are the steps you should take care for preparing your mirroring database.

Run full backup and subsequent transactional log backup of the Principal database and copy it to the Mirror server.
Restore database with same name in norecovery state on Mirror server with the copied backup files from above step. You must ensure that restored database on mirror server should be in restoring mode before starting database mirroring configuration.

Firewall/Ports

One of the probable reason to get error 1418 is partner servers are behind firewall. Make sure that the principal server instance and destination mirror server instance is not behind a firewall and they should talk to each other. Principal server, Mirror server and witness server should be accessible to each other.

Verify that SQL Server port and endpoint ports are enabled and accessible via telnet. If not or you are not able to telnet any of the partner instance from any server participating in mirroring then you should ask your network admins to open these ports to establish the connectivity over given port.

Endpoints

Make sure that endpoint has been created on principal, mirror and witness servers. Verify that the endpoints are started on each partner server instances. You can check endpoint status by running below T-SQL query on each instance.

SELECT state_desc FROM sys.database_mirroring_endpoints

If either endpoint is not started, execute below ALTER ENDPOINT statement to start it.

#Change the name of your endpoints. Here endpoint name is Mirroring
ALTER ENDPOINT Mirroring
STATE = STARTED
AS TCP (LISTENER_PORT = )
FOR database_mirroring (ROLE = ALL);
GO

Recheck that the principal server instance is listening on the port assigned to its database mirroring endpoint and the mirror server instance is listening on its port. If a partner is not listening on its assigned port, modify the database mirroring endpoint to listen on a different port.

Sometimes this issue got fixed by dropping the existing endpoint and recreate it again on partner servers.

Service Accounts

Do not use local system account to run SQL Server services. If you don’t have any choice and want to use local system then ensure to use certificates for authentications.

Make sure that service accounts that you are using to run SQL Server services must have CONNECT permission to mirroring endpoints. Also, if you are configuring database mirroring between two domains then the login of one account must be created in master database on the other computer, and that login must be granted CONNECT permissions on the endpoint.

It’s always advisable to use same service accounts to run SQL Server services on all three Instances on Principal, Mirror and Witness server.

You can comment us your experience about fixing this issue. We will update this article with your solution that you have used to fix this issue.

I hope you like this article. Please follow us on our Facebook page and Twitter handle to get latest updates.

Fix AOAG Listener Error 19471: Kerberos Status is Showing The handle is Invalid

Manvendra Deo Singh — Thu, 28 Sep 2017 13:44:47 +0000

I was configuring AlwaysOn Availability Group between two replicas. Everything was configured successfully but Listener was failed to create with an error 19471. I have already explained how to fix listener error 19471 in attached article but this has not helped me. Here i will explain another aspect of this error along with their fix.

AlwaysOn Listener Error 19471

When i checked the AlwaysOn High Availability folder in SSMS on any of the replica, everything was working fine. AOAG was configured successfully and working fine but listener was not configured due to below listener error 19471. You can see this in below screenshot.

Create failed for Availability Group Listener ‘Listener-Name’. (Error: 19471)

I tried creating Listener name using “Add Listener…” wizard in SSMS but failed with same error. I observed root cause of this issue during following steps given in my last article that i have attached in first paragraph. Make sure to clear all entries from DNS for your listener Name and IP, if there is any.

Kerberos Status: The handle is Invalid

First we will create a Client Access Point(CAP) in FCM for this listener name to check the status of NetBIOS, DNS & Kerberos that will help us to go deeper inside the issue.

Launch Failover Cluster Manager and click on Roles tab from left side pane. Here you can see your availability group role in right side pane.
Right click on this role and select “Add Resources” then “Client Access Point“.
Enter the Listener name and its IP address and click on Next button to proceed.
Click on Finish button of final screen to create the Listener Client Access Point in FCM.
Once CAP will be created in FCM, it will be in Offline state. Right click on listener CAP and click on “Bring Online” to bring it online. You can see Listener IP comes online but Listener name still shows in offline state.

Now double click on listener client access point or right click on it and choose properties. You will get CAP property window as shown in below image.

You can see, this time issue is with Kerberos status that is showing as “The handle is invalid“. Earlier DNS status was not ok in last article.

Fix Kerberos Status The handle is invalid

When i look into Active Directory server, i found that listener name object was showing as disabled as shown in below image.

I decided to enable it and then to create listener. Right click on listener name object on AD that are showing in disable mode with down arrow and click on “Enable Account” button as per below image.

You can see, listener name account is enabled and down arrow that are showing during disabled mode is not showing now.

Once you enabled the listener name object in AD, bring your listener CAP online in FCM. Right click on listener client access point and click on bring online. You can see listener CAP is showing online now.

When you will launch its property window, you will see the status of NetBIOS, DNS and Kerberos are showing OK now. Close this property window to proceed.

Now we will follow same process that we have followed in my last article. We will remove this listener CAP from FCM and then add listener in AOAG in SSMS. Right click on CAP in FCM and click on Remove button to delete it.

Once CAP will be removed, launch the SSMS and connect to your Primary Replica. Expand AlwaysOn High Availability folder followed by Availability Group. Now you can right click on Availability Group Listeners and click on Add Listener option. You will get below window to configure it.

Enter the listener name, port and then add its IP. Once you entered all details, click on OK button to create the listener. This time, listener will be created on all replicas. You can see i have just created listener for my alwayson availability group that are showing in below image for both replicas.

Related Articles:

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix AOAG Listener Error 19471: Kerberos Status is Showing The handle is Invalid appeared first on Techyaz.com.

Fix SQL Server Error 976: Cannot connect to Secondary Replica of AlwaysON Availability Group

Manvendra Deo Singh — Wed, 13 Sep 2017 10:00:51 +0000

Today an application user has reported that he is not able to connect to the secondary replica of AlwaysOn Availability Group configuration. The details about error Microsoft SQL Server 976 that he was getting is given below.

Cannot connect to ‘Secondary Replica Server’.
ADDITIONAL INFORMATION:
The target database, ‘SDGC’, 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. (Microsoft SQL Server, Error: 976)

The screenshot of this error is given below.

Solution

Before going ahead let me give you a background about SQL Server configurations.

We have two SQL Servers Server A & Server B and there is an user database SDGC is hosted on both SQL Server Instances.
AOAG is configured between both servers in Automatic failover mode for database SDGC.
Availability database SDGC hosted on instance B is inaccessible because it was restored in no recovery mode and not set in read only mode for AOAG configuration.
User’s login was created on both SQL Server instances with having default database as SDGC that are participating in AOAG.

Now, the problem is whenever user tries to connect to the secondary replica whether AOAG is active from instance A or instance B, he is not able to connect to the SQL Server Instance and getting given SQL Server error 976. I analyzed this issue and found two solutions to fix this issue:

Change Connect to database value in SSMS while establishing the connection.
Change default database value of your Login in Login Property window.

Change Connect to database value in SSMS

Launch SQL Server Management Studio. Click on Options tab of connection details window in SSMS as shown in below image.

You can see, Connect to database value showing as default that means it is connecting to the database that is set as default database for user’s login. Remember, default database for user’s login is set as SDGC that is running in norecovery mode.

Now, we just need to change the connect to database value from default to master or some other database. As default database for user’s login was set to SDGC, so change it master to make database engine to read an accessible database.

Once you make changes, hit the connect button and establish a database connection. This time you will be able to establish database connection to secondary replica.

Change default database value of your Login

If default database of your login is not mandatory to set to availability database then you can change it to master and remove this issue permanently. Otherwise, you need to change default database every time you make a connection to secondary replica as discussed in above section.
You can connect to your secondary replica or to the server where you are facing this issue using different admin or security admin account. If you have such account and password, you don’t need to logoff and relogin. You can just right click on SSMS icon while pressing SHIFT button to logged in using different user to the SQL Server instance. You can see that option in below image.

Click on “Run as different user” option. It will display below login screen to enter your new login and password. Enter the credentials.

Once your new account will be authenticated, SSMS will be launched and show you the details as shown in below image. Click on Connect button to establish the connection.

Expand Security folder. Identify your login for which you have to change the default database setting. Right click and choose properties on this login to launch properties window. You can double click on this login as well to launch this properties window. Below window will come to your screen where you can see the default database set for this login.

You can see default database is set as SDGC in above screenshot. Now we need to change it to master or any accessible database. Do the changes, you can see i have changed it to master in our screenshot. Once you make changes, click on Ok button to proceed.

NOTE: If you need to change default database back to availability database due to some application dependencies then you need to first make your availability database accessible. You can perform failover to make secondary replica as primary then you can make changes and then you can failback. If you don’t want to perform failover/failback, then you can do this by changing the availability database from norecovery to read only mode.

Now your issue is fixed. You would be able to connect to the SQL Server Instance that are running as secondary replica in AOAG configuration. You can see, i have connected to secondary replica using same account with whom i was facing issue.

Related Articles:

Please comment us to give your feedback. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 976: Cannot connect to Secondary Replica of AlwaysON Availability Group appeared first on Techyaz.com.