[MXS-359] keepalive client connection on master failover Created: 2015-09-10  Updated: 2020-08-25  Resolved: 2018-03-15

Status: Closed
Project: MariaDB MaxScale
Component/s: readwritesplit
Affects Version/s: None
Fix Version/s: 2.3.0

Type: New Feature Priority: Major
Reporter: VAROQUI Stephane Assignee: markus makela
Resolution: Fixed Votes: 2
Labels: None

Issue Links:
Duplicate
is duplicated by MXS-1737 Existing ReadWriteSplit connection ca... Closed
PartOf
is part of MXS-636 Continue handling read queries althou... Closed
is part of MXS-1501 Tasks related to transparent master f... Closed
Sprint: MXS-SPRINT-53

 Description   

Planned Tasks

  • Allow re-connection to master servers
  • Allow the master server to change mid-session

Original Issue

The case that we try to solve are very frequent in 3 tiers Java Applications , we have long running connections in a 1 to 1 model majority of connection in state Idle. Loosing the DB backend would generate JDBC errors leaving some application that don't catch exception in a failed situation , despite we could have hidden this to all sessions that have committed just before the failure

Connection context tracking will be used (encoding, variables prepared statement ),
Maxscale maintain session variable keepalive = 0

On event
If tmp table set keepalive = 1
If SP Call set keepalive = 2
If keepalive not in (1,2) and autocomit =1 and statement set keepalive = 0
If keepalive not in (1,2) and autocomit =1 and query=ANY set keepalive = 0

If keepalive not in (1,2) and autocomit =1 and query=BEGIN set keepalive = 3
If keepalive not in (1,2) and autocomit =1 and keepalive = 3 and query=ANY set keepalive = 4
If keepalive not in (1,2) and autocomit =1 and query=COMMIT set keepalive =0

If keepalive not in (1,2) and autocomit =0 and query=COMMIT set keepalive =3
If keepalive not in (1,2) and autocomit =0 and query=ANY set keepalive =4

We can keepalive in keepalive =0 and keepalive=3
If keepalive=3 we need to START TRANSACTION on the new backend



 Comments   
Comment by markus makela [ 2017-08-22 ]

First implementations of this could "promote" a previous slave server as the new master server of the connection if certain requirements are met. The requirements would be that no transactions are open and that autocommit is enabled. This should allow master failover but it depends on an external actor changing the replication topology in a way that doesn't cause inconsistencies in the database.

Generated at Thu Feb 08 03:58:42 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.