You are here
Wed, 2014-02-12 08:09
It seems that in all the writing around what MaxScale is, why I think we need it and what we plan to do with it, we have created some confusion as regards what it can do as of today, mid-February 2014. So I thought I would try to clear it up a little my writing this short post. The version that is described here is the one that is available from SkySQL download site and is labelled as version 0.4, later code is available in GitHub, with the changes we are working on, but I will not cause more confusion by referring to these. Our design concept for MaxScale is a core with five plugin interfaces that provide different functionality, currently we have a core, that supports the event driven model we wanted, but we have only implemented three of the five plugin interfaces. The interfaces that have been implemented are the protocol plugin, the query router and the monitor. The authentication mechanism we are using currently is built into the core, not the long term goal but something we have done in order to get a version that we can start sharing with everyone. The authentication offers the standard MySQL authentication protocol, the client applications authenticate themselves with MaxScale and then MaxScale will deal with the authentication between itself and the backend databases. The username and password used to authenticate with MaxScale are extracted from the backend database, in the 0.4 version the client host information is not checked, this is considered a bug which is being worked on. The core also includes the MariaDB parser which is used by the routers or other modules via an interface we call the query classifier. This allows us to extract the read, write or session modification properties of the statement. The result is that we can create routers such as the read/write splitter that we have, but more of this in a moment.
Protocol ModulesCurrently we have a number of protocol modules, the two most important of these are the MySQL Client protocol and the MySQL Backend protocol modules. The client protocol module is used by client applications that connect to MaxScale. In this case MaxScale acts as a server and offers a full implementation of the MySQL protocol with the exception that does not support compression or SSL. We currently turn off these capabilities in the handshake we perform with the clients. The MySQL Backend protocol module is designed to allow MaxScale to attach to a MySQL, MariaDB or Percona Server database. It operates as the client side of the protocol, although it differs from a normal connector since it is designed to take data in a way that is more efficient for the proxy activities it is performing. In particular if we are doing connection based routing we want to take advantage of having the ready made packet formats. The combination of these two protocol modules means that the only database clients and servers we can support with the version 0.4 are those that talk the MySQL protocol. In addition to these two protocol modules used for database connections we have a telnet protocol module that we use for a debugging interface and an experimental HTTP protocol implementation.
Routing ModulesWe have two routing modules currently, a connection based router and a statement based router. The connection based router is known as the readconnrouter, which is perhaps not the best name for it. What this router can do is evenly distribute connections between a set of servers, it keeps a count of the number of connections that are currently open to a server via MaxScale and uses this to find the server that has the least number of connections. If multiple servers have the same number of connections then it will round-robin between these servers. The connection router can be configured with some options, these options are used to decrease the set of servers that it will consider when it looks for the server to which connections are routed. The options supported in the 0.4 version are;
- master - Only route to servers that are marked as replication masters
- slave - Only route to servers that are marked as replication slaves
- synced - Only route to servers that are marked as synced, in a Galera cluster
- Session modification commands may result in multiple returns begin sent to the client for a single statement
- Very long statements that require multiple packets fail to parse and are thus always routed to the master
- Prepared statements and the execution of prepared statements may not always occur on the right server
- Transaction support is currently missing - a transaction should be execute on a single server
- The choice of master and slave server is currently only done as connect time, if the master moves the connection to the client will be failed. Reconnection to the new master should be handled by the router without intervention by the client.