MaxScale for the Rest of Us: Part 1

SkySQL released MaxScale as Open Source on github a few weeks ago. For some instructions on how to install and configure it, Ivan Zoratti has written a blog about that, and Mark Riddoch has written about why we need MaxScale here, but what I will try in a series of blogs is to describe what MaxScale is, in terms of what you can do with it, and to put it into context, so that you have an idea why you would want to install it in the first place. I will also show how to configure and manage MaxScale. This first post is a quick introduction to MaxScale.

So what is MaxScale then? Mark, and many others, call it a Proxy, and that is partly true, if you download MaxScale as it stands and start using it, it sure is a proxy, but that's underestimating the abilities of MaxScale a bit. The power of MaxScale largely lies in that is is extensible and in how effective the core of MaxScale is.

 There are 5 different types of plugins, with different properties. Some of these are always required, some are optional, but they all have some common properties:

• The MaxScale core is written in C and the Plugin API is a C API. This doesn't mean a plugin is limited to C, but the interface to MaxScale is.
• MaxScale is multi-threaded, so plugins need to be threadsafe. This is a good thing, not a restriction!
• They depend on eachother, to a large extent.
• The MaxScale core handles a lot of the basics and the routing between modules.

This means that there are a lot of things that MaxScale can do, all you need is to develop a module or two, right? Well, actually it's easier than that as there are some Modules that are already included with MaxScale.

Current MaxScale modules

The currently available modules are of two types, the ones used for development, debugging and monitoring of MaxScale and the ones that can be used for real database work.

Protocol modules

Protocol modules are key to MaxScale, these are the nodules that enable MaxScale to talk to just about anything. Currently the most important modes are the ones that implement the MySQL client and server protocol (yes, this is two separate modules). For testing and managing MaxScale there are also telnet and http protocol modules.

Authentication modules

These modules do authentication, but if you look at the current sourcecode, you realize there are no authentication modules. But authentication still takes place, as part of the MySQL protocol modules.

Monitor modules

These modules monitor the servers and keep MaxScale informed about the status of these, like which one is a master, which is running, which is a slave etc.. This information is then used by the routing modules to know to to route client traffic. There are 2 monitor modules available right now, one that monitors the master/slave status of servers and one that monitors the status of the nodes in a MariaDB Galera Cluster setup.

Filter modules

The purpose of this kind of plugin should be obvious. This module API is currently not yet implemented.

Router modules

This is the most interesting type of module, and this is where the logic of routing database traffic takes place. There are currently 3 router modules included with MaxScale, one that does read/write splitting on a cluster master/slave servers, using the monitor to keep track of which is master and slave, one that does simple load balancing and one that handles a MariaDB Galera Cluster.

MaxScale uses

As can be seen from above, MaxScale can be used for many thing potentially. What determines what it can be used for depends largely on what modules are available, potentially it can be used for protocol conversion, query filtering, high availability and load balancing, for example. As it stands with the currently available modules though, is the MySQL protocol and for query routing we can do a couple of different variations on load balancing and HA using Galera.

To be continued

The next post in this series of blogs on MaxScale will show an actual use-case and how we can solve a real-world problem using MaxScale.