Announcing MariaDB MaxScale 2.3 GA

We are happy to announce the general availability of MariaDB MaxScale 2.3.2. MariaDB MaxScale is the key application-facing component for MariaDB Platform X3, also announced today. MariaDB MaxScale serves as the integrated data access entry point of MariaDB Platform that hybrid transactional and analytical processing (HTAP) applications connect to.

MariaDB MaxScale/ HTAP Architecture Diagram

MariaDB MaxScale 2.3 allows applications to send a query to the same port on a single platform without having to decide whether a query is transactional or analytical. MaxScale dynamically routes application queries that are transactional to MariaDB Server running InnoDB (or MyRocks) and application queries that are analytical to the MariaDB ColumnStore storage engine. Additionally in MariaDB Platform X3, MaxScale also ensures that both InnoDB and ColumnStore have visibility to the same data. Thus analytical queries performed by applications on the MariaDB Platform provides analytics on “in flight” transactions as they are occuring, rather than after-the-fact analytics. This hybrid approach enables several use cases, including:

  • Personalized upselling to customers across multiple channels (in-store, in-app, online, email promotion) by retail business
  • Optimized inventory levels across stores
  • Datacenter and network operational optimization

In an upcoming blog, we will dive deeper into these hybrid use cases that MariaDB Platform enables. Other new features available in MariaDB MaxScale 2.3 include:

Reliability

  • Transparent query connection failover: Applications do not experience connection loss during failover of master in backend database cluster. Two new option of master_reconnection and transaction_replay in Read Write Split Router
  • Seamless data streaming from Multi-node Galera Cluster via binlog server: Continuous data streaming from Galera cluster even in case of a node failure without manual intervention.
  • ColumnStore Monitor: The new csmon monitor can be used to monitor ColumnStore clusters versions 1.2.1 and newer. This monitor that holistically checks the status of the entire Columnstore cluster before routing queries to the UM nodes.

Scalability

  • Adaptive Routing based on Server Load conditions: Routing based on actual load conditions of servers as measured by response time and probabilistic selection. A new slave_selection_critera value of ‘ADAPTIVE_ROUTING’ in Read Write Split router.
  • Binlog filtering: A new filter module that allows the client side stream of binlogs to be filtered.
  • Table Family Sharding: The SchemaRouter is now capable of table family sharding.

Read consistency

  • Always consistent reads: A new causal_reads parameter that enables distributed consistent reads with MariaDB version 10.2.16 and newer.

Security

  • Robust data masking that cannot be bypassed by calling a function on a masked column. e.g. ‘SELECT masked_column FROM table_x’ as well as ‘SELECT UPPER(masked_column) FROM table_x’ will prevent masked_column data from being exposed

Ease of use

  • Comment Filter: A new comment filter to prepend statement received with a comment before it is sent further to a server. Please see the comment filter documentation for more details.
  • Syslog Improvements: It is now possible for the end user to specify the syslog facility and level for authentication errors.  
  • MaxCtrl: There is now a new command classify <statement> to check if and how MaxScale classifies a specific statement.
  • Watchdog: Systemd Watchdog can be enabled to monitor and take corrective action if MaxScale process hangs for more than watchdog duration.  

For additional details, please see the release notes. Also, look for more blogs that further dive into these capabilities in the coming days and weeks.