Release Notes for MariaDB MaxScale 6.2.1

Overview

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

MariaDB MaxScale 6.2.1 was released on 2022-01-19. This release is of General Availability (GA) maturity.

Notable Changes

  • Configurable checksum validation for transaction replay (MXS-3894, MXS-3379)

    • When the transaction_replay parameter is enabled for Read/Write Split Router (readwritesplit), the behavior of checksum validation can now be configured.

    • A new transaction_replay_checksum parameter can now be used to configure the checksum validation behavior.

    • When transaction_replay_checksum=full is set, the checksum validation behaves as it did in previous releases. All responses from the server are included in the checksum. This retains the full consistency guarantee of the replayed transaction as it must match exactly the one that was already returned to the client.

    • When transaction_replay_checksum=result_only is set, the checksum validation excludes OK packets. Only result-sets and errors are included in the checksum. This mode is intended to be used in cases where the extra information (auto-generated ID, warnings etc.) returned in the OK packet is not used by the application. This mode is safe to use only if the auto-generated ID is not actually used by any following queries. An example of such behavior would be a transaction that ends with an INSERT into a table with an AUTO_INCREMENT field.

    • When transaction_replay_checksum=no_insert_id is set, the checksum validation excludes OK packets and results from queries that use the LAST_INSERT_ID() function. This mode is safe to use only if the result of the query is not used by any subsequent statement in the transaction.

    • The default value of the transaction_replay_checksum parameter is full.

  • More predictable replay timeouts for transaction replay (MXS-3937)

    • When the transaction_replay parameter is enabled for Read/Write Split Router (readwritesplit), the replay timeouts can now be configured in a more predictable manner.

    • A new transaction_replay_timeout parameter can now be used to configure the timeouts.

    • The transaction_replay_timeout parameter is not enabled by default. By default, how long a transaction can be retried is controlled by delayed_retry_timeout and transaction_replay_attempts. This can result in a maximum replay time limit of delayed_retry_timeout multiplied by transaction_replay_attempts, by default this is 50 seconds. The minimum replay time limit can be as low as transaction_replay_attempts seconds (5 seconds by default) in cases where the connection fails after it was created. Usually this happens due to problems like the max_connections limit being hit on the database server or an Xpand group change being in progress.

    • When the new transaction_replay_timeout parameter is set to a duration value, the time a transaction replay can take is controlled solely by this parameter. This is a more convenient and predictable method of controlling how long a transaction replay can be attempted before the connection is closed. If delayed_retry_timeout is less than transaction_replay_timeout, it is set to the same value.

  • Configurable log levels for services (MXS-2353)

    • Log levels can now be enabled on a per-service scope.

    • The log_warning, log_notice, log_info, and log_debug parameters can now be enabled for specific services when the corresponding global parameter is disabled.

Issues Fixed

Can result in a hang or crash

  • When MaxScale receives an incorrect response from a session command, it could cause MaxScale to raise a debug assertion. (MXS-3940)

  • When MaxScale replays a session command during transaction replay, it could cause MaxScale to raise a debug assertion. (MXS-3939)

  • When a server is unlinked from Xpand Monitor (xpandmon), it could cause MaxScale to raise a debug assertion. (MXS-3938)

  • When maxctrl set server maintenance --force is executed, MaxScale crashes. (MXS-3917)

  • MaxScale can crash due to a double free or corruption. (MXS-3908)

  • When Avro Router (avrorouter) is used to send data to Kafka, MaxScale could crash. (MXS-3897)

Can result in unexpected behavior

  • When the configuration of Xpand Monitor (xpandmon) is altered at run-time, the operation fails. (MXS-3943)

  • When a Read/Write Split Router (readwritesplit) service has multiple primary servers and the primary server being used goes down, the router does not properly switch to the other primary server, which could cause replayed session commands to fail. (MXS-3941)

  • When a server is linked to Xpand Monitor (xpandmon), the server is not added. (MXS-3934)

  • When a stored procedure with an OUT parameter is executed, the connection could stall. (MXS-3929)

  • When MaxScale loads user accounts and privileges from Xpand, the MaxScale log contains the following warning: (MXS-3928)

    Service user 'DATABASE_USER' of service 'SERVICE_NAME' does not have 'SHOW DATABASES' or a similar global privilege on '@@MONITOR_NAME:SERVER_NAME'. This may cause authentication errors on clients logging in to a specific database.

  • When a delayed query is routed, the corresponding log messages in the MaxScale log do not contain the session ID. (MXS-3927)

  • When the delayed_retry parameter is enabled for Read/Write Split Router (readwritesplit), session commands are not retried. (MXS-3924)

  • When a database name contains a utf8mb4 character with a code point greater than or equal to U+0080, MaxScale fails to connect with the following error: (MXS-3920)

    ERROR 1049 (42000): Unknown database 'DATABASE_NAME'

  • MaxScale's query classifier doesn't track autocommit correctly. (MXS-3915)

  • Monitor parameters could not be modified from the table in MaxGUI. (MXS-3911)

  • When MaxCtrl connects to localhost and the http_proxy environment variable is configured, MaxCtrl incorrectly uses the HTTP proxy. (MXS-3909)

  • When MaxScale is used with Xpand, MaxScale does not properly detect Xpand's capabilities, which could cause the following errors to be written to the MaxScale log: (MXS-3907)

    2021-12-08 21:22:18   error  : (79) Unexpected result state. cmd: 0x08, len: 41 server: @@MONITOR_NAME:SERVER_NAME
2021-12-08 21:22:18   error  : (79) Unexpected result state. cmd: 0xfe, len: 5 server: @@MONITOR_NAME:SERVER_NAME

  • When the systemd watchdog kills MaxScale due to a hang, MaxScale could write the stack trace of the wrong thread to the MaxScale log: (MXS-3900)

    • When gdb is installed, MaxScale will now use gdb to write stack traces of all threads to the MaxScale log.

    • When gdb is not installed, MaxScale will write the stack trace of the thread that catches the signal to the MaxScale log, as in previous releases.

  • When MaxCtrl reads a password from stdin, it could incorrectly read commands from stdin as part of the password. (MXS-3896)

  • Read/Write Split Router (readwritesplit) incorrectly calculates idle times for connection_timeout, which could cause connections with running transactions to be considered idle. (MXS-3893)

  • When a SELECT query is executed using MaxGUI without a LIMIT clause, MaxScale does not automatically add a LIMIT clause. (MXS-3841)

  • When the Kafka CDC Router (kafkacdc) replicates from the Binlog Router (binlogrouter), it would fail with the following error: (MXS-3807)

    Kafka: FindCoordinator response error: Group authorization failed.

  • When the MaxScale log is viewed in MaxGUI, it uses excessive memory. (MXS-3544)

Platforms

In alignment to the MariaDB Corporation Engineering Policy, MariaDB MaxScale 6.2.1 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)

  • SUSE Linux Enterprise Server 12 (x86_64, ARM64)

  • SUSE Linux Enterprise Server 15 (x86_64, ARM64)

  • Ubuntu 18.04 (x86_64, ARM64)

  • Ubuntu 20.04 (x86_64, ARM64)