Release Notes for MariaDB MaxScale 6.2.1
This page is part of MariaDB's MariaDB Documentation.
The parent of this page is: Release Notes for MariaDB MaxScale 6
Topics on this page:
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.
Configurable checksum validation for transaction replay (MXS-3894, MXS-3379)
transaction_replayparameter is enabled for Read/Write Split Router (
readwritesplit), the behavior of checksum validation can now be configured.
transaction_replay_checksumparameter can now be used to configure the checksum validation behavior.
transaction_replay_checksum=fullis 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.
transaction_replay_checksum=result_onlyis set, the checksum validation excludes
OKpackets. 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
OKpacket 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_
transaction_replay_checksum=no_insert_idis set, the checksum validation excludes
OKpackets 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
More predictable replay timeouts for transaction replay (MXS-3937)
transaction_replayparameter is enabled for Read/Write Split Router (
readwritesplit), the replay timeouts can now be configured in a more predictable manner.
transaction_replay_timeoutparameter can now be used to configure the timeouts.
transaction_replay_timeoutparameter is not enabled by default. By default, how long a transaction can be retried is controlled by
transaction_replay_attempts. This can result in a maximum replay time limit of
transaction_replay_attempts, by default this is 50 seconds. The minimum replay time limit can be as low as
transaction_replay_attemptsseconds (5 seconds by default) in cases where the connection fails after it was created. Usually this happens due to problems like the
max_connectionslimit being hit on the database server or an Xpand group change being in progress.
When the new
transaction_replay_timeoutparameter 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_timeoutis 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.
log_debugparameters can now be enabled for specific services when the corresponding global parameter is disabled.
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)
maxctrl set server maintenance --forceis 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
OUTparameter 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)
delayed_retryparameter is enabled for Read/Write Split Router (
readwritesplit), session commands are not retried. (MXS-3924)
When a database name contains a
utf8mb4character 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
Monitor parameters could not be modified from the table in MaxGUI. (MXS-3911)
When MaxCtrl connects to
http_proxyenvironment 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
systemdwatchdog kills MaxScale due to a hang, MaxScale could write the stack trace of the wrong thread to the MaxScale log:
gdbis installed, MaxScale will now use
gdbto write stack traces of all threads to the MaxScale log. (MXS-3900)
gdbis 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
stdinas 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)
SELECTquery is executed using MaxGUI without a
LIMITclause, MaxScale does not automatically add a
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)
In alignment to the MariaDB Corporation Engineering Policy, MariaDB MaxScale 6.2.1 is provided for:
CentOS 7 (x86_
Debian 9 (x86_
Debian 10 (x86_
Debian 11 (x86_
Red Hat Enterprise Linux 7 (x86_
Red Hat Enterprise Linux 8 (x86_
SUSE Linux Enterprise Server 12 (x86_
SUSE Linux Enterprise Server 15 (x86_
Ubuntu 18.04 (x86_
Ubuntu 20.04 (x86_
Deploy Enterprise Cluster Topology with MariaDB MaxScale 6Deploy Enterprise Cluster Topology with MariaDB MaxScale 6
Deploy Primary/Replica Topology with MariaDB MaxScale 6Deploy Primary/Replica Topology with MariaDB MaxScale 6
Deploy ColumnStore Object Storage Topology with MariaDB MaxScale 6Deploy ColumnStore Object Storage Topology with MariaDB MaxScale 6
Deploy ColumnStore Shared Local Storage Topology with MariaDB MaxScale 6Deploy ColumnStore Shared Local Storage Topology with MariaDB MaxScale 6