This release enhanced data integration and read-after-write consistency. It introduced the Kafka CDC router to stream database changes and a causal reads feature for replica servers.
MariaDB MaxScale is a database proxy that forwards database statements to one or more database servers.
The forwarding is performed using rules based on the semantic understanding of the database statements and on the roles of the servers within the backend cluster of databases.
MariaDB MaxScale is designed to provide, transparently to applications, load balancing and high availability functionality. MariaDB MaxScale has a scalable and flexible architecture, with plugin components to support different protocols and routing approaches.
MariaDB MaxScale makes extensive use of the asynchronous I/O capabilities of the Linux operating system, combined with a fixed number of worker threads. epoll is used to provide the event driven framework for the input and output via sockets.
Many of the services provided by MariaDB MaxScale are implemented as external shared object modules loaded at runtime. These modules support a fixed interface, communicating the entry points via a structure consisting of a set of function pointers. This structure is called the "module object". Additional modules can be created to work with MariaDB MaxScale.
Commonly used module types are protocol, router and filter. Protocol modules implement the communication between clients and MariaDB MaxScale, and between MariaDB MaxScale and backend servers. Routers inspect the queries from clients and decide the target backend. The decisions are usually based on routing rules and backend server status. Filters work on data as it passes through MariaDB MaxScale. Filter are often used for logging queries or modifying server responses.
A Google Group exists for MariaDB MaxScale. The Group is used to discuss ideas, issues and communicate with the MariaDB MaxScale community. Send email to maxscale@googlegroups.com or use the forum interface.
Bugs can be reported in the MariaDB Jira jira.mariadb.org
Information about installing MariaDB MaxScale, either from a repository or by building from source code, is included in the MariaDB MaxScale Installation Guide.
The same guide also provides basic information on running MariaDB MaxScale. More detailed information about configuring MariaDB MaxScale can be found in the Configuration Guide.
This page is licensed: CC BY-SA / Gnu FDL
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.
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.
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.
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.
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.
Follow the MXS-1350 Jira issue to track the progress on this limitation.
XA transactions are not detected as transactions by MaxScale. This means that all XA commands will be treated as unknown commands and will be treated as operations that potentially modify the database (in the case of readwritesplit, the statements are routed to the master).
MaxScale will not track the XA transaction state which means that any SELECT queries done inside an XA transaction can be routed to servers that are not part of the XA transaction.
This limitation can be avoided on the client side by disabling autocommit before any XA transactions are done. The following example shows how a simple XA transaction is done via MaxScale by disabling autocommit for the duration of the XA transaction.
SET autocommit=0;
XA START 'MyXA';
INSERT INTO test.t1 VALUES(1);
XA END 'MyXA';
XA PREPARE 'MyXA';
XA COMMIT 'MyXA';
SET autocommit=1;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:
set autocommit=1
PREPARE hide_autocommit FROM "set autocommit=0"
EXECUTE hide_autocommitTo ensure that MaxScale functions properly, do not commit or rollback a transaction or change the autocommit mode using a prepared statement.
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.
MariaDB MaxScale does not support KILL QUERY ID <query_id> type
statements. If a query by a query ID is to be killed, it needs to be done
directly on the backend databases.
Any KILL commands executed using a prepared statement are ignored by
MaxScale. If any are executed, it is highly likely that the wrong connection
ends up being killed.
If a KILL connection kills a session that is connected to a readwritesplit
service that has transaction_replay or delayed_retry enabled, it is
possible that the query is retried even if the connection is killed. To avoid
this, use KILL QUERY instead.
A KILL on one service can cause a connection from another service to be
closed even if it uses a different protocol.
The change user command (COM_CHANGE_USER) only works with standard authentication.
If a COM_CHANGE_USER succeeds on MaxScale yet fails on the server the session ends up in an inconsistent state. This can happen if the password of the target user is changed and MaxScale uses old user account data when processing the change user. In such a situation, MaxScale and server will disagree on the current user. This can affect e.g. reconnections.
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.
The Database Firewall filter does not support multi-statements. Using them will result in an error being sent to the client.
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.
A server can only be monitored by one monitor. Two or more monitors monitoring the same server is considered an error.
The default master selection is based only on MIN(wsrep_local_index). This can be influenced with the server priority mechanic described in the Galera Monitor manual.
Refer to individual router documentation for a list of their limitations.
This page is licensed: CC BY-SA / Gnu FDL