Release Notes for MariaDB MaxScale 23.02.2

Overview

MariaDB MaxScale is an advanced database proxy and query router. MaxScale is a component of MariaDB database products.

MariaDB MaxScale 23.02.2 was released on 2023-05-30. This release is of General Availability (GA) maturity.

This document describes the changes in MaxScale 23.02.2 when compared to MaxScale 23.02.1.

Issues Fixed

Can result in a hang or crash

  • When a multi-statement query is executed with the Query Editor in MaxGUI, all result-sets are rendered at once. (MXS-4612)

    • In previous releases, this issue could cause the browser to consume too much memory and freeze.

    • Starting with this release, the tabs for each result-set in the Query Editor UI have been replaced with a drop-down menu that allows you to choose a specific result-set. The drop-down menu only renders 30 items at a time, and the rest are rendered on demand.

  • 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 binary log event is larger than INT_MAX (2,147,483,647) bytes, Binlog Router (binlogrouter) causes an integer overflow when it calculates the event length, which can lead to excessive memory allocation and errors. (MXS-4557)

  • When the authenticator_options='lower_case_table_names=1' is set, database names are not checked in a case insensitive manner. (MXS-4556)

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

  • MaxScale's query classifier does not properly classify statements related to XA transactions, which breaks transaction boundary detection. (MXS-4625)

    • In previous releases, when a user executed a statement related to XA transactions, such as XA STARTXA START, XA COMMITXA COMMIT, or others, MaxScale would not detect that a transaction has started or ended, which could cause MaxScale to use too much memory for the transaction replay buffer.

    • Starting with this release, MaxScale's query classifier properly classifies statements related to XA transactions.

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

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

    • In previous releases, this issue could cause statements that could share the same classification information to have their own unique classification information. Consequently, this can have a negative performance impact in cases where it causes MaxScale to parse more statements or causes it to store more entries in its statement classification cache.

    • Starting with this release, MaxScale canonicalizes scientific numbers correctly.

  • 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 MaxScale REST API returns parameter values, if a password-related parameter is not set, the REST API sends a masked password for the parameter in the response. (MXS-4571)

    • In previous releases, this issue could cause unset passwords to appear as *****.

    • Starting with this release, unset passwords are displayed as null.

  • With the Query Editor in MaxGUI, when a query with an identifier that contains backticks is executed, the identifier is not properly quoted. (MXS-4601)

  • With MaxGUI, on the current sessions dashboard on the service and service details pages, the "I/O Activity" column is incorrect. (MXS-4564)

    • In previous releases, the "I/O Activity" column contains a button to kill the session instead of details about I/O activity.

    • Starting with this release, the "I/O Activity" column contains details about I/O activity, and the new "Action" column contains a button to kill the session.

  • When MaxScale parses its configuration file during startup, configuration errors related to duplicate sections and duplicate parameter values are not logged. (MXS-4561)

    • In previous releases, since MaxScale would detect these types of errors early in the startup procedure before logging was initialized, MaxScale would report these types of errors using a function that did not write to the MaxScale log.

    • Starting with this release, MaxScale reports these types of errors using a function that does write its messages to the MaxScale log during startup.

Platforms

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

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