We are happy to announce the 2.1 GA release of MariaDB MaxScale, the next-generation database proxy for MariaDB.

MariaDB MaxScale 2.1 introduces the following key new capabilities.

Dynamic Configuration

• Server, monitor, and listeners: MaxScale 2.1 supports dynamic configuration of servers, monitors, and listeners, which can be added, modified or removed during runtime. A set of new commands were added to maxadmin.
• Database firewall filter: Rules can now be modified during runtime using the new module commands introduced in this release.
• Persistent configuration changes: The runtime configuration changes are immediately applied to the running MaxScale as well as persisted using the new hierarchical configuration architecture.

Security

• Selective data masking: Meet your HIPAA and PCI compliance needs by obfuscating sensitive data using the new masking filter.
• Result set limiting: Prevent access to large sets of data with a single query by using maxrows filter — securing your database servers against malicious or accidental DoS attack.
• Secured single sign-on: MariaDB MaxScale now supports LDAP/GSSAPI authentication support.
• Prepared statement filtering by database firewall: The database firewall filter now applies the filtering rules to prepared statements as well.
• Function filtering by database firewall: Now the database firewall filter adds a rule to whitelist or blacklist a query based on presence of a function.
• Secure binlog server: The binlog cache files on MaxScale can now be encrypted. MaxScale binlog server also uses SSL in communication with master and slave.

Query Performance

• Query cache filter: MariaDB MaxScale 2.1 now allows caching of query results in MaxScale for a configurable timeout. If a query is in cache, MaxScale will return results from cache before going to server to fetch query results. Our internal testing has shown 2.8x performance improvement from 2.0 to 2.1.3 using cache filter.
• Streaming insert plugin: A new plugin in MariaDB MaxScale 2.1 converts all INSERT statements done inside an explicit transaction into LOAD DATA LOCAL INFILE.

Scalability

• Aurora Cluster support: MariaDB MaxScale can now be used as a proxy for Amazon Aurora Cluster. The newly added monitor detects read replicas and write node in Aurora Cluster and supports launchable scripts on monitored events like other monitors.
• Multi-master for MySQL monitor: Now MariaDB MaxScale can detect complex multi-master replication topologies for MariaDB and MySQL environment.
• Failover mode for MySQL monitor: For a two-node master-slave cluster, MariaDB MaxScale now allows the slave to act as a master in case the original master fails.
• Read-write splitting with master pinning: MariaDB MaxScale 2.1 introduces a new “Consistent Critical Read Filter.” This filter detects a statement that would modify the database and route all subsequent statements to the master server where data is guaranteed to be in an up-to-date state.

Thanks to community members and especially OutboundEngine who beta tested MariaDB MaxScale 2.1.0 to MariaDB MaxScale 2.1.2 in order for us to reach GA with MariaDB MaxScale 2.1.3.

Links:

• Release notes
• List of bugs fixed
• Binaries
• MaxScale 2.1.3 documentation in our Knowledge Base
• Source code in GitHub tagged with maxscale-2.1.3