Release Notes for MariaDB MaxScale 2.5.20

Overview

MariaDB MaxScale is an advanced database proxy, firewall, and query router.

MariaDB MaxScale 2.5.20 was released on 2022-05-10. This release is of General Availability (GA) maturity.

Notable Changes

  • Many internal MaxScale threads have been named, so that they can be easily differentiated during profiling and debugging. (MXS-3997)

  • When a client tries to connect to MaxScale using TLS ciphers that are unsupported or disabled on the MaxScale node, MaxScale will write more detailed error messages to the MaxScale error log. (MXS-3665)

    • Starting with this release, the following error message can be written to the MaxScale error log:

    error  : (34) SSL operation failed for Client DCB at 'CLIENT_IP': error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher (Client ciphers: CLIENT_CIPHER_LIST) (Our ciphers: MXS_CIPHER_LIST)
    
    • The Client ciphers section is only logged when the MaxScale node uses OpenSSL 1.1.1 or later.

  • A new maxctrl create report command has been added. (MXS-4045)

    • When the maxctrl create report command is executed, MaxScale generates a report describing the state of all MaxScale objects in JSON format and saves the output to a file. The report can be helpful in issue diagnosis and troubleshooting.

Issues Fixed

Can result in a hang or crash

  • When the Cache Filter (cache) uses Redis for storage and timeout > 0 is configured on the Redis node, Redis can close MaxScale's idle connections, and MaxScale can crash when it tries to clear the cache. (MXS-3954)

