Clustering - Techyaz.com

SQL Server Error 5184: Cannot use file ‘I:\Path\Techyaz.mdf’ for clustered server

Manvendra Deo Singh — Wed, 29 Aug 2018 12:10:18 +0000

Today, one of my team mate was trying to attach a database on one of the clustered SQL Server instance. He got error 5184 while attaching the database. The details about error 5184 is given below.

Msg 5184, Level 16, State 2, Line 1
Cannot use file ‘I:\Path\Techyaz.mdf’ for clustered server.
Only formatted files on which the cluster resource of the server has a dependency can be used. Either the disk resource containing the file is not present in the cluster group or the cluster resource of the Sql Server does not have a dependency on it.

Msg 1802, Level 16, State 1, Line 1
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

While troubleshooting this error we came to know that the storage or LUN on which we have placed the database files are not added to cluster group. It means disk is not visible in failover cluster manager.

Solution – Error 5184

We performed below steps to fix this issue.

Added the storage on which databases files are placed as shared storage in the failover cluster manager.
Launch SQL Server properties window in Failover Cluster Manager.
Added all newly added disks in Dependencies tab.
Attached the database again.

Here i will explain above steps in detail with screenshots.

We were attaching a database using T-SQL statement on one of the SQL Server cluster instance. While executing the command we get error 5184. Error details are given in below screenshot.

As error suggests that “Either the disk resource containing the file is not present in the cluster group” so I checked cluster group for the disk and found that database files storage was not showing in failover cluster manager.
Next step was to add these storage disks to the cluster group. Launch failover cluster manager. Click at Roles tab from left side pane. You can see SQL Server as role in right side pane. Right click at the SQL Server role and click at “Add Storage” option. You can see this in below screenshot.

Once you will click at “Add Storage” option you will get below window to add the identified disks to cluster group. You can see I have selected all required disks in below screenshot. You can choose your disks where your database files are placed.

Once you click at OK button post selecting all respective check boxes in above step, you will see all your storage disks in failover cluster manager under storage tab.
Now again click at the SQL Server role and then go to “Resources” tab from down side pane where you can see SQL Server and all resources that are aligned for the SQL Server role. Here, right click at SQL Server and click at Properties tab as shown in below screenshot.

Once you get SQL Server properties windows in failover cluster manager, next you should click at dependencies tab. Here, you need to insert one row for each disk system that you have added in above steps. Once you will insert dependencies for all newly added disks then it will look like below screenshot. Now click at OK button to apply this change.

Now again go to SQL Server query window and run the T-SQL command to attach the database. This time you will successfully attach the database to the clustered SQL Server instance.

Let me know if this article helped you to fix your issue. You can follow our facebook page and Twitter handle to get latest updates.

Upgrade or Patch SQL Server Failover Cluster Instance Running with Availability Group

Manvendra Deo Singh — Mon, 04 Jun 2018 14:39:57 +0000

I have explained step by step process to upgrade or patch SQL Server instance that hosts an Always on Availability Group (AOAG) to latest version in attached article. Here, I will explain how to upgrade or patch SQL Server failover cluster instance running with Always on Availability Group. We should plan and execute such upgrades carefully to avoid any risk during execution. The process to upgrade or patch SQL Server cluster instances running with AOAG is quite similar.

NOTE: Always test any solution in Lower life cycle environment before deploying it to Production.

Points to Remember

I have described steps to upgrade or patch SQL Server failover cluster instance having always on availability group. Do not use these steps while upgrading or patching Windows clustering or standalone SQL Server instances running with Always on Availability groups. If you have AOAG configured on standalone SQL Server instances then read attached article.
During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic).
A higher version of a SQL Server instance cannot be added as a new replica to an existing AOAG. For example, a SQL Server 2016 replica cannot be added to an existing SQL Server 2014 AG.
Always first upgrade secondary replica then primary replica because an upgraded primary replica can no longer ship logs to any secondary replica. This may cause data loss as data movement to a secondary replica is suspended.

Planning

We should be very careful while planning upgrade or Patching for your SQL Server Failover cluster instances and if your SQL Server cluster instances are running with availability groups then you need to be more careful considering its complex configuration. Here, i have given multiple steps that you need to plan during patching any AOAG cluster instance.

