This document lists known issues and limitations in MariaDB MaxScale and its
plugins. Since limitations are related to specific plugins, this document is
divided into several sections.
Configuration limitations
In versions 2.1.2 and earlier, the configuration files are limited to 1024
characters per line. This limitation was increased to 16384 characters in
MaxScale 2.1.3. MaxScale 2.3.0 increased this limit to 16777216 characters.
In versions 2.2.12 and earlier, the section names in the configuration files
were limited to 49 characters. This limitation was increased to 1023 characters
in MaxScale 2.2.13.
Multiple MaxScales on same server
Starting with MaxScale 2.4.0, on systems with Linux kernels 3.9 or newer due to
the addition of SO_REUSEPORT support, it is possible for multiple MaxScale
instances to listen on the same network port if the directories used by both
instances are completely separate and there are no conflicts which can cause
unexpected splitting of connections. This will only happen if users explicitly
tell MaxScale to ignore the default directories and will not happen in normal
use.
Security limitiations
The parser of MaxScale correctly parses WITH statements, but fails to
collect columns, functions and tables used in the SELECT defining theWITH clause.
Consequently, the database firewall will not block WITH statements
where the SELECT of the WITH clause refers to forbidden columns.
MariaDB Default Values
MaxScale assumes that certain configuration parameters in MariaDB are set to
their default values. These include but are not limited to:
autocommit: Autocommit is enabled for all new connections.
tx_read_only: Transactions use READ WRITE permissions by default.
Query Classification
Transaction Boundary Detection
If a module in MaxScale requires tracking of transaction boundaries but does not
require query classification, a custom parser is used to detect them. Currently
the only situation in which this parser is used is when a readconnroute
service uses the cache filter.
The custom parser detects a subset of the full SQL syntax used to start
transactions. This means that more complex statements will not be fully parsed
and will cause the transaction state to not match the real state on the
database. For example, SET @my_var = (SELECT 1), autocommit = 0 is not parsed
by the custom parser and causes the autocommit modification to not be noticed.
XA Transactions
MaxScale will treat statements executed after XA START and before XA END as
if they were executed in a normal read-write transaction started with START TRANSACTION. This means that only XA transactions in the ACTIVE state will be
routed as transactions and all statements after XA END are routed normally.
XA transactions and normal transactions are mutually exclusive in MariaDB. This
means that a START TRANSACTION command will fail if the connection already has
an open XA transaction. MaxScale currently only inspects the SQL and deduces the
transaction state from that. If a transaction fails to start due to an open XA
transaction, the state in MaxScale and in MariaDB can be different and MaxScale
will keep routing statements as if they were inside of a transaction. However,
as this is an unlikely scenario, usually no action needs to be taken.
Prepared Statements
For its proper functioning, MaxScale needs in general to be aware of the
transaction state and autocommit mode. In order to be that, MaxScale
parses statements going through it.
However, if a transaction is commited or rolled back, or the autocommit
mode is changed using a prepared statement, MaxScale will miss that and its
internal state will be incorrect, until the transaction state or autocommit
mode is changed using an explicit statement.
For instance, after the following sequence of commands, MaxScale will still
think autocommit is on:
To ensure that MaxScale functions properly, do not commit or rollback a
transaction or change the autocommit mode using a prepared statement.
Protocol limitations
Limitations with MySQL/MariaDB Protocol support (MariaDBClient)
Compression is not included in the server handshake.
If a KILL [CONNECTION] <ID> statement is executed, MaxScale will intercept
it. If the ID matches a MaxScale session ID, it will be closed by sending
modified KILL commands of the same type to all backend server to which the
session in question is connected to. This results in behavior that is similar
to how MariaDB does it. If the KILL CONNECTION USER <user> form is given,
all connections with a matching username will be closed instead.
Authenticator limitations
Limitations in the MySQL authenticator (MariaDBAuth)
MySQL old style passwords are not supported. MySQL versions 4.1 and newer use
a new authentication protocol which does not support pre-4.1 style passwords.
When users have different passwords based on the host from which they connect
MariaDB MaxScale is unable to determine which password it should use to connect
to the backend database. This results in failed connections and unusable
usernames in MariaDB MaxScale.
Filter limitations
Tee filter limitations (tee)
The Tee filter does not support binary protocol prepared statements. The
execution of a prepared statements through a service that uses the tee filter is
not guaranteed to succeed on the service where the filter branches to as it does
on the original service.
This possibility exists due to the fact that the binary protocol prepared
statements are identified by a server-generated ID. The ID sent to the client
from the main service is not guaranteed to be the same that is sent by the
branch service.
Monitor limitations
A server can only be monitored by one monitor. Two or more monitors monitoring
the same server is considered an error.
Limitations with Galera Cluster Monitoring (galeramon)
The default master selection is based only on MIN(wsrep_local_index). This
can be influenced with the server priority mechanic described in the manual.
Router limitations
Refer to individual router documentation for a list of their limitations.
ETL Limitations
The ETL feature in MaxScale always uses the MariaDB Connector/ODBC driver to
perform the data loading into MariaDB. The recommended minimum version of the
connector is 3.1.18. Older versions of the driver suffer from problems that may
manifest as crashes or memory leaks. The driver must be installed on the system
in order for the ETL feature to work.
The data loading into MariaDB is done with autocommit, unique_checks andforeign_key_checks disabled inside of a single transaction. This is done to
leverage the optimizations done for InnoDB that allows faster insertions into
empty tables. When loading data into MariaDB versions 10.5 or older, this can
translate into long rollback times in case the ETL operation fails.
ETL Limitations with PostgreSQL as the Source
For ETL operations that migrate data from PostgreSQL, we recommend using the
official PostgreSQL ODBC driver. Use of other PostgreSQL ODBC drivers is
possible but not recommended: correct configuration of the driver is necessary
to prevent the driver from consuming too much memory.
Limitations in Automatic SQL Generation
Triggers on tables are not migrated automatically.
Check constraints are defined using the native PostgreSQL
syntax. Incompatibilities must be manually fixed.
All indexes specific to PostgreSQL will be converted into normal indexes in
MariaDB.
ETL Limitations with Generic ODBC Targets
It is the responsibility of the end-user to correctly configure the ODBC
driver. Some drivers read the whole resultset into memory by default which will
result in MaxScale running out of memory
ETL operations that operate on more than one catalog are not supported.
This page is licensed: CC BY-SA / Gnu FDL