Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
23.08.4
-
None
-
MXS-SPRINT-206, MXS-SPRINT-207
Description
Bug Description
When transaction replay is enabled, "kill user" doesn't work as expected. The query just keeps coming back.
I don't know how this can be improved, and I've seen the recommendation previously (e.g. MXS-3756 / MXS-1452) that people use the Maxscale session IDs, but I'm raising this ticket because:
- If users can run "kill user <theirUserName>" they can manage their own problems rather than require admin intervention
- How does the user get the maxscale session ID of a session that's executing a long running query?
It feels like there should be a better way to manage this than admin having to log on to the Maxscale server, running list/show sessions, finding the user session out of the thousand or so sessions, and then running destroy session.
Implemented Fix
Whenever a KILL [CONNECTION] query is received and the target session is the same user as the client user, the session is flagged as "dead". This will prevent all replay functionality in readwritesplit when the connection eventually dies. The functionality is currently limited to sessions with matching usernames as otherwise there's an opportunity for slight misuse where clients without the required grants do a KILL on a different user's connection and a failure later on ends up not being handled transparently due to the KILL flagging the session as "dead".