Make sure you can directly upgrade to the latest version of SQL Server 2017. If you are running with SQL Server 2005, you cannot go directly to SQL Server 2017. You must upgrade SQL Server 2005 to SQL Server 2012, 14 or 2016 before moving to latest version SQL Server 2017.
Identify your databases if they are involved in Change Data Capture or Replication then we need to perform some additional activities. These additional steps are given later in this article.
Run DBCC CHECKDB to make sure there is no corruption on databases hosted on these cluster instances.
You must run Full database backups for all your databases to secure a copy in case anything goes wrong and we need it to restore databases.
Make sure Always on Availability Group is working fine and in Healthy state. Fix the issues and make your AOAG configuration in healthy state before going with the upgrade.
Disable the backup job from the system that is going to upgrade (current secondary replica) and make sure to run it from the server that is online and acting as primary replica at the time upgrade will process. You can also change the Backup Preferences of AOAG to run backups always from primary replica during this upgrade.
No replicas are readable or available for backups during a version upgrade whereas during a non-version upgrade you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.
Choose Upgrade approach. As we know, there are three approaches to perform any SQL Server upgrade. In-place upgrade, Side by side upgrade and Rolling upgrade. We will be using rolling upgrade process to apply patch or upgrade SQL Server cluster instances. This approach is used if your SQL Server Instances are required to upgrade in particular sequence. We use this approach if SQL Server is configured with Always on availability group, Database Mirroring, Log Shipping, Replication, Failover Cluster Instances, SQL Server Reporting Scale-out environment.
Make sure that synchronization state of the failover target is SYNCHRONIZED during any failover of Availability Group.
Develop a rollback plan. Executing this plan will enable you to restore your original environment if you need to rollback.
Plan to test the upgrade on Lower life cycle first before deploying on productions.

Upgrade or Patch SQL Server Failover Cluster Instance running with Availability Group

Here, I will explain how to upgrade or patch SQL Server failover cluster Instance running with Always on Availability group. Let me describe the cluster setup first for this upgrade.

We have four database servers that are hosted in two data centers. Two nodes in each data centers.
All four nodes are part of same windows cluster group. two set of storage have been shared between two nodes to install SQL Server failover cluster.
Two SQL Server Failover Cluster Instances have been installed on these nodes of each data centers. One SQL Server failover cluster instance named FCIA is installed in data center 1 and another SQL Server cluster instance named FCIB is hosted in data center 2.
We have configured Availability Group between these two SQL Server failover cluster instances.
Each SQL Server cluster instance has two nodes. One active and one passive node in their respective data centers. Although active node in data center 2 is not active for connections but this will work as primary in case AOAG failover.
Databases are hosted on shared storage that is connected to their respective nodes in their data centers. You can see this configuration depicted in below image.

Now we have to upgrade or patch this AOAG cluster instance configuration. Keep reading this article to understand step by step process to patch such complex AOAG configuration.

We can see above SQL Server cluster instances have Always on Availability Group so we will follow rolling upgrade process to perform upgrade or patch on these SQL Server cluster instances. The sequence to upgrade SQL Server cluster instances having AOAG configuration is to go from passive to active. We will upgrade the inactive nodes before upgrading the active nodes. Have a look at below step by step process.

First upgrade or patch passive node of SQL Server cluster instance FCIB i.e. Node 4.
Once you will update node 4 of above image configuration then next step is to failover second SQL Server cluster instance FCIB to upgraded instance Node 4 that is hosted in data center 2.
Once you performed failover for cluster instance FCIB to node 4 then next step is to patch node 3 that will be in passive state of this inactive SQL Server cluster instance. You can failback SQL Server cluster instance FCIB to node 3 again post patching. This failback is an optional step and not mandatory. Now you have applied latest patch level or upgraded your SQL Server cluster instance FCIB hosted in two cluster nodes in data center 2. Next, we will follow same process to apply patches in data center 1.
Apply patch on SQL Server cluster node 2 or upgrade SQL Server cluster node installed on node 2 machine as it’s passive node of SQL Server cluster instance FCIA.
Once you have upgraded or patched node 2 in data center 1 next we will failover SQL Server cluster instance FCIA to node 2. Now node 2 will run active instance of SQL Server cluster setup. But If you have enabled change data capture feature or replication configured on your SQL Server cluster instance then you should run few additional steps as described here. Once you upgraded or patched all secondary replicas then fail over the Availability Group to an upgraded instance. Now run below command on your primary replica.

EXECUTE [master].[sys].[sp_vupgrade_replication];

Go ahead after execution of above command and upgrade or patch SQL Server cluster instance that was originally the primary replica i.e. Node 1

Now, patch SQL Server cluster instance that is hosted on node 1 and was original primary replica that is now acting as passive in this cluster setup. Once done you can failback SQL Server cluster instance FCIA to again node 1 as active node. Here, you have patched or upgraded all SQL Server cluster instances hosted on these four nodes.

