[MXS-1477] Lost connection to MySQL server during query Created: 2017-10-19  Updated: 2017-12-27  Resolved: 2017-12-27

Status: Closed
Project: MariaDB MaxScale
Component/s: galeramon, readwritesplit
Affects Version/s: 2.1.6, 2.1.9
Fix Version/s: 2.1.12

Type: Bug Priority: Major
Reporter: Dirk Gnedler Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: galera, mariadb, maxscale
Environment:

HyperV VM - Operating System: Ubuntu 16.04.3 LTS - Kernel: Linux 4.4.0-92-generic

MariaDB Cluster: Operating System: Ubuntu 16.04.3 LTS - Kernel: Linux 4.4.0-92-generic - mysql Ver 15.1 Distrib 10.0.31-MariaDB Galera Cluster

Attachments: Text File maxscale-bug.log    

 Description   

Hello,

we have problems with maxscale in front of MariaDB.
It's configured as multi master with read/write split.

As you can see in my Log on Line 76 the Connection drop and all Sessions close.
This results in problems on the attached systems.

the mariadb server has no corresponding log entry or warning

2 things we have seen that could maybe be part of the problem:
1) line 90 - there is no log entry since 15:08:28 - the connection could be open since 14:24 max. (last error)
2) line 88 - on this session is the second log line of the last query missing (line 56) - on other connection you can see "Route query to..."

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

Appears to be caused by this:

2017-10-13 15:16:57   error  : Failed to execute query on server 'vmdbc05' ([10.14.22.35]:3306): Lost connection to MySQL server during query
 
2017-10-13 15:16:57   notice : Server changed state: vmdbc04[10.14.22.34:3306]: new_master. [Slave, Synced, Running] -> [Master, Synced, Running]
 
2017-10-13 15:16:57   notice : Server changed state: vmdbc05[10.14.22.35:3306]: lost_master. [Master, Synced, Running] -> [Running]

I think this could be fixed by using the new query_retries parameter that was added to solve this problem in 2.1.10. The parameter will cause a failed query to be retried N times before giving up. Setting this value to 1 should prevent most of the false positives while still retaining the relatively fast failure detection.

Comment by Dirk Gnedler [ 2017-11-09 ]

Thank you for your hint with this new option.
We will test and give feedback.

Comment by markus makela [ 2017-11-21 ]

ahdDGne Any updates?

Comment by markus makela [ 2017-12-27 ]

Closing as fixed due to no feedback. It is also likely that this is already fixed in 2.1.12. If not, please reopen this.

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