I have a master/slave mysql (mariadb) setup for replication. Is it possible to let an existing database connection fallback to master when it's available again after a failover to slave has happened? I'm using Glassfish connection pools and have tried with different properties with no effect, eg. secondsBeforeRetryMaster. My URL is: jdbc:mysql:sequential://master,slave/db
I'm following
mysql connector
It works when new connections are created, but for existing ones, fallback does not happen at all. Since I'm reusing existing connections a lot, I'm kind of lost. The secondary server is read-only, so all writes to database fail after a failover.
Related
I have a client that uses MS SQL with availability groups. I develop a java based software and connect to the server in the following fasion: jdbc:sqlserver://[serverName[:portNumber]]
Everytime the DBA does a update on the servers, we loose the connection to the server (We get a Connection Closed). According to the DBA this is normal behavior in SQL-Servers and our software should just do a retry.
Is it really normal that the sql server closes all connections in a failover situation? Shouldn't it just redirect all connections to the new instance?
Unfortunately I am no SQL-expert and the DBA is anything but helpful, he just claims that our software should simple reconnect after receiving a closed connection. Am I missing something or is this really the desired experience in sql server?
Is it really normal that the sql server closes all connections in a failover situation? Shouldn't it just redirect all connections to the new instance?
Yes. On the assumption that the Availability Group (hereafter abbreviated "AG") is built on top of Windows Failover Clusters†, the AG listener is brought offline, transferred to new owner of the AG, and brought back online. Moreover, the databases in the AG on both the primary and all secondary replicas are transitioned from online → recovery pending → back online in their new (perhaps same as old) capacity as read/write or read-only.
Either of these phenomena alone would cause your application to lose communication with a database that it had previously established a connection with. But also, two of the fallacies of distributed computing are:
The network is reliable.
Topology doesn't change.
Regardless of the reason for those assumptions being violated, if your application isn't resilient to them, there's going to be a problem.
† - while it's technically possible to build an AG without Windows Clustering (i.e. a basic AG or if the AG is on Linux and is using Pacemaker as the coordinator), I think that the majority of implementations do use Windows Clustering.
I want a solution that match the below scenario:
We have 2 databases with 1 being the main DB and the other being the secondary DB. I want a process (executable, powershell, anything...) that can update the changes that I make in Stored Procedures in the main DB. the main DB is the database that we will make the changes then I want a process that update (simple delete and create) the older SP in the secondary DB.
How I can make this possible in the most simply way? If you will say software to work with please take in account that I only want freeware.
It seemed like you are defining something called Mirroring if I didn't assume wrong.
Database mirroring maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. Typically, these server instances reside on computers in different locations. Starting database mirroring on a database, initiates a relationship, known as a database mirroring session, between these server instances.
One server instance serves the database to clients (the principal server). The other instance acts as a hot or warm standby server (the mirror server), depending on the configuration and state of the mirroring session. When a database mirroring session is synchronized, database mirroring provides a hot standby server that supports rapid failover without a loss of data from committed transactions. When the session is not synchronized, the mirror server is typically available as a warm standby server (with possible data loss).
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017
Hope it helps
I have an installation which has two SCADA (Intouch) HMIs and I want to save the data in an SQL Server database which will be in another computer. To be as sure as possible that I have an operating database I'm going to set a SQL Server mirroring. So I will have 2 SQL server databases with a distributor. About this I don't have any doubt. To make it easy to understand I've made an image with the architecture of the system.
Architecture.
My doubt is how do I configure the Alarm DB Logger to make it point, automatically, to the secondary database in case that the principal database is down for any unknown failover.
PS: I don't know if it's even possible.
Configure it the database in Automatic failover. The connection are handled automatically in case of a failover. Read on Mirroring EndPoints
The below Links should have more than enough information.
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/role-switching-during-a-database-mirroring-session-sql-server
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/the-database-mirroring-endpoint-sql-server
The AlarmDBLogger reads its configuration from the registry, so you could try the following:
Stop AlarmLogger
Change ServerName in registry [HKLM].[Software].[Wonderware].[AlarmLogger].[SQLServer]
Start AlarmLogger
But what about the two InTouch-nodes? What if one of those fails? You would have to make sure one of them logs alarms, and that they don't log duplicates!
The standard controls and activex for alarms use a specific view in the alarm database. You cannot change that behaviour, but you can script a server change in InTouch or System Platform.
Keep in mind that redundancy needs to be tested, and should only be implemented if 100% uptime is necessary. In many cases you will be creating new problems to solve instead of solving an actual problem.
I am using MS Access to connect to Sql Server through a DSN connection. This is a linked table to a sql server backend. Here is the connection string
ODBC;DSN=mydsn;Description=mydesc;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=mydb;ApplicationIntent=READONLY;;TABLE=dbo.mytable
As you can see there is a ApplicationIntent=READONLY tag in the connection string. What does this mean. Am I connecting to the database in a read only fashion? Is it recommended to perform updates and inserts using this connection string?
This means that if you are using Availability Groups in SQL Server 2012, the engine knows that your connections are read only and can be routed to read-only replicas (if they exist). Some information here:
Configure Read-Only Access on an Availability Replica
Availability Group Listeners, Client Connectivity, and Application Failover
If you are not currently using Availability Groups, it may be a good idea to leave that in there for forward compatibility, but it really depends on whether or not you are intentionally only just reading. This should prevent writes but there are some caveats. These Connect items may be useful or may leave you scratching your head. I'll confess I haven't read them through.
ApplicationIntent=ReadOnly allows updates to a database
ApplicationIntent=ReadOnly does not send the connection to the secondary copy
In principle an SQL Server failover cluster presents itself as a virtual machine that applications can connect to oblivious to the fact that the SQL Server is actually a cluster of servers, hence, in principle no additional logic is required within the database access tier of the application.
My question is whether the above is true and whether there are best practice modifications to how the DB access tier operates when using a failover cluster. E.g. presumably when failover occurs there will be a delay that may cause a time-out error at the DB access tier, we are considering putting logic in that tier to re-try [some] DB calls upon a timeout occurring (we already have retry logic for DB deadlocks). This provides another level of protection from errors affecting the application.
If a failover switch occurs and results in the higher application level receiving a timeout error on a service call then that is not seamless switch over. Should we simply be setting our timeouts at a duration that allows for failover?
Thanks.
In principle an SQL Server failover cluster presents itself as a virtual machine that
applications can connect to oblivious to the fact that the SQL Server
is actually a cluster of servers
Ah? Really? That contradicts documentation. A cluster is basically nothing more than a moving IP address with different installation on different servers, hardly a virtual machine.
in principle no additional logic is required within the database access tier of the
application.
Yes and no - a failing node DOES kill all ongoing transactions and connections, obviously, so the CLIENT must be able to react to that and retry. If the client crashes because a connection is down an does not retry, it does not help you that server is reachable again after a second or two.
Should we simply be setting our timeouts at a duration that allows for failover?
No, a connection is broken by failover as the ongoing transaction state is lost. You need to reestablish the connection and then start all Sql commands again that were issued in the transaction.
Note from a security point, clustering is bad and you should use mirroring - you have a specific risk that a failing cluster node turns the database files corrupt in which case the fail-over fails. Mirroring is more robust.