I am working on a project that requires a reconfigurement of the current Failover Cluster settings. The project itself requires the availability of a report server as well as the login by use of a windows authenticated account.
The current situation is: Server runs perfect while on the first node, but whenever a failover occurs, and the cluster switches over to the second node, there is an issue with gaining access to the report server. When the cluster is running on the second node, on SSMS the availability group shows that the cluster is in (Secondary) position, while the replicas themselves are as follows: Node1 (secondary), role: Secondary; node2: [blank], role: Unknown.
This also brings up an error saying having issues logging into to the report server from node2.
If anyone knows of anyway, or settings to be changed, I would be greatly appreciative.
Thank you!
Related
I am having a strange issue and am hoping you guys might be able to help!
Problem: I have a 2 node SQL Server 2019 Availability Group Cluster utilising a FSW. Both nodes are using the same DBEngine Service account. and it's been working fine for quite some time.
Today I restarted the passive node DBEngine account . When the node came back up, it was no longer synchronising with node 1. The state of the replica was disconnected, and I could see lots of login failures on Node 1 (active node) SQL Logs.
I found that the DBEngine service account had locked. I had it unlocked, but it soon locked again.
Has anyone got any ideas? Any input would be greatly received!
Steps I tried:
created a new service account to rule out the account being used elsewhere, started both nodes under the new account.... account locked out when node 2 started
unlocked the account, stopped node 2. restarted node 1. Account fine... waited.. account still fine. Started node 2 service... account locked out.
recreated mirroring endpoints on both nodes and reapplied connect permissions to the dbengine service account. - this didn't fix it.
restarted both Servers.
removed the node 2 replica from the availability group, removed all databases (from node 2) and dropped the mirroring endpoint on node 2. restarted node 2 service. - at this point both nodes were happily running under the same service account.
tried re-adding node 2 as a replica using the wizard. It added it, backed up the database, restored to node 2, and got to the very last step where it connects it, and the password locked out again!
The account gets locked if someone is using wrong password.
You can check task scheduler if any task using service account.
If application uses same service account. It could be due to caching of old credentials.
I am new to fail-over clustering, I have a two node Windows fail-over cluster (windows server 2016) with SQL Server 2016 Installed in cluster mode which configured successfully and everything is working fine. I needed to configure an Always-On Availability to a DR site, but ended up in error while adding the third node.
I have uninstalled Antivirus,checked for duplicate name in the AD of which there are non and it didn't fix my problem.
Cluster service on node xxxxxxxx did not reach the running state. The error code is 0x5b4. For more information check the cluster log and the system event log from node xxxxxx. This operation returned because the timeout period expired.
Operation failed, attempting cleanup.
The server 'xxxxxx.xxx.net' could not be added to the cluster. An error occurred while adding node 'xxxxxx.xxxx.net' to cluster 'xxxxxx'.
This operation returned because the timeout period expired
From the event viewer in failover cluster manager it says xxxxx has been evicted from the cluster.
You should first run following PowerShell command
Clear-ClusterNode -Name nodeName -Force
After running this command try to add node back to the cluster
Have You tried to add third server from Failover Cluster Manager (FCM) i.e. have you spinned the Role/Server from FCM or from Hyper V manager. Please try to spin Vm from FCM
We have two nodes availability group. The two nodes being SQL cluster1- node1 and SQL cluster 2- node2 and a Availability group listener. The Java application is connecting to this listener and all is working fine initially i.e application is able to perform both read/writes on the database, untill we do a failover.
The connector string is driverURL=jdbc:jtds:sqlserver://[Listerner DNS Name]:[Port]/[Database]
Say initially the node1 was primary and node2 was the secondary.
After failover, node1 becomes secondary and node2 becomes primary. Now the application is still able to connect to the database but only able to perform reads on the database. The application throws exceptions (which is mentioned in the title) if we try to do inserts on that DB.
Basically what I need is for the application to be able to perform read/writes all the time irrespective of which node is the primary. Any ideas ?
There should be no reason why you get a read-only database when the connection string is pointing to the listener. That's the point of the avail grp listener - to direct flow to the read/write (primary) database. Ping the DNS name and check that it resolves to the listener (before and after an AG failover). Unfortunatelyy I don't use Java so can't help you any further. Cheers, Mark.
Adding node fails Windows Server 2012 Failover Cluster for AlwaysOn Availability Groups in all AZURE, is leaving an apparent phantom VM node. How can I cleanup up?
Server property for target server VM is flagged as "clustered", but is not. There was another node added successfully, but when trying again to add the node , that failed earlier, does not work, as cluster manager reports back that target "xxxxx server is already clustered".
I evicted the the single node, then "destroyed cluster". Then created anewly named cluster. Added one node, but when trying to add the "problem" sql server VM, I get same return msg : "server is already in a cluster". When I remote into the target sql Azure VM, server manager shows the server as "Clustered". I can not find any way to clean this failed operation up.
When I open FO cluster mgr on the SQL VM, I see red-x'ed the cluster name of the cluster I had previously "destroyed". Same VNET, same subnet. Validates OK on cluster build up to point of failure when trying a add 2nd SQL VM node to cluster.
No solution was found after rambling thru msdn, technet. Had to delete azure vm,s completely, but note that in the
same cloud viewed thru ms new portal, parts still are displayed in those pages. Like Loose random balloons drifting around azure chaos...
I'm trying to set up mirroring between two sql 2008 databases on different servers in my internal network, as a test run before doing the same thing with two live servers in different locations.
When I actually try and switch the mirroring on the target DB (with
ALTER DATABASE testdb SET PARTNER = N'TCP://myNetworkAddress:5022') I'm getting an error telling me that the server network address can not be reached or does not exist. A little research suggests this is a fairly unhelpful message that pops up due to a number of possible causes, some of which are not directly related to the server existing or otherwise.
So far I've checked and tried the following to solve this problem:
On the target server, I've verified that in SQL Configuration Manager that "Protocols for SQLEXPRESS" (my local installation is labelled SQLEXPRESS for some reason, even though querying SERVERPROPERTY('Edition') reveals that it's 64-bit Enterprise), and Client Protocols for SQL Native Client 10 all have TCP/IP enabled
I'm using a utility program called CurrPorts to verify that there is a TCP/IP port with the same number specified by the mirroring setup (5022) is open and listening on my machine. Netstat verifies that both machines are listening on this port.
I've run SELECT type_desc, port FROM sys.tcp_endpoints; and
SELECT state_desc, role FROM sys.database_mirroring_endpoints to ensure that everything is set up as it should be. The only thing that confused me was the "role" returns 1 .. not entirely sure what that means.
I've tried to prepare the DB correctly. I've taken backups of the database and the log file from the master DB and restored them on the target database with NORESTORE. I've tried turning mirroring on both while leaving them in the NORESTORE state and running an empty RESTORE ... neither seems to make much difference. Just as a test I also tried to mirror an inactive, nearly empty database that I created but that didn't work either.
I've verified that neither server is behind a firewall (they're both on the same network, although on different machines)
I've no idea where to turn next. I've seen these two troubleshooting help pages:
http://msdn.microsoft.com/en-us/library/ms189127.aspx
http://msdn.microsoft.com/en-us/library/aa337361.aspx
And as far as I can tell I've run through all the points to no avail.
One other thing I'm unsure of is the service accounts box in the wizard. For both databases I've been putting in our high-level access account name which should have full admin permissions on the database - I assumed this was the right thing to do.
I'm not sure where to turn next to try and troubleshoot this problem. Suggestions gratefully received.
Cheers,
Matt
I think that SQL Express can only act as a witness server with this SQL feature, you might get better mileage on ServerFault though.
Mike.
Your network settings might be OK. We got quite non-informative error messages in MS SQL - the problem might be an authorization issue and the server still will be saying "network address can not be reached".
By the way, how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.