How MaxScale monitors servers

maxscale monitors serversIn this post, we’ll address how MaxScale monitors servers. We saw in the

We saw in the previous post how we could deal with high availability (HA) and read-write split using MaxScale.

If you remember from the previous post, we used this section to monitor replication:

But what are we monitoring? We are monitoring the assignment of master and slave roles inside MaxScale according to the actual replication tree in the cluster using the default check from the mysqlmon monitoring modules.

There are other monitoring modules available with MaxScale:

So back to our setup. MaxScale monitors the roles of our servers involved in replication. We can see the status of every server like this:

Now if we stop the slave, we can see:

and in the MaxScale logs:

Now if the slave is lagging, nothing happens, and we will then keep sending reads to a slave that is not up to date 🙁

To avoid that situation, we can add to the “[Replication Monitor]” section the following parameter:

If we do so, MaxScale (if it has enough privileges) will create a schema maxscale_schema  with a table replication_heartbeat . This table will be used to verify the replication lag like pt-heartbeat does.

When enabled, after we restart MaxScale, we can see the slave lag:

Does this mean that now the node won’t be reached (no queries will be routed to it)?

Let’s check:

That doesn’t sound good…