Here, I have described how to upgrade or patch SQL Server failover cluster instance that is running with Always on Availability Group. I hope you like this article. Please follow 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.

Why is Secondary Replica Showing in Resolving state after AOAG Automatic failover?

Manvendra Deo Singh — Wed, 02 Aug 2017 15:29:46 +0000

Sometimes AOAG configuration stuck in resolving state and its secondary Replica does not come online. When you check the Alwayson Availability Group configuration, you find it showing in resolving state after Automatic failover of AOAG Configuration. Let us get the reason behind secondary replica stuck in resolving state and solution to overcome such issues in future.

SQL Server AlwaysOn Availability Group

SQL Server AlwaysOn Availability Group is an advanced version of database mirroring and introduced in SQL Server 2012. AOAG is HA & DR solution for SQL Server databases. We can group a bunch of databases as one Availability Group and failover/failback as one entity whereas it was not possible in database mirroring. Database Mirroring can be configured only for single database at a time. You can visit the attached link to learn more about AlwaysOn Basics.

I have also an AOAG configuration in my environment which is set for Automatic failover between both replicas. Last week, we faced an issue during automatic failover. Secondary replica was not transitioning as primary replica during an automatic failover and it was stuck in “Resolving” state. It was full down time for application because primary replica was lost and availability databases were not coming online on secondary replica.

I will explain step by step method to make you understand the issue and the fix.

Automatic Failover Not Working and Secondary Replica Stuck in Resolving State

As secondary replica is not transitioning as primary replica after failover because secondary replica hung in resolving state so here, we will check the main root cause and its fix so that secondary replica comes online after every failover. Let’s check the current configuration of this AOAG. Run below command to get the AOAG details. We can see the configuration is running into automatic failover mode.

SELECT replica_server_name, availability_mode, availability_mode_desc, failover_mode, failover_mode_desc
FROM sys.availability_replicas

Now connect to secondary replica in SQL Server Management Studio. Expand the AlwaysOn High Availability folder followed by Availability Group folder. Here, you can see the current state of this availability group which is showing in Resolving state.

I checked the SQL Server error log file but i did not get enough information about this issue to proceed. I searched about this issue and got few suggestions on web that i should check the cluster log. I checked failover cluster manager for critical events. I got below event in failover cluster manager.

Clustered role 'AG_***' has exceeded its failover threshold. It has exhausted the configured number of failover attempts within the failover period of time allotted to it and will be left in a failed state.
No additional attempts will be made to bring the role online or fail it over to another node in the cluster.
Please check the events associated with the failure. After the issues causing the failure are resolved the role can be brought online manually or the cluster may attempt to bring it online again after the restart delay period.

Fix Resolving state and Make Secondary Replica Primary

Above issue clearly indicates about some cluster configuration related to role created for AOAG. As we can see, there is one role is showing under roles tab of this cluster group in below image. We can see the current owner of this role is still showing as node 1.

Now right click on this role and choose properties as per below image.

You will get a properties window as shown in below screenshot. Now click on “Failover” tab of this screen to check the failover threshold details.

We can see the failover threshold is set to only 1 in the 6 hours. It means if any failover happen more than once in the 6 hrs time period it will remain in failed state and will not try to come online. Now increase this value as per your need. I have changed it to 10. Click on apply and Ok button.

Now, secondary replica of availability databases will not come online automatically. We need to bring them online. We have multiple options to bring them online from resolving state. You can directly run the failover by right click on availability group in SSMS and then proceed with failover.

Another option is to bring them online from failover cluster manager. You can either right click on the AOAG role and click on “Bring Online…” option or you can failover it to best possible node. As primary replica is down and not accessible so it will be failed over to the secondary replica only because this node is only available this time. Let’s right click on AOAG role in failover cluster manager, choose move and then click on “Best Possible Node”

It will process and come online within few seconds and this time you can see this role is online from node 2 as current owner is showing as node 2 now.

We can also validate this change while making a database connection to the secondary replica in SSMS. Connect to secondary replica and expand the AlwaysOn Availability Group folders. You can see now availability group is showing as primary. That means your database is online from secondary replica to accept the user connections.

You can also test this exercise to make sure automatic failover is working fine or not to prevent this kind of future outages. Once your earlier primary replica comes online, you shutdown SQL Server services on secondary replica/current primary replica. Once it will go down, your current secondary replica becomes primary automatically. Before shutdown SQL Server services, make sure databases should be fully synchronized.

Hee, we have fixed Alwayson issue where secondary replica is not coming online after failover and hung in resolving state. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.