centos 7
wait_timeout=60

Strictly speaking, this is not a bug. The failure of the master connection, in this case caused by a low wait_timeout, is something which the current readwritesplit cannot handle. It is recommended to set wait_timeout to a value which is greater than the interval between writes, this guarantees that the master connection is not closed by the backend database. Most of the time it's not needed when MaxScale is used and the connection_timeout parameter for services should be used instead.

There are ways to treat the symptoms of this problem. One of them is to periodically send a COM_PING from the client through MaxScale. This will be sent to all servers and is a common way to keep connections alive. Connection pooling mechanisms tend to do this to keep the pooled connections alive. Another option is to modify the session state in some way e.g. by doing a SET @a=1. This modification is sent to all open connections for the session so that the session state is consistent. This also has the side-effect of resetting the wait_timeout timer.

It is possible that in the future MaxScale could detect a modification in the wait_timeout and automatically send keepalive queries to connections.

thank you for clarifying.

we have an application which has scenarios where it does use both connections on the read-write-split and read-only scenarios where it doesn't. since maxscale is supposed to be transparent (is it?) it doesn't make sense that it would not be able to handle that.

two suggestions:
1. make this very clear in the known limitations section of the documentation
2. feature-request to change this, for instance maxscale could not open a connection until it is used for the first time or just be able to reopen it if it times out

currently we opted to send a "use <dbname>" every 10s as a keep alive.

another thought i had is this:

what if you have multiple slaves which are being read according to which one is the least behind? if some of them are always behind they will eventually timeout, as soon as they would qualify to be used though the query would crash due to the closed connection.

1. make this very clear in the known limitations section of the documentation

Yes, we will clarify this in the limitations section.

2. feature-request to change this, for instance maxscale could not open a connection until it is used for the first time or just be able to reopen it if it times out

This could be an interesting improvement. Although it would slow down the connection creation due to the possible synchronization of the session state, it could allow for a lower performance impact on the cluster as a whole. By delaying the creation of the connections, we could only use the connections that are needed. Please feel free to create a new feature request detailing this functionality.

seams like something was done in mariadb 2:

Read Continuation upon Master Down

The readwritesplit routing module now supports a high availability read mode
where read queries are allowed even if the master server goes down. The new
functionality supports three modes: disconnection on master failure, disconnection
on first write after master failure and error on write after master failure.

The MySQL monitor module, mysqlmon, now supports stale states for both the master
and slave servers. This means that when a slave loses its master, it will retain
the slave state as long as it is running.

For more details about these new modes, please read the ReadWriteSplit
and MySQL Monitor documentation.

https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale/mariadb-maxscale-200-release-notes/

Changing into an improvement and downgrading to major.

Limitations document updated for 2.0.

Added connection keepalive to readwritesplit.