Release Notes for MariaDB MaxScale 6.4.2

When the persistpoolmax parameter is enabled and the KILL statement is executed, the connection that executes the statement hangs. (MXS-4209)

When the Schema Router (schemarouter) is used, MaxScale can crash due to a double-free. (MXS-4237)

When an invalid parameter is configured for a listener, MaxScale throws a std::out_of_range exception and crashes. (MXS-4211)

When replication fails to start on a replica node due to an incorrect password for the replication user, the Connection Router (readconnroute) still routes connections to the replica node. (MXS-4240, MXS-4239)

When replication fails to start on a replica node due to an incorrect password for the replication user, the MariaDB Monitor (mariadbmon) flags the node with the wrong server state. (MXS-4239)

• In previous releases, commands like maxctrl list servers would show [Slave, Running] in cases where replication fails to start on a replica node due to an incorrect password for the replication user.

When MaxScale tries to load a TLS certificate for a listener and the certificate's chain of trust is unknown to OpenSSL, MaxScale improperly verifies the certificate while building the certificate chain. (MXS-4198)

• In previous releases, the following notice could be written to the MaxScale log:

  notice : (LISTENER_NAME); OpenSSL reported problems in the certificate chain: error:1414C086:SSL routines:ssl_build_cert_chain:certificate verify failed. This is expected for certificates that do not contain the whole certificate chain.
  

• Starting with this release, the notice is no longer written to the log.

When the config_sync_cluster parameter is enabled and different MaxScale nodes have different values for static global parameters, configuration synchronization fails. (MXS-4218)

• Starting with this release, MaxScale ignores static global parameters during configuration synchronization.

When connection sharing is enabled for the Read/Write Split Router (readwritesplit) by setting the idle_session_pool_time parameter to 0 or greater, the router can raise timeouts. (MXS-4183)

• When connection sharing is enabled and a timeout occurs, the following messages can be written to the MaxScale log:

  info   : [readwritesplit] (ROUTER_NAME); Master 'SERVER_NAME' failed: #HY000: Timed out when waiting for a connection.
  error  : [readwritesplit] (ROUTER_NAME); Lost connection to the master server, closing session. Lost connection to master server while waiting for a result. Connection has been idle for 69 seconds. Error caused by: #HY000: Timed out when waiting for a connection.. Last close reason: <none>. Last error:
  

• Starting with this release, the multiplex_timeout parameter is available to configure the timeout interval.

  • The default value of multiplex_timeout is 60s.

  • The multiplex_timeout value can be increased if queries fail with the timeout error shown above.

  • The multiplex_timeout value can be decreased to prevent stalls by failing earlier.

When the Xpand Monitor (xpandmon) is used, the parameters for the initial bootstrap servers are not propagated to the dynamically detected servers. (MXS-4219)