[MXS-917] False error message about master not being in use Created: 2016-10-16  Updated: 2016-10-20  Resolved: 2016-10-17

Status: Closed
Project: MariaDB MaxScale
Component/s: readwritesplit
Affects Version/s: 2.0.1
Fix Version/s: 2.0.2

Type: Bug Priority: Major
Reporter: markus makela Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MXS-880 Write query failure with multiple mas... Closed

 Description   

When MaxScale is run under heavy load, it occasionally logs the following error message.

Could not find master among the backend servers. Previous master's state : Master is not in use

This can happen if a network disconnection happens before a query from the client has finished processing.

Here is an excerpt from a log created with a modified version of 2.0.1 with extra logging and session identifiers added to the log messages.

2016-10-16 14:34:08   notice : 1972: Closing bref: server1
 
2016-10-16 14:34:08   error  : 1972 Backend hangup error handling.
 
2016-10-16 14:34:08   notice : 1972: Closing bref: server3
 
2016-10-16 14:34:08   error  : 1972 Backend hangup error handling.
 
2016-10-16 14:34:08   notice : 1972: Closing bref: server2
 
2016-10-16 14:34:08   error  : 1972 Backend hangup error handling.
 
2016-10-16 14:34:08   notice : 1972: Closing bref: server4
 
2016-10-16 14:34:08   error  : 1972 Backend hangup error handling.
 
2016-10-16 14:34:08   error  : 1972 Could not find master among the backend servers. Previous master's state : Master is not in use

This error message should not be logged if the master server was deliberately taken out of use.

 Comments   
Comment by markus makela [ 2016-10-17 ]

The error message was a false positive caused by backend hangups occurring at the same time that a query was being routed. This led to the closing of the backend connections before the query finished processing.

Since the closing of the backends mid-query is not an error, the message should not be logged.

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