[MXS-3397] Connection loss problem on maxscale Created: 2021-02-04  Updated: 2021-08-30  Resolved: 2021-08-30

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: 2.5.8
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: haooy chen Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

I have a maxscale instance maxscale01 and three MySQL instances, mysql01 (Master) mysql02 (slave01) mysql03 (slave02)



 Description   

I have a maxscale instance maxscale01 which version is v2.2.22 and three MySQL instances, mysql01 (Master) mysql02 (slave01) mysql03 (slave02)
I found that when I use MySQL -uqfsys -p -h${maxscale_IP} - p ${port}, and keep a long connection.
At this point, there is a session from the qfsys account on each MySQL back end, and a long connection is maintained.
When I repeatedly execute a `select 1` as heartbeat detection on the client for a long time, the request is continuously forwarded to mysql01, and the qfsys session time on mysql01 is refreshed.
I use a long connection on the client, there has a problem that session wait_timeout in MySQL. When my session from the library times out, I execute a large-scale query on the client, and these requests are forwarded to slave01. Since the session of qfsys on slave01 has timed out, I will prompt the client for lost connection to MySQL.
I don't want to increase that value of wait_timeout
Does maxscale have any configuration or method to solve this problem?

My profile is as follows:

proxy_protocol=1
[server-0]
type=server
address=test-cbdd100-headless
port=3306
protocol=MariaDBBackend
 
[server-1]
type=server
address=test-cbdd101-headless
port=3306
protocol=MariaDBBackend
 
[server-2]
type=server
address=test-cbdd110-headless
port=3306
protocol=MariaDBBackend
 
[server-3]
type=server
address=test-cbdd111-headless
port=3306
protocol=MariaDBBackend
 
[MariaDB-Monitor]
type=monitor
module=mysqlmon
servers=server-0,server-1,server-2,server-3
user=root
passwd=$MYSQL_ROOT_PASSWORD
monitor_interval=1000
 
[Read-Only-Service]
type=service
router=readconnroute
servers=server-0,server-1,server-2,server-3
user=root
passwd=$MYSQL_ROOT_PASSWORD
enable_root_user=1
 
[Read-Write-Service]
type=service
router=readwritesplit
servers=server-0,server-1,server-2,server-3
user=root
passwd=$MYSQL_ROOT_PASSWORD
enable_root_user=1
master_accept_reads=true
use_sql_variables_in=master
 
[MaxAdmin-Service]
type=service
router=cli
 
[Read-Only-Listener]
type=listener
service=Read-Only-Service
protocol=MariaDBClient
port=4008
 
[Read-Write-Listener]
type=listener
service=Read-Write-Service
protocol=MariaDBClient
port=4006
 
[MaxAdmin-Listener]
type=listener
service=MaxAdmin-Service
protocol=maxscaled
socket=default



 Comments   
Comment by markus makela [ 2021-02-04 ]

MaxScale 2.2 is EOL, can you test this with the latest 2.5 release?

Comment by haooy chen [ 2021-02-04 ]

Thank you. I'll check it later

Comment by haooy chen [ 2021-02-22 ]

hello,markus ,I reproduced it. The maxscale version is MaxScale 2.5.8

Comment by markus makela [ 2021-02-22 ]

In MaxScale 2.5 there's a connection_keepalive feature designed for situations like this. The default value is 300 seconds so any connection that does a query within that time should keep all connections alive.

What is the value of your wait_timeout?

Comment by haooy chen [ 2021-02-22 ]

interactive_timeout: 172800
wait_timeout: 172800

Comment by haooy chen [ 2021-02-22 ]

I connect to the database through maxscale,I execute a query,The connection of master is refreshed,but slave is not refreshed。I'm curious about this。

Comment by markus makela [ 2021-08-02 ]

Can you test this again with the latest 2.5 release? We've done some fixes to the connection_keepalive feature and it might fix this problem.

Comment by markus makela [ 2021-08-24 ]

chenhao any updates?

Comment by markus makela [ 2021-08-30 ]

I'll close this as Cannot Reproduce. If you still see this problem with the latest 2.5 release, let us know and we'll reopen this.

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