Galera and Master-Slave

If you use a Galera cluster but still only want to see writes on one Galera node, you can combine the two modes of operation already described. The router then works in readwritesplit mode, which causes MaxScale to make one of the Galera nodes the master, to which writes are routed. In the case of the splitter service, max_slave_connections, as in the master-slave example, ensures that MaxScale only uses a certain number of slave back ends.

By using disable_master_failback = 1 for the Galera monitor, you can also keep the master node from changing during operation when a new node enters the Galera cluster. This would be the default behavior: MaxScale would look at the WSREP_LOCAL_INDEX parameter of the node and choose the node with the lowest value for this variable as the master. If disable_master_failback is set to 1, a server will remain the master as long as it exists in the cluster.

The combination of readwritesplit and the Galera back end ultimately allows you to operate a genuine multimaster cloud that is compatible with older, non-cluster-capable applications. For larger cloud installations that use MySQL in the back end (e.g., Open Stack), the program is a genuine winner.

MaxScale CLI

MySQL now offers a variety of commands to discover the state of the database directly from the command line. MaxScale comes with its own command line (Figure 1), which mimics MySQL behavior in some way. To start the tool, you enter maxadmin. The show server command will give you an overview of the configured back end and its state.

Figure 1: With the help of maxadmin at the MaxScale command line, you can quickly discover the health of a router and its back end.

The maxadmin command also keeps internal statistics, and eventstats show displays how long various queries take on average and how high the load on the MaxScale server is at the moment (Figure 2). If you need to remove a single back end from the cluster (e.g., for maintenance purposes), you will also find a maintenance mode. Entering

set server backend1 maintenance

enables maintenance mode for backend1; the same command with clear instead of set disables maintenance mode for the node.

Figure 2: Individual back ends can be switched to maintenance mode from the command line for updates or reboots.

MaxScale as the Binlog Server

MaxScale is not only qualified to be the doorman for other MySQL back ends, it can take an active role within a cluster by acting as a source for binlogs that feed the MySQL slaves data. MariaDB calls this feature "replication proxy." In such a setup, MaxScale itself becomes the slave node for the master server in the MySQL cluster while acting as a master for more slaves. Because instances of MaxScale will scale arbitrarily, the number of potential slaves can be high.

In this function, MaxScale competes directly with MySQL. After all, any normal MySQL slave can produce binlogs and distribute them to other slave servers. The developers refer to performance problems in the MySQL version as the motivation for developing the MaxScale version.

A complete guide to the use of MaxScale as a binlog router can be found in the MaxScale GitHub directory [7]. The developers also mention that the show service <replication> command is available on maxadmin binlog servers if the local setup follows the example; otherwise, you need to replace <replication> with the name the replication service uses in the configuration. The service statistics for a binlog router reveal many important details about the replication status or the number of slaves and are thus an important source of information.

MaxScale can also be put to use for compliance and security. If you need performance logging for your database queries, you typically retrieve the data directly from the databases. However, because every query also passes through MaxScale, it can provide an accurate log, as well. MaxScale offers this feature so that admins can further reduce the load on their servers.