Release Notes for MariaDB MaxScale 6.4.7

Overview

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.

Issues Fixed

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[44390] 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 SELECT statements 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_reads parameter is set to false. (MXS-4611)

  • With the Read/Write Split Router (readwritesplit), when transaction_replay is enabled, MaxScale uses too much memory. (MXS-4586)

    • In previous releases, the documented default value for the transaction_replay_max_size parameter 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 .. END or XA transactions.

    • Starting with this release, the default value for the transaction_replay_max_size parameter is 1MiB.

  • When maxctrl commands are executed, the monitorpw parameter is not masked for servers. (MXS-4560)

  • When multiple queries are executed, Query Log All Filter (qlafilter) can sometimes log queries that do not match. (MXS-4602)

  • MaxScale does not correctly classify scientific numbers (for example, 1e10) in queries. (MXS-4596)

  • When maxctrl classify is executed with a query that contains scientific numbers, a malformed query is sent to the REST API. (MXS-4595)

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

  • When the Query Log All Filter (qlafilter) is used with options=extended, queries are not properly matched, and query duration is not properly tracked. (MXS-4551)

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

Platforms

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

  • Red Hat Enterprise Linux 9 (x86_64, ARM64)

  • Rocky Linux 8 (x86_64, ARM64)

  • Rocky Linux 9 (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)