Release Notes for MariaDB MaxScale 23.02.1
This page is part of MariaDB's Documentation.
The parent of this page is: Release Notes for MariaDB MaxScale 23.02
Topics on this page:
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 addresslocalhost
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 theuser
parameter is used, the value ofuser_match
is ignored.user_match=/(^alice$)|(^bob$)/
user_exclude
: Exclude all queries from users that match this pattern. If theuser
parameter is used, the value ofuser_exclude
is ignored.user_exclude=/(^alice$)|(^bob$)/
source_match
: Only log queries from hosts that match this pattern. If thesource
parameter is used, the value ofsource_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 thesource
parameter is used, the value ofsource_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 |
---|---|---|
|
| Enables audit logging of the REST API. |
|
| Specifies the absolute path to the audit log, including a file extension (preferably |
|
| List of comma separated HTTP methods to exclude from logging. The supported enum values are: |
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:
MaxScale transmits a random message to the client.
The client signs the message using the password as the private key and transmits the signature to MaxScale.
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 |
---|---|---|
|
| Specifies the authentication mode to use. Two values are supported:
|
|
| Specifies the path to the RSA private key file. Only required for |
|
| Specifies the path to the RSA public key file. Only required for |
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
orbob
authenticates with MaxScale, MaxScale uses the mappeddba
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 forcarol
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 theCurrent Sessions
windowmaxctrl list sessions
exposes the metric in the newI/O Activity
columnmaxctrl show sessions
exposes the metric in the newI/O Activity
rowThe REST API exposes the metric in the new
io_activity
attribute of thesession
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;
As
SLICES
, specify the number of Slave Event Readers / Applicators that the slave Xpand cluster should create.As
MASTER_HOST
, specify the IP address or hostname of the MaxScale node used by the master Xpand cluster.As
MASTER_PORT
, specify the port of the listener used by a service using Read/Write Split Router (readwritesplit
) or ReadConnRoute Router (readconnroute
)
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:
ColumnStore Monitor (
csmon
) has been removed, because MariaDB Monitor (mariadbmon
) is the monitor used for MariaDB Enterprise ColumnStore 1.5 and later.Aurora Monitor (
auroramon
) has been removed, because it is no longer supported.
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)
In the output of the
maxctrl list sessions
command, the"Connected"
field is convertedIn the output of the
maxctrl list users
command, the"Last Login"
field is convertedIn the output of the
maxctrl show service
command, the"Started At"
and"Users Loaded At"
fields are convertedIn the output of the
maxctrl show session
command, the"Connected"
field is converted
Removed Deprecated maxctrl
Commands
In MariaDB MaxScale 23.02, some deprecated MaxCtrl commands were removed:
maxctrl drain
has been removed and can be replaced withmaxctrl set server SERVER_NAME drain
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 |
---|---|
| |
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 |
---|---|
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 |
---|---|
MaxGUI Enhancements
MariaDB MaxScale 23.02 adds enhancements for MaxGUI, including:
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 areadconnroute
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
admin_
audit global parameter addedadmin_
audit_ global parameter addedexclude_ methods admin_
audit_ global parameter addedfile admin_
jwt_ global parameter addedmax_ age auroramon monitor removed
cluster maxctrl utility removed
cluster diff maxctrl utility removed
cluster sync maxctrl utility removed
config_
sync_ global parameter addeddb csmon monitor removed
drain maxctrl utility removed
drain server maxctrl utility removed
ED25519 authenticator plugin added
grmon monitor removed
insertstream filter removed
maxctrl+create+listener
--authenticator command-line option removedmaxctrl+create+listener
--authenticator-options command-line option removedmaxctrl+create+listener
--interface command-line option removedmaxctrl+create+listener
--protocol command-line option removedmaxctrl+create+listener
--tls-ca-cert command-line option removedmaxctrl+create+listener
--tls-cert command-line option removedmaxctrl+create+listener
--tls-cert-verify-depth command-line option removedmaxctrl+create+listener
--tls-crl command-line option removedmaxctrl+create+listener
--tls-key command-line option removedmaxctrl+create+listener
--tls-verify-peer-certificate command-line option removedmaxctrl+create+listener
--tls-verify-peer-host command-line option removedmaxctrl+create+listener
--tls-version command-line option removedmaxctrl+create+monitor
--monitor-password command-line option removedmaxctrl+create+monitor
--monitor-user command-line option removedmaxctrl+create+server
--authenticator command-line option removedmaxctrl+create+server
--authenticator-options command-line option removedmaxctrl+create+server
--protocol command-line option removedmaxctrl+create+server
--tls command-line option removedmaxctrl+create+server
--tls-ca-cert command-line option removedmaxctrl+create+server
--tls-cert command-line option removedmaxctrl+create+server
--tls-cert-verify-depth command-line option removedmaxctrl+create+server
--tls-key command-line option removedmaxctrl+create+server
--tls-verify-peer-certificate command-line option removedmaxctrl+create+server
--tls-verify-peer-host command-line option removedmaxctrl+create+server
--tls-version command-line option removedmaxctrl+drain
--drain-timeout command-line option removedmaxctrl+drain+server
--drain-timeout command-line option removedmaxscale.maxscale
admin_audit
module parameter addedmaxscale.maxscale
admin_audit_exclude_methods
module parameter addedmaxscale.maxscale
admin_audit_file
module parameter addedmaxscale.maxscale
admin_jwt_max_age
module parameter addedmaxscale.maxscale
config_sync_db
module parameter addedmaxscale.maxscale
threads_max
module parameter addedMonitor.mariadbmon
backup_storage_address
module parameter addedMonitor.mariadbmon
backup_storage_path
module parameter addedProtocol.MariaDBProtocol
proxy_protocol_networks
module parameter addedthreads_
max global parameter added
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)