Release Notes for MariaDB MaxScale 23.02.1

Overview

MariaDB MaxScale is an advanced database proxy and query router. MaxScale is a component of MariaDB database products.

MariaDB MaxScale 23.02.1 was released on 2023-03-20. This release is of General Availability (GA) maturity. MaxScale 23.02.1 is the first GA release in this release series.

This document describes the changes in MaxScale 23.02.1 when compared to MaxScale 22.08.4.

Inbound Proxy Protocol

MariaDB MaxScale 23.02 adds support for listeners to receive inbound proxy protocol traffic from other MaxScale nodes or from other load balancers, which allows authentication to be simplified when another MaxScale node or another load balancer is relaying client connections to MaxScale. (MXS-3003)

In previous releases, MaxScale supported outbound proxy protocol traffic between MaxScale and the database nodes, but it did not support inbound proxy protocol traffic for listeners.

Starting with this release, MaxScale listeners can receive inbound proxy protocol traffic if the proxy_protocol_networks parameter is configured for the listener. Set the proxy_protocol_networks parameter to a comma-separated list of IP addresses and subnets that are authorized to send proxy protocol traffic to the listener:

[rw-listener]
type=listener
service=rw-service
protocol=MariaDBClient
port=3306
proxy_protocol_networks=192.168.0.1,198.168.0.0/16
  • Subnets must be in CIDR format (such as 192.168.0.0/16)

  • A wildcard (*) allows proxy protocol traffic from any address

  • localhost allows proxy protocol traffic from domain socket connections

When a MaxScale listener receives proxy protocol traffic from another MaxScale node or another load balancer, the proxy header contains the original client IP address and port. MaxScale use the original client IP address for authentication. If outbound proxy protocol traffic is also enabled between the MaxScale node and the database nodes, MaxScale uses a proxy header to relay the original client IP address and port to the database nodes as well. If the proxy protocol is used between the MaxScale node and the other load balancer and between the MaxScale node and the database nodes, both the MaxScale node and the database nodes know the original client IP address and port, and both can use this information for authentication.

Since the proxy protocol affects authentication, only trusted IP addresses and subnets should be added to the proxy_protocol_networks parameter.

When the proxy protocol is enabled for a listener, the listener still accepts connections that do not use the proxy protocol.

Backup and Restore for MariaDB Monitor

MariaDB MaxScale 23.02 adds support to MariaDB Monitor (mariadbmon) for the async-create-backup and async-restore-from-backup module commands, which can be used to create and restore backups. (MXS-3262)

Configuration

MariaDB Monitor requires configuration to create and restore backups:

[mdb-monitor]
type=monitor
module=mariadbmon
servers=server1,server2,server3
user=database_user
password=database_pwd
backup_storage_address=192.0.2.1
backup_storage_path=/backups
ssh_user=backup_admin
ssh_keyfile=/home/maxscale/.ssh/id_rsa
ssh_port=44
  • The backup_storage_address parameter configures the IP address or hostname of the server where the backups are stored.

  • The backup_storage_path parameter configures the directory where the backups are stored.

  • The ssh_user parameter configures the user account that is used to SSH to the database node being backed up and to the backup server.

  • The ssh_keyfile parameter configures the private key file that is used to SSH to the database node being backed up and to the backup server.

  • When a non-standard SSH port is used, the ssh_port parameter configures the TCP port that is used to SSH to the database node being backed up and to the backup server.

Requirements

  • The SSH user used by MaxScale requires sudo access on both the database node being backed up and the backup server.

  • MaxScale requires the following tools to be installed on both the database node being backed up and the backup server:

    • MariaDB Enterprise Backup

    • pigz

    • socat

Create and Restore Backups

To backup a server, execute maxctrl call command mariadbmon and specify the async-create-backup module command:

$ maxctrl call command mariadbmon async-create-backup mdb-monitor server1 20230222161011-backup-mdb-monitor-server1

To restore a server from a backup, execute maxctrl call command mariadbmon and specify the async-restore-from-backup module command:

$ maxctrl call command mariadbmon async-restore-from-backup mdb-monitor server2 20230222161011-backup-mdb-monitor-server1

Backups and restores are asynchronous operations, so MaxCtrl does not wait for the operation to complete and instead immediately returns "OK".

