Release Notes for MariaDB MaxScale 6.4.5

When a worker's sessions are rebalanced, MaxScale can crash due to a race condition. (MXS-4423)

When MaxScale is under high load, MaxScale can lose messages when writing to its message queue, which can cause MaxScale to hang. (MXS-4474)

• In previous releases, the following log messages could appear in the MaxScale log:

  Worker WORKER_THREAD_ID attempted to send a message to worker WORKER_THREAD_ID
  

With a service-to-service configuration where one service uses another service as its target, MaxScale can crash due to a segmentation fault if a query is replayed right before the connection is closed. (MXS-4460)

When a MaxScale listener performs a TLS handshake with a client, MaxScale does not provide the full certificate chain in the server hello message. (MXS-4450)

• In previous releases, MaxScale only provides the MaxScale certificate in the server hello message.

• Starting with this release, MaxScale provides the full certificate chain in the server hello message.

When MaxScale is executing a query that takes longer than wait_timeout seconds to complete, MaxScale can sometimes consider the client to be idle and can terminate the client connection. (MXS-4440)

• In previous releases, the following log messages could appear in the MaxScale log:

  info   : (10) [readwritesplit] (SERVICE_NAME); Master 'SERVER_NAME' failed: #HY000: Lost connection to backend server: network error (SERVER_NAME: 104, Connection reset by peer)
  error  : (10) [readwritesplit] (SERVICE_NAME); Lost connection to the master server, closing session. Lost connection to master server while connection was idle. Connection has been idle for 120 seconds. Error caused by: #HY000: Lost connection to backend server: network error (SERVER_NAME: 104, Connection reset by peer). Last close reason: <none>. Last error:
  

When MaxScale is under high load, MaxScale's message queues can fill up. (MXS-4439)

• In previous releases, the following log messages could appear in the MaxScale log:

  error  : (CONNECTION_ID) (SERVICE_NAME); Failed to write message to worker WORKER_THREAD_ID: 11, Resource temporarily unavailable
  

With Schema Router (schemarouter), when a table exists on more than one node and one of the nodes with the table becomes unavailable, MaxScale can route queries to the unavailable node. (MXS-4471)

• In previous releases, if a table exists on more than one node, MaxScale routes queries to the first node with the table in its set, even if that node is unavailable.

• Starting with this release, if a table exists on more than one node, MaxScale checks that a node is available before routing queries to it.

With Schema Router (schemarouter), when the USE statement or the COM_INIT_DB command are used to select a database and the database is located on multiple shards, the database is only selected on a single shard, and the selected database on the remaining shards is left unmodified. (MXS-4470)

With Schema Router (schemarouter), transaction control statements (such as BEGIN and COMMIT) can be routed to the wrong nodes when a default database is not selected. (MXS-4467)

• Starting with this release, transaction control statements are routed to all nodes.

With Schema Router (schemarouter), session commands can be routed to nodes that have no databases mapped for the user. (MXS-4454)

With Schema Router (schemarouter), a query can be routed to a failed connection. (MXS-4453)

With the Query Log All (QLA) Filter (qlafilter), when maxctrl rotate logs is executed and the user parameter is defined for the filter, the logs are reopened for any sessions that do not match the user, which causes errors to be logged for each executed statement. (MXS-4435)