I'm configuring a failover in an above-mentioned setup with two nodes and synchronous commit. It's a test setup. Primary is server1 and secondary is server2. I configured the availability group and added the database.
When I manually execute a failover it seems to work, server2 becomes primary, but when I connect to cluster resource IP, the database remains in a read-only mode. It works only when I shutdown server1. So far I couldn't find any solution.
Related
We are building a two-node SQL Availability Group with SQL Server 2016 SP3.
Steps taken:
1.) Build two VMs in Azure in the same region, but different Zones
2.) Install Windows Failover Cluster on both nodes
3.) Install SQL Server 2016 SP3 on each node
4.) Create a failover cluster with each node and a cloud witness
5.) Enable the failover cluster on the SQL engine service
6.) Create an availability group and add both nodes and a database
7.) Add a listener to the availability group
At this point, we can connect to the listener name if we try from the primary node with SSMS. The DNS entry has been created and assigned the IP address given to the listener.
If I go to node2 and try and connect to the listener name, I get a connection timeout. If I nslookup the correct IP is given.
When I failover from node1 to node2 the connection to the listener stops working on node1 and starts working on node 2.
We have moved node 2 to a separate subnet and still see the same behavior.
I know there are some intricacies with Azure VMs and failover clustering communications, but we have tried the things we have found concerning this.
The only thing we have been hesitant to do is the standard load balancer.
Does anyone have a direction we can look at next?
on one of my environment automatic failover does not work. what things i need to check, please help me on this?
https://support.microsoft.com/en-us/help/2833707/troubleshooting-automatic-failover-problems-in-sql-server-2012-alwayson-environments
The symptoms when automatic failover is unsuccessful
If an automatic failover event is not successful, the secondary
replica does not successfully transition to the primary role.
Therefore, the availability replica will report that this replica is
in Resolving status. Additionally, the availability databases report
that they are in Not Synchronizing status, and applications cannot
access these databases.
For example, in the following image, SQL Server Management Studio
reports that the secondary replica is in Resolving status because the
automatic failover process was unable to transition the secondary
replica into the primary role:
My project supports nested transactions and thus we have MSDTC service running on web server as well as on database server. The project is working fine. However, we have database mirroring established over database server and thus whenever fail-over happens, site page where, nested transactions are used, throws an error:
The operation is not valid for the state of the transaction.
We have MSTDC service running on mirroring database too. Please suggest what should be done to overcome this problem.
In the default DTC setup it is the DTC of the server that initiates the transactions (the web server in your case) that coordinates them. When the first database server goes down, it rollbacks its current transaction and notifies the transaction coordinator of this and that is why you get the error. The webserver cannot commit the transaction because at least one participant has voted for a rollback.
I don't think you can get around that. What your webserver should do is retry the complete transaction. Database calls would than be handled by the mirror server and would succeed.
That is at least my opinion. I'm no authority on distributed transactions, nor on database clusters with automatic failover...
I have a setup of master-slave SVN servers.
Master and two Slave server are set up in three different location of three different timezone. We cannot let the slave server up for 24 hrs, so slave servers need to be shut down at the end of each day. But at the same time developers are committing changes from another slave to master server. Master server is up forever.
So my situation is at the starting of the day each slave server needs to synchronized with master which can only done from master by svnsync command.
Is there any way to automatically synchronize slave server when it starts up?
We are using apache server to host subversion. OS are windows server 2008 R2.
Thanks
If using svnsync on your slave server in a boot time script is not possible, you can do something like the solution described in this blog post.
To sum it up, then have a dedicated server listening on the master server (written in Python) that will start svnsync upon reception of a special TCP packet.
On your slave, you can then use the Windows version of netcat like described in the blog post to trigger the sync.
Hi I have a application that is deploy on two weblogic app servers
recently we have issue that for certain cases the user session returned is null. Developer feedback is that it could be caused by the session not replicating to the other server.
How do we prove if this is really the case?
Are you using a single session store that both application servers can access via some communication protocol? If not, then it is definitely the case. Think about it, if your weblogic servers are storing the session in memory anywhere, and having users pass their session id via cookies, than the other server has no way of accessing the memory on the other machine. Unless you are using sticky load balancing. Are you?
There's 2 concepts to consider here - Session stickiness and session replication.
Session Stickiness is a mechanism where weblogic server ensures that if a request from a user with session A goes to server 1 then the next request from user with session A will go to server 1 only.
This is achieved by configuring a hardware loadbalancer (like F5) which is capable of providing session stickiness. or configuring weblogic proxy installed on apache/iis/weblogic.
The first time a request reached WLS managed server, it responds with a session id and appends to it the JVM id of the server (this is the primary id), if the managed server is part of a cluster, it also attaches a secondary server jvm id (the secondary server is the server where the session is being replicated)
The proxy maintains a table of all JVM id's and corresponding IP of managed server, it also checks periodically if the servers are up and running or not.
The next time when another request passes the proxy with existing session id and a primary jvm id, the proxy parses this and tries to send the request to that server, if it cannot within some time it tries to send to secondary server.
Session Replication - This is enabled by default when you configure a WLS cluster with 2 or more managed server. Each time any data is updates to a session, its data is replication in a secondary server too.
So in your case if your application users are loosing session or getting redirected to login page between normal usage, then check that the session did not get invalidated because of a timeout, if you have defined a cluster and using WLS proxy then check the proxy debug output to make sure the primary and secondary server are being appended to the session id.
Finally there's a simple example in the sample application deployment of wls that you can use to test session replication and failover functionality.
So to prove why session is getting lost,
1) check server log to see if session got invalidated because of timeout,
2) if using wlproxy, enable debug, and the next time the issue happens check in the proxy log if the request was sent to a different server, and if that server is not the secondary server.