Release Notes for MariaDB MaxScale 2.5.26

Can result in unexpected behavior

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