The latest set of updates for MaxScale has just been released, among the highlights of this alpha release are improved Galera support, the introduction of the first phase of the filter API and server maintenance mode.
MaxScale has always supported Galera, at least since the earliest downloadable release, now it has the ability to use Galera in a different way.
The initial Galera support simply involved usig the Galera Monitor plugin to provide the routers with information as the the state of each of the nodes in the Galera Cluster. This meant that routing of queries could be controlled such that queries would only be sent to nodes that were fully fledged members of the cluster. No statements would get sent to a node whilst it was still joining a cluster or during state transfers.
The latest release provides a new monitor mechanism that as well as being able to report the state of the nodes within the Galera cluster will also elect one node within the cluster as a master and the remaining nodes as slaves. This then means that the routers within MaxScale which have been designed to work with MySQL Master/Slave replication can now be used with Galera Cluster, treating one of the Galera Cluster nodes as master and the others as slaves.
Using the Read/Write Splitter routing module with Galera and this monitor will then result in all the writes going to a single database node, the one that has been designated as the master. Meanwhile all of the read operations will be distributed over a number of the other nodes in the Galera Cluster. Since all the writes are sent to a single node there is no write contention. Because the backend databases are in a Galera Cluster, should the master fail, failover can take place almost instantly, once the failure is detected. There is no need to do any work on the remaining nodes to re-establish the replication. The MaxScale monitor merely detects the failure, elects a new master and write operations can continue on that master.
One of the long planned API’s for MaxScale makes an appearance in this version, the first phase of the filter API has been included. This allows filters to be added, as plugin modules, that sit between the client interface to MaxScale and the routing modules. All data that arrives via the client protocol may be passed through the filter before it is delivered to the routing module for eventual routing onwards to a database server for execution.
The filters may either inspect the content of these requests and pass them on, or the filter may modify the request and pass this modified data on to the router and ultimately the database server that will execute the request. Filters may be chained together to form processing pipelines through which requests are passed before eventual routing to a server and execution.
In the next phase of the filter API development will add the ability to filter the result set data as it comes back from the router and is sent to the client.
Included in the package are three example filters, these are unsophisticated and are really just included to demonstrate the functionality. One of these allows for the counting of statements, another provides basic logging functionality, whilst the third provides the means to use regular expressions to change the statement contents.
Server Maintenance Mode
Server maintenance mode is a very simple idea, it is just a way to tell MaxScale to ignore a particular database server for the time. The server remains in the MaxScale configuration, it merely is put into a dormant state in which MaxScale will not create any new connections to the server or issue any monitoring commands against the server. Any connections that exist to the server when it is put into maintenance mode remain, they are not closed.
The idea is that a DBA wishing to carry out some maintenance to a database would first put that database into maintenance mode, over time the connections to the database node would be closed naturally, assuming an environment in which connections are not held permanently open. Once those connections had diminished to zero, or an acceptable level, the DBA could take the database out of service and perform whatever actions are required.