Kudos to the SkySQL Engineering team, who released the 3rd alpha version of MaxScale, a database proxy for MySQL, MariaDB and Percona servers, labeled MaxScale 0.6.
This version comes with two important additions:
- A feature-complete read/write splitting module, i.e. read and write operations are now balanced in a smarter way to master or slave servers.
- New client-based features, such as a version string that provides compatibility with the major MariaDB and MySQL connectors, the ability to connect through the root user and the use of the unix socket when MaxScale is co-located with a client application on the same server.
Binaries and source code are “hidden” here: http://downloads.skysql.com/files/SkySQL/MaxScale.
The project is on GitHub: https://github.com/skysql/MaxScale/
Other helpful links are:
- Bugs database: http://bugs.skysql.com
- MaxScale forum: https://groups.google.com/forum/#!forum/maxscale
- IRC: irc:irc.freenode.net/maxscale
We have still some work to do before we can reach a beta stage. We definitely need to catch more bugs, but we also want to extend the features of the product. We are working on different types of load balancing, on the compatibility with Galera, MySQL Cluster/NDB, MariaDB Spider and on many other aspects.
At the moment we have two routing modules:
- The readconnroute module is a connection load balancer that accepts 2 types of connections from the client (read/write and read/only) and it balances the connections among all the masters and the slaves in a MySQL and MariaDB Cluster. This is helpful for applications that have apre-defined read/write and read/only operations. If the backend is based on a Galera Cluster, readconnroute acts as a “simple” load balancer for all the connections.
- The readwritesplit module is a statement load balancer that accepts a connection that can send read and write operations. The module parses each statement and decides whether must be sent to a master server, a slave server or all the servers. The backend is a MariaDB or a MySQL Replication cluster.
There is definitely more to come. For example, we want to provide read/write splitting for Galera clusters in order to avoid deadlocks and to guarantee read operations without replication lag. We are also working on a version that can handle slaves with different specification and clusters that can be organised on multiple locations, i.e. where there is a mix of local and remote servers. Last but not least, we are working on benchmarks to show the clear benefits of MaxScale, where it fits and where it doesn’t. in a typical IT infrastructure.
As usual, help, suggestions and comments are more than welcome.