Release Notes for MariaDB MaxScale 6.4.6

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.

MaxScale crashes when trying to create a table named DUAL. (MXS-4481)

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

For parameters that accept regular expressions (regex), the empty string ("") and an empty pattern ("//") are not handled the same. (MXS-4547)

• In previous releases, an empty pattern ("//") is not handled as empty, but the empty string ("") is.

• Starting with this release, both the empty string ("") and an empty pattern ("//") are handled as empty.

When a transaction fails checksum verification and transaction_replay_retry_on_mismatch is enabled, readwritesplit can try to replay the failed transaction in an infinite loop. (MXS-4540)

When configuration synchronization is enabled with the config_sync_cluster parameter, the maxscale_config table is always created in the mysql database. (MXS-4499)

• In previous releases, creating the maxscale_config table in the mysql database could cause some limitations, such as the inability to create triggers on the table.

• Starting with this release, the config_sync_db parameter can be used to configure the database used to create the maxscale_config table. For backward compatibility, the default value is mysql.

QLA filter does not properly log USE statements. (MXS-4410)

When MaxScale requests the capabilities from a filter, the static capabilities are returned instead of the dynamic capabilities. (MXS-4555)

• In previous releases, for all filters except nullfilter, the static capabilities are identical to the dynamic capabilities. Therefore, the impact of this issue are minimal.

• Starting with this release, all filters return dynamic capabilities.

When connection_keepalive=0s is set for a readconnroute service, prepared statements are not tracked properly, which causes inaccurate warnings to be raised. (MXS-4552)

• In previous releases, the following warning could be incorrectly raised:

  Unknown prepared statement handler (HANDLER_ID) given to MaxScale for COMMAND by 'USER'@'HOST'
  

• Starting with this release, the prepared statements are tracked properly, so the warnings are not raised.