Release Notes for MariaDB MaxScale 6.4.7
MariaDB MaxScale is an advanced database proxy and query router.
MariaDB MaxScale 6.4.7 was released on 2023-05-24. This release is of General Availability (GA) maturity.
Can result in a hang or crash
On CPUs that do not support Advanced Vector Extensions (AVX), MaxScale fails to start. (MXS-4599)
In previous releases, when MaxScale is started with a CPU that does not support AVX instructions, MaxScale raises errors like the following:
[ 646.714809] show_signal: 11 callbacks suppressed [ 646.714815] traps: maxscale trap invalid opcode ip:7fd8ed566a5c sp:7ffc245ef3d0 error:0 in libmaxscale-common.so.1.0.0[7fd8ed528000+338000]
Starting with this release, MaxScale starts properly with a CPU that does not support AVX instructions.
Can result in unexpected behavior
When a statement has embedded comments, such as
SELECT /* comment here */ 1, the query can be classified incorrectly. (MXS-4548)
With the Read/Write Split Router (
readwritesplit), when MaxScale routes a multi-statement query containing multiple
SELECTstatements to a server, if the server becomes unavailable while executing the multi-statement query, MaxScale does not detect that the statements are partially executed, and an unexpected error is returned to the client. (MXS-4615)
In previous releases, this issue could occur with multi-statement queries like the following:
BEGIN NOT ATOMIC SELECT SLEEP(1); SELECT SLEEP(2); SELECT SLEEP(3); END;
Starting with this release, MaxScale can detect when a multi-statement query is partially executed.
When a compound statement is defined with
BEGIN NOT ATOMIC .. END, MaxScale's query classifier classifies the statement as the start of a transaction, which breaks transaction boundary detection. (MXS-4614)
With the Read/Write Split Router (
readwritesplit), when the primary server is idle and the replica servers are busy, MaxScale routes read statements to the idle primary server, even when the
master_accept_readsparameter is set to
Starting with this release, the Read/Write Split Router (
readwritesplit) only routes read statements to the primary server when
In previous releases, the documented default value for the
transaction_replay_max_sizeparameter was 1 MiB, but due to an issue, 1 GiB was actually used. Consequently, MaxScale could use too much memory for transaction replay in the following scenarios:
The Read/Write Split service handled large transactions that exceed 1 MiB in size.
The Read/Write Split service handled statements that break MaxScale's transaction boundary detection, such as the previously mentioned issues with
BEGIN NOT ATOMIC .. ENDor XA transactions.
Starting with this release, the default value for the
transaction_replay_max_sizeparameter is 1MiB.
MaxScale does not correctly classify scientific numbers (for example,
1e10) in queries. (MXS-4596)
In previous releases, queries like the following would be malformed:
SELECT 1e10 + 1
MaxCtrl would send the following malformed query to the REST API:
select 1e10 1
Starting with this release, MaxCtrl does not send a malformed query to the REST API in this scenario.
In previous releases, MaxScale improperly specified the extended option when calling the PCRE2 functions, so matching did not work properly, which would cause queries to be missing from the log. Additionally, query duration was not properly tracked, so incorrect query durations would be logged.
Starting with this release, MaxScale properly specifies the extended option when calling the PCRE2 functions, and MaxScale properly tracks query durations.
In alignment to the MariaDB Engineering Policy, MariaDB MaxScale 6.4.7 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_
Red Hat Enterprise Linux 9 (x86_
Rocky Linux 8 (x86_
Rocky Linux 9 (x86_
SUSE Linux Enterprise Server 15 (x86_
Ubuntu 18.04 (x86_
Ubuntu 20.04 (x86_
Ubuntu 22.04 (x86_