Release Notes for MariaDB MaxScale 6.4.2

Overview

MariaDB MaxScale is an advanced database proxy, firewall, and query router.

MariaDB MaxScale 6.4.2 was released on 2022-09-02. This release is of General Availability (GA) maturity.

Issues Fixed

Can result in a hang or crash

Can result in unexpected behavior

  • 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)

Interface Changes

  • Router.readconnroute multiplex_timeout module parameter added

  • Router.readwritesplit multiplex_timeout module parameter added

Platforms

In alignment to the MariaDB Corporation Engineering Policy, MariaDB MaxScale 6.4.2 is provided for:

  • CentOS 7 (x86_64)

  • Debian 9 (x86_64, ARM64)

  • Debian 10 (x86_64, ARM64)

  • Debian 11 (x86_64, ARM64)

  • Red Hat Enterprise Linux 7 (x86_64)

  • Red Hat Enterprise Linux 8 (x86_64, ARM64)

  • Rocky Linux 8 (x86_64, ARM64)

  • SUSE Linux Enterprise Server 15 (x86_64, ARM64)

  • Ubuntu 18.04 (x86_64, ARM64)

  • Ubuntu 20.04 (x86_64, ARM64)

  • Ubuntu 22.04 (x86_64, ARM64)