Release Notes for MariaDB MaxScale 2.5.25

With the Smart Router (smartrouter), if a session is closed while waiting on a server reply, MaxScale leaks memory, which can lead to an out-of-memory (OOM) condition. (MXS-4476)

With the Smart Router (smartrouter), MaxScale can hang under heavy load. (MXS-4473)

When the internal query parser throws an exception, the Binlog Router (binlogrouter) does not catch it. (MXS-4510)

• In previous releases, this could occur when a SET statement is used to modify gtid_slave_pos and the file where the GTID is stored is unavailable.

• Starting with this release, Binlog Router (binlogrouter) catches exceptions from the internal parser.

When MaxScale is under high load, MaxScale can lose messages when writing to its message queue, which can cause MaxScale to hang. (MXS-4474)

• In previous releases, the following log messages could appear in the MaxScale log:

  Worker WORKER_THREAD_ID attempted to send a message to worker WORKER_THREAD_ID
  

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)

• Starting with this release, Binlog Router (binlogrouter) can properly handle binary log events larger than INT_MAX (2,147,483,647) bytes.

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)

When a server is down, MaxScale does not know the server's MariaDB Server version, and MaxScale can make incorrect assumptions about the server version that can negatively impact how it classifies and routes queries. (MXS-4524)

• In previous releases, MaxScale's incorrect assumptions about the server version can cause the internal query classifier to incorrectly classify sequence operations as read queries.

• Starting with this release, when MaxScale does not know a server's version, the server is ignored when calculating the minimum and maximum server versions to prevent the query classifier from using the wrong version number.

When writeq_high_water is non-zero, a session can end up in an inconsistent state when the session is closed while network traffic throttling is in effect. (MXS-4515)

The skip_name_resolve parameter is not dynamic. (MXS-4514)

• Starting with this release, the skip_name_resolve parameter is configurable at runtime (dynamic).

When the masking filter is used and the masking rules use host wildcards in the applies_to or exempted attributes, user hosts are not interpreted properly, which can cause users to incorrectly receive unmasked results. (MXS-4504)

When Binlog Filter is used to exclude events, replication can fail with an error. (MXS-4494)

• In previous releases, the following errors could occur:

  [ERROR] Unexpected break of being relay-logged GTID 0-3000-11 event group by the current GTID event 0-3000-12
  [ERROR] Slave I/O: Relay log write failure: could not queue event from master, Internal MariaDB error code: 1595
  

• Starting with this release, when statement-based replication is used and a query event is excluded, the query string in the event is replaced with an SQL comment. This causes the query event to do nothing and prevents the event from modifying the contents of the database. The GTID position of the database being replicated will still advance, which means that servers that replicate from it continue to function correctly.

MaxScale uses the default collation for the character set instead of the collation defined for the server. (MXS-4489)

With the Binlog Router (binlogrouter), GTID events can be written to the binary log too early. (MXS-4197)

With the Binlog Router (binlogrouter), the rpl_state file is not updated in an atomic manner. (MXS-3972)