To see the current status of an operation, either check the MaxScale log or execute maxctrl call command mariadbmon and specify the fetch-cmd-result-command module command:

$ maxctrl call command mariadbmon fetch-cmd-result mdb-monitor

Preserve Replication Position

MariaDB MaxScale 23.02 adds support to MariaDB Monitor (mariadbmon) for preserving the value of the MASTER_USE_GTID option after a switchover or failover. (MXS-4398)

When changing the primary on a node that was already a replica node, MariaDB Monitor uses the value of MASTER_USE_GTID that was being used prior to the switchover or failover.

When configuring replication on a node that was previously the primary node, MariaDB Monitor uses MASTER_USE_GTID=current_pos.

Dynamic Worker Thread Changes

MariaDB MaxScale 23.02 adds support for dynamically changing the number of worker threads used to route client traffic without restarting MaxScale. (MXS-3269)

As part of this change, MaxScale no longer assumes that the number of CPUs on the system is a constant value. This change helps improve MaxScale support in environments using virtualization or containerization, where the the number of CPUs available can be changed.

To change the number of worker threads dynamically, change the value of the threads parameter using the maxctrl alter maxscale sub-command:

$ maxctrl alter maxscale threads=2

The new threads_max parameter can be used to configure the hard limit for the number of worker threads. The default value is 256. The threads_max parameter can't be changed dynamically.

On startup, if the value of the threads configuration parameter is greater than the value of threads_max, the value of threads is reduced to the value of threads_max, and a warning is raised:

MaxScale can have at most THREADS_HARD_LIMIT routing threads; the request for THREADS_REQUESTED will be reduced to that. The maximum can be increased with `threads_max`.

At runtime, if the value of threads is set higher than the value of threads_max, an error is raised:

MaxScale can have at most THREADS_HARD_LIMIT routing threads; a request for THREADS_REQUESTED cannot be honored. The maximum can be increased with `threads_max`.

Cache Filter Enhancements

MariaDB MaxScale 23.02 contains some enhancements to the Cache Filter (cache).

Dynamic Configuration Changes

MariaDB MaxScale 23.02 adds support for dynamically changing the Cache Filter (cache) configuration without restarting MaxScale. (MXS-3708)

The following parameters have been changed to dynamic, so that they can be changed with the maxctrl alter filter sub-command:

When the configuration changes, the cache rules are reloaded. If any rules have changed, the changes are applied. This means that you can intentionally force your rules to be reloaded using the maxctrl alter filter sub-command to alter the rules parameter, but specifying the parameter's existing value, so that it does not actually change:

$ maxctrl alter filter rw-cache rules='/path/to/rules-file'

Password Authentication with Redis Cache

MariaDB MaxScale 23.02 adds support for Redis password authentication when the Cache Filter (cache) is configured to use Redis. (MXS-4106)

When storage=storage_redis is configured, the storage_options parameter has the following optional arguments to enable password authentication:

  • The username argument specifies the username to use for authentication.

  • The password argument specifies the password to use for authentication.

For example:

[rw-cache]
type=filter
module=cache
storage=storage_redis
storage_options = "server=127.0.0.1, username=alice, password=PASSWORD"

[rw-service]
type=service
router=readwritesplit
servers=server1,server2,server3
user=mxs
password=PASSWORD
filters=rw-cache

[rw-listener]
type=listener
service=rw-cache
protocol=mariadbclient
port=3306

Since the arguments for the storage_options parameter are separated by commas (,), neither the username nor the password can contain commas.

If the Redis server is configured to use the older form of Redis authentication, then only the password must be provided. With the older form of Redis authentication, a system-wide Redis password is configured by writing the requirepass directive to redis.conf.

If the Redis server is configured to use the newer form of Redis authentication, then a username and password must be provided. With the newer form of Redis authentication, usernames and passwords are created by executing the ACL SETUSER command.

When Redis password authentication is enabled, MaxScale authenticates with Redis by executing the AUTH command after the connection is established.

For additional details about password authentication with Redis, see "Redis security: Authentication".

TLS Encryption with Redis Cache

MariaDB MaxScale 23.02 adds support for TLS encryption between MaxScale and the Redis server when the Cache Filter (cache) is configured to use Redis. (MXS-4107)