Can result in unexpected behavior

  • When the Cache Filter (cache) is used and an uncacheable statement is executed as part of a multi-statement query (such as SELECT * FROM tab1 WHERE ..; SELECT * FROM tab2 WHERE ..), the statement's results can be improperly cached. (MXS-4053)

    • Starting with this release, the Cache Filter will not cache any results for multi-statement queries.

  • When handle_events is enabled for MariaDB Monitor (mariadbmon), but event_scheduler is disabled for the server, an error message is repeatedly written to the MaxScale error log. (MXS-4040)

    • Starting with this release, the error message will only be written to the MaxScale error log once.

    • In previous releases, the following error could be repeatedly written to the MaxScale error log:

    error  : [MONITOR] Could not query events of 'SERVER': Query 'SELECT Event_schema, Event_name FROM information_schema.EVENTS WHERE Status = 'ENABLED';' failed: 'Cannot proceed, because event scheduler is disabled'. Event handling can be disabled by setting 'handle_events' to false.
    
  • With the MaxScale Xpand Monitor (xpandmon), the status of the bootstrap server is not always the same as the status of corresponding runtime servers: (MXS-4074)

    • Starting with this release, the state of the bootstrap server is updated from the runtime servers at every Monitor tick independent of the state of the health check round.

    • Prior to this release, the Monitor tick for the bootstrap server status could occur during a health check of the runtime servers. The health check is independent of the Monitor tick.

  • Query classifier cache does not properly record all used memory which can cause memory usage to exceed configured value of query_classifier_cache_size. (MXS-4008)

  • When users_refresh_time > 0 is configured, maxctrl reload service does not bypass the rate limit. (MXS-4038)

  • When the KILL statement is executed, a race condition could sometimes cause the statement to be discarded. (MXS-4004)

  • When the KILL statement is executed and log_info is enabled, no details of the operation are logged. (MXS-4002)

  • Binlog Router (binlogrouter) creates malformed replication events which can cause the binlogfilter to error out if it encounters such an event. (MXS-4000)

  • When the Cache Filter (cache) uses Redis for storage and timeout > 0 is configured on the Redis node, Redis can close MaxScale's idle connections, which could cause subsequent cache activity to fail and the following error message to be written to the MaxScale log: (MXS-4001)

    error  : [storage_redis] Failed to read reply in the context of MULTI: general error, Server closed the connection
    error  : [storage_redis] Failed when reading response to MULTI: no error, Server closed the connection
    
  • When a TLS certificate has usage flags via the X509v3 Extended Key Usage extension, MaxScale does not verify that the certificate has the correct usage flags: (MXS-3931)

    • Starting with this release, if a TLS certificate has usage flags via the X509v3 Extended Key Usage extension, MaxScale will check the usage flags and refuse to use a certificate with the wrong usage.

    • A certificate that only has the clientAuth flag can only be used with servers.

    • A certificate that only has the serverAuth flag can only be used with listeners.

    • A certificate that has both the clientAuth and serverAuth flags can be used with servers and listeners.

  • Under heavy loads, REST API requests can take too long. (MXS-3808)

  • When the Avro router (avrorouter) is used, reading an Avro file can fail with Sync marker mismatch. (MXS-3945)

  • The schemarouter does not work with MariaDB Enterprise Server 10.6 unless the ignore_tables_regex is used to exclude it from duplicate checks. The sys schema was added in MariaDB Enterprise Server 10.6 but was not added to the list of database names that are automatically ignored by MaxScale. (MXS-4110)

  • With the REST API, the /user/inet endpoint fails schema validation when used with the newest schema for the JSON API specification. (MXS-4109)

  • If the Binlog Router (binlogrouter) is used with a password that is encrypted with maxpasswd and select_master=true, authentication fails. (MXS-4103)

    • Starting with this release, the binlogrouter, avrorouter, and kafkacdc will always decrypt the master password before using it.

    • Prior to this release, the binlogrouter, avrorouter, and kafkacdc did not decrypt the master password before using it.

  • Executing the SHOW SLAVE STATUS statement via the Maxscale Binlog Router (binlogrouter) does not show SSL information. (MXS-4096)

  • User account manager does not detect database-level privilege changes when fetching user accounts and grants from the server. (MXS-4093)

    • If a login to MaxScale fails and user account fetching is not limited by "users_refresh_time", MaxScale fetches user accounts and grants from the server and checks if the new data differs from existing data and updates its cache if yes.

    • Starting with this release, changes are detected properly and will cause the grant database to update.

    • Prior to this release, the comparison operation does not correctly detect changes in the mysql.db array.

  • Duplicate table errors for tables where the table names are in different cases, for example table.t1 and table.T1 (MXS-4092)

    • Starting with this release, MaxScale schemarouter compares table and database names case-sensitively. This means that the tables test.t1 and test.T1 are seen as different tables.

    • Prior to this release MaxScale schemarouter compares table and database names case-insensitively which could cause duplicate tables to be found if the server supports case-sensitive table names.

  • The REST API is inaccessible after deleting the last user. (MXS-4086)

    • Starting with this release, it is no longer possible to delete all the REST API users. There will always be one user, "the last user", remaining.

    • Prior to this release, it is possible to delete every user of the REST API which would leave the REST API inaccessible.

  • Stale connections are not cleared from the persistent connection pool. The persistmaxtime module parameter is only checked when a new connection is created or an old one is closed, so if no new connections are created, stale connections are not cleared. (MXS-4034)

    • Starting with this release, the pool is cleaned periodically independent of activity.

  • The CDC protocol in the Avrorouter (avrorouter) logs the following MXS_NOTICE for each new connection. This gives inappropriate importance to the message. (MXS-4024)

    2022-02-23 07:49:02   notice : [CDC] (CDC-Listener) CDC-Router: new connection from [::1]
    
    • Starting with this release, new connections will be logged with a MXS_INFO message.

  • The Avro router (avrorouter) and the Kafka CDC Router (kafkacdc) do not log an error for failed SHOW CREATE TABLE. This can make it difficult to find the source of a problem. (MXS-4022)

    • Starting with this release, a failed SHOW CREATE TABLE statement will be indicated with a MXS_ERROR.

Platforms

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

  • SUSE Linux Enterprise Server 15 (x86_64, ARM64)

  • Ubuntu 18.04 (x86_64, ARM64)

  • Ubuntu 20.04 (x86_64, ARM64)