Release Notes for MariaDB MaxScale 22.08.6

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.

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)

• Starting with this release, the Read/Write Split Router (readwritesplit) only routes read statements to the primary server when master_accept_reads=true

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.

When CREATE USERCREATE USER is executed with the Query Editor in MaxGUI, the plain-text password isn't obfuscated in the query history. (MXS-4570)