When storage=storage_redis is configured, the storage_options parameter has the following optional arguments to enable TLS encryption:

  • The ssl argument specifies whether TLS encryption should be used.

  • The ssl_key argument specifies the path to the non-encrypted PKCS #8 private key file in PEM format.

  • The ssl_cert argument specifies the path to the X.509 certificate file in PEM format.

  • The ssl_ca argument specifies the path to the X.509 certificate authority chain file in PEM format.

For example:

[rw-cache]
type=filter
module=cache
storage=storage_redis
storage_options = "server=127.0.0.1, ssl=true, ssl_cert=/etc/ssl/maxscale/mxs-cert.pem, ssl_key=/etc/ssl/maxscale/mxs-key.pem, ssl_ca=/etc/ssl/maxscale/ca.pem"

[rw-service]
type=service
router=readwritesplit
servers=server1,server2,server3
user=mxs
password=PASSWORD
filters=rw-cache

[rw-listener]
type=listener
service=rw-cache
protocol=mariadbclient
port=3306

Redis considers TLS encryption to be an optional feature that must be enabled at compile time. Before enabling TLS encryption for Redis, confirm that your Redis binaries were built with TLS enabled.

For additional details about TLS encryption with Redis, see "Redis: TLS".

Query Log All (QLA) Filter Enhancements

MariaDB MaxScale 23.02 adds support to the QLA Filter for filtering users and sources with regular expressions (regex). (MXS-4302)

The following parameters can be used:

  • user_match: Only log queries from users that match this pattern. If the user parameter is used, the value of user_match is ignored.

    user_match=/(^alice$)|(^bob$)/
    
  • user_exclude: Exclude all queries from users that match this pattern. If the user parameter is used, the value of user_exclude is ignored.

    user_exclude=/(^alice$)|(^bob$)/
    
  • source_match: Only log queries from hosts that match this pattern. If the source parameter is used, the value of source_match is ignored.

    source_match=/(^127[.]0[.]0[.]1)|(^192[.]168[.]0[.]109)/
    
  • source_exclude: Exclude all queries from hosts that match this pattern. If the source parameter is used, the value of source_exclude is ignored.

    source_exclude=/(^127[.]0[.]0[.]1)|(^192[.]168[.]0[.]109)/
    

Semi-Synchronous Replication for Binlog Router

MariaDB MaxScale 23.02 adds support for semi-synchronous replication to the Binlog Router. (MXS-3004)

With semi-synchronous replication, the primary server waits to commit a transaction until one replica server has acknowledged that they have received and logged the event. In previous releases of MaxScale, the Binlog Router is not able to provide this acknowledgment.

Starting with this release, when semi-synchronous replication is enabled on the primary server, the Binlog Router is able to provide the acknowledgments to the primary server. The router automatically detects when semi-synchronous replication is enabled on the primary server and automatically provides the correct acknowledgments. No special configuration is required in MaxScale.

Audit Log for REST API

MariaDB MaxScale 23.02 adds support for an audit log for the REST API. (MXS-3827)

The following parameters have been added to configure this feature:

Parameter

Type

Description

admin_audit

Bool

Enables audit logging of the REST API.

admin_audit_file

String

Specifies the absolute path to the audit log, including a file extension (preferably .csv).

admin_audit_exclude_methods

EnumList

List of comma separated HTTP methods to exclude from logging. The supported enum values are: GET, PUT, POST, PATCH, DELETE, HEAD, OPTIONS, CONNECT, and TRACE. Currently MaxScale ignores CONNECT and TRACE when they are specified.

To dynamically configure the parameters without restarting MaxScale, use the maxctrl alter maxscale sub-command:

$ maxctrl alter maxscale admin_audit_file=/var/log/maxscale/2023-02-admin_audit.csv
$ maxctrl alter maxscale admin_audit=true

Similar to the MaxScale log, the audit log for the REST API can also be rotated. However, unlike the MaxScale log, the audit log for the REST API is never overwritten when a rotation occurs.

ed25519 Authentication

MaxScale 23.02 adds support for ed25519 authentication. (MXS-4270)

MaxScale's ed25519 authentication is compatible with the ed25519 authentication plugin from MariaDB Enterprise Server.

