[MXS-4508] Mariadbmon loses locks without reporting a broken connection Created: 2023-02-14  Updated: 2024-02-05  Resolved: 2023-11-06

Status: Closed
Project: MariaDB MaxScale
Component/s: Monitor
Affects Version/s: 2.5.19, 6.4.5, 22.08.4, 23.02
Fix Version/s: 2.5.19

Type: Bug Priority: Major
Reporter: Allen Lee (Inactive) Assignee: Esa Korhonen
Resolution: Incomplete Votes: 1
Labels: None
Environment:

RHEL 7


Issue Links:
Relates
relates to MXS-4511 master status change when run stop slave Closed
Sprint: MXS-SPRINT-192, MXS-SPRINT-193

 Description   

The monitor connections unconditionally enable MYSQL_OPT_RECONNECT which can hide the loss of cooperative monitoring locks. Unfortunately the failover requires this option so it cannot outright be disabled.


Original description:
Stop slave on slave server changes master's status on MaxScale.

Server changed state: xxx1p[192.168.254.52:3306]: new_master. [Slave, Running] -> [Master, Running]



 Comments   
Comment by markus makela [ 2023-02-14 ]

In the server logs, this can be seen:

ERROR 1158: Got an error reading communication packets : (null)

This suggests that the MYSQL_OPT_RECONNECT might be hiding this connection loss which would explain the confusing error messages.

Comment by markus makela [ 2023-02-15 ]

The MYSQL_OPT_RECONNECT is no longer used which should now cause the errors to be reported correctly. The state change itself wasn't a result of this but the confusing error messaging about losing locks was.

Comment by markus makela [ 2023-02-17 ]

Had to revert commit d0cd7a705c28c8bb64304d2071dd4215d1b6dfa2 since it breaks failovers.

Comment by Esa Korhonen [ 2023-11-06 ]

Unclear issue, more details required.

Generated at Thu Feb 08 04:29:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.