When a client authenticates with MaxScale using ed25519, the following exchange occurs:

  1. MaxScale transmits a random message to the client.

  2. The client signs the message using the password as the private key and transmits the signature to MaxScale.

  3. MaxScale verifies the signature using the public key stored for the user.

Throughout this exchange, the client's password is never transmitted to MaxScale.

This authentication method does have a downside for MaxScale. MaxScale requires a password to login to the database nodes on behalf of the client. Since MaxScale never receives the client's password, one of the following options is required:

  • Option 1: MaxScale must store the password somewhere

  • Option 2: MaxScale must use a different authentication method between the client and MaxScale, so that MaxScale can obtain the password from the client

MaxScale's implementation of ed25519 authentication supports both alternatives. Option 1 is ed_mode=ed25519 and option 2 is ed_mode=sha256.

Authenticator Options

MaxScale 23.02 adds the following arguments for the authenticator_options parameter that can be used to configure ed25519 authentication:

Authenticator Option

Type

Description

ed_mode

String

Specifies the authentication mode to use. Two values are supported:

  • ed25519 (default): Use ed25519 authentication between the client and MaxScale, but use another authentication method between MaxScale and the database nodes. Requires a user mapping file containing passwords. The user mapping file is configured by the user_mapping_file parameter.

  • sha256: Use caching_sha2_password authentication between the client and MaxScale, but use ed25519 authentication between MaxScale and the database nodes. Requires either TLS encryption or an RSA key-pair. The RSA key-pair is configured by the ed_rsa_privkey_path and ed_rsa_pubkey_path arguments for the authenticator_options parameter.

ed_rsa_privkey_path

String

Specifies the path to the RSA private key file. Only required for ed_mode=sha256 when TLS is not used.

ed_rsa_pubkey_path

String

Specifies the path to the RSA public key file. Only required for ed_mode=sha256 when TLS is not used.

ed_mode=ed25519

When ed25519 authentication is enabled for a listener in ed25519 mode, MaxScale uses ed25519 authentication between the client and MaxScale, but it uses another authentication method between MaxScale and the database nodes. The other authentication method is pulled from the user mapping file.

To enable ed25519 authentication for a listener in ed25519 mode, specify authenticator=ed25519auth and authenticator_options="ed_mode=ed25519" and configure the path to the user mapping file with the user_mapping_file parameter:

[rw-listener]
type=listener
address=::
service=rw-service
authenticator=ed25519auth
authenticator_options="ed_mode=ed25519"
user_mapping_file=/etc/maxscale/user_mapping.json

The user mapping file specifies the user mappings and specifies the user names, passwords, and authentication methods to use for authenticating with the database nodes:

{
   "user_map": [
      {
         "original_user": "alice",
         "mapped_user": "dba"
      },
      {
         "original_user": "bob",
         "mapped_user": "dba"
      }
   ],
   "server_credentials": [
      {
         "mapped_user": "dba",
         "password": "PASSWORD",
         "plugin": "mysql_native_password"
      },
      {
         "mapped_user": "carol",
         "password": "PASSWORD",
         "plugin": "mysql_native_password"
      }
   ]
}

The passwords can be encrypted with maxpasswd, or the passwords can be in clear-text.

In the example above:

  • When alice or bob authenticates with MaxScale, MaxScale uses the mapped dba user with the specified password and authentication method to authenticate with the database nodes.

  • When carol authenticates with MaxScale, there is no mapped user, so MaxScale uses the password and authentication method specified for carol without performing any user mapping.

ed_mode=sha256

When ed25519 authentication is enabled for a listener in sha256 mode, MaxScale uses ed25519 authentication between MaxScale and the database nodes, but it uses caching_sha2_password authentication between the client and MaxScale. To use this mode, either TLS encryption or an RSA key-pair are required. The RSA key-pair is configured by the ed_rsa_privkey_path and ed_rsa_pubkey_path arguments for the authenticator_options parameter.

To enable ed25519 authentication for a listener in sha256 mode, specify authenticator=ed25519auth and authenticator_options="ed_mode=sha256" and configure the paths to the RSA key-pair:

[rw-listener]
type=listener
address=::
service=rw-service
authenticator=ed25519auth
authenticator_options="ed_mode=sha256,ed_rsa_privkey_path=/etc/ssl/maxscale/sha_private_key.pem,ed_rsa_pubkey_path=/etc/ssl/maxscale/sha_public_key.pem"

Alternatively, instead of configuring the paths to an RSA key-pair, TLS can be configured:

[rw-listener]
type=listener
address=::
service=rw-service
authenticator=ed25519auth
authenticator_options="ed_mode=sha256"
ssl=true
ssl_key=/etc/ssl/maxscale/mxs-key.pem
ssl_cert=/etc/ssl/maxscale/mxs-cert.pem
ssl_ca=/etc/ssl/maxscale/ca.pem

Monitor Session I/O Load

MaxScale 23.02 adds support for displaying I/O activity for each session and the relative I/O compared to the total I/O of all sessions. (MXS-4182)

The new details are available in the following interfaces:

  • MaxGUI exposes the metric in the new I/O Activity column has been added to the Current Sessions window

  • maxctrl list sessions exposes the metric in the new I/O Activity column

  • maxctrl show sessions exposes the metric in the new I/O Activity row

  • The REST API exposes the metric in the new io_activity attribute of the session object

The I/O activity metric is calculated using the number of I/O operations performed by the session during the previous 30 seconds. Since the value is an aggregate of I/O activity over the previous 30 seconds, very short peaks might not appear in the data.

Xpand Parallel Replication

MariaDB MaxScale 23.02 adds support for Xpand parallel replication to Read/Write Split Router (readwritesplit) and ReadConnRoute Router (readconnroute). (MXS-4330)

With Xpand parallel replication, Xpand uses multiple Slave Event Readers / Applicators on multiple nodes to independently stream and apply replication traffic. Since each Slave Event Reader / Applicator operates independently in parallel, the full power of the cluster is used without any choke points. When compared to serial replication, Xpand's parallel replication is more effective at keeping up with high write rates while reducing latency and slave lag.

Using MaxScale as a load balancer for Xpand parallel replication provides some operational benefits, including:

  • MaxScale can automatically distribute Slave Event Reader / Applicator connections between multiple Xpand nodes to spread out load

  • If an Xpand node fails, MaxScale can detect the failure and re-route failed replication connections to healthy nodes

Configuration

To configure Xpand parallel replication with MaxScale, use the CREATE SLAVE statement on the slave Xpand cluster:

CREATE SLAVE parallel_repl
   PARALLEL_LOG = xpand-bin,
   PARALLEL_POS = 0,
   SLICES = 6,
   BATCH_SIZE_MS = 1000,
   MASTER_HOST = MAXSCALE_ADDRESS,
   MASTER_PORT = MAXSCALE_PORT,
   MASTER_USER = repl,
   MASTER_PASSWORD =  PASSWORD;

For additional information about how to configure parallel replication with Xpand, see "Configure Parallel Replication with MariaDB Xpand".

Supported Routers

Xpand parallel replication is supported by Read/Write Split Router (readwritesplit) and ReadConnRoute Router (readconnroute).

MariaDB recommends using ReadConnRoute Router (readconnroute) for Xpand parallel replication, but Read/Write Split Router (readwritesplit) can also be used.

For both routers, Slave Event Reader / Applicator connections are routed in similar ways:

  • When a client connects to Read/Write Split Router (readwritesplit) with MariaDB Xpand, MaxScale initializes the session by connecting to a single Xpand node. Xpand Monitor (xpandmon) labels all cluster nodes as "Master", so any node is a viable connection target. For each new client connection, readwritesplit connects to the node that has the lowest connection count.

  • When a client connects to ReadConnRoute Router (readconnroute) with MariaDB Xpand, MaxScale initializes the session by connecting to a single Xpand node. For each new client connection, readconnroute connects to the node that has the lowest connection count.

As more and more clients connect, both routers connect to Xpand nodes in a round-robin manner. Therefore, when Xpand parallel replication is used with either router, the Slave Event Reader / Applicator connections should be distributed between multiple nodes in the master Xpand cluster.

Monitoring

MaxScale considers the Slave Event Reader / Applicator connections to be regular connections, so the connections can be monitored with the following commands:

Removed Deprecated Monitors

In MariaDB MaxScale 23.02, some deprecated monitors were removed:

maxctrl Enhancements

MariaDB MaxScale 23.02 contains some enhancements for MaxCtrl.

Client Time Zone

In MariaDB MaxScale 23.02, MaxCtrl converts timestamp fields to the timezone of the terminal's locale: (MXS-4320)

Removed Deprecated maxctrl Commands

In MariaDB MaxScale 23.02, some deprecated MaxCtrl commands were removed:

Removed Deprecated maxctrl Options

In MariaDB MaxScale 23.02, several deprecated MaxCtrl command-line options were removed, because the command-line options are redundant, since MaxScale previously added the ability to specify module parameters to MaxCtrl as key-value pairs. (MXS-4266)

This change can impact backward compatibility. Some scripts and tools written for previous versions of MaxCtrl will require updates to continue functioning with MaxCtrl from MaxScale 23.02. The old command-line parameters have been deprecated since MaxScale 22.08. The new syntax to specify parameters as key-value pairs has been supported since MariaDB MaxScale 6.2.0.

For example, in previous releases, the following maxctrl create monitor command could be executed:

$ maxctrl create monitor mdb_monitor mariadbmon \
   --monitor-user mxs \
   --monitor-password 'maxscale_passwd' \
   replication_user='repl_user' \
   replication_password='repl_pass' \
   --servers node1 node2 node3

Starting with this release, some deprecated command-line options have been removed and must be replaced with a key-value pair using the corresponding module parameter:

$ maxctrl create monitor mdb_monitor mariadbmon \
   user='mxs' \
   password='maxscale_passwd' \
   replication_user='repl_user' \
   replication_password='repl_pass' \
   --servers node1 node2 node3

For maxctrl create listener, the following deprecated command-line options were removed and must be replaced with a key-value pair using the listed parameter:

Command-line Option

Replaced by Parameter

--authenticator

authenticator

--authenticator-options

authenticator_options

--interface

interface

--protocol

protocol

--tls-ca-cert

ssl_ca

--tls-cert

ssl_cert

--tls-cert-verify-depth

ssl_cert_verify_depth

--tls-crl

ssl_crl

--tls-key

ssl_key

--tls-verify-peer-certificate

ssl_verify_peer_certificate

--tls-verify-peer-host

ssl_verify_peer_host

--tls-version

ssl_version

For maxctrl create monitor, the following deprecated command-line options were removed and must be replaced with a key-value pair using the listed parameter:

Command-line Option

Replaced by Parameter

--monitor-password

password

--monitor-user

user

For maxctrl create server, the following deprecated command-line options were removed and must be replaced with a key-value pair using the listed parameter:

Command-line Option

Replaced by Parameter

--authenticator

authenticator

--authenticator-options

authenticator_options

--protocol

protocol

--tls

ssl

--tls-ca-cert

ssl_ca

--tls-cert

ssl_cert

--tls-cert-verify-depth

ssl_cert_verify_depth

--tls-key

ssl_key

--tls-verify-peer-certificate

ssl_verify_peer_certificate

--tls-verify-peer-host

ssl_verify_peer_host

--tls-version

ssl_version

MaxGUI Enhancements

MariaDB MaxScale 23.02 adds enhancements for MaxGUI, including:

  • MaxGUI includes a ETL/Data Migration service GUI. (MXS-4430)

  • The Query Editor schema sidebar displays views, functions, triggers and indexes in addition to tables and procedures. (MXS-4013)

  • MaxGUI remembers and restores user settings such as window sizes from a previous session. (MXS-4285)

Issues Fixed

Can result in unexpected behavior

  • 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 ("//") was not handled as empty, but the empty string ("").

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

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

  • When a connection associated with a Query Editor tab is disconnected, the tab can become unusable. (MXS-4490)

Interface Changes

Platforms

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

  • Red Hat Enterprise Linux 9 (x86_64, ARM64)

  • Rocky Linux 8 (x86_64, ARM64)

  • Rocky Linux 9 (x86_64, ARM64)

  • SUSE Linux Enterprise Server 15 (x86_64, ARM64)

  • Ubuntu 18.04 (x86_64, ARM64)

  • Ubuntu 20.04 (x86_64, ARM64)

  • Ubuntu 22.04 (x86_64, ARM64)