Designing for MaxScale's Xpand Monitor

MaxScale's Xpand Monitor (xpandmon) monitors nodes in Xpand deployments.

Additional information is available .

Prior to MaxScale 6, Clustrix Monitor (clustrixmon) was used.

Understanding MaxScale's Xpand Monitor

MaxScale's monitors nodes in Xpand deployments.

What Does the Xpand Monitor Support?

The supports:

• Monitoring Xpand deployments.

_{This page is: Copyright © 2025 MariaDB. All rights reserved.}

In MariaDB MaxScale, monitors perform the following tasks:

• Deciding whether a server is up or down.

• Deciding whether a server is the primary server or a replica server.

• Performing automatic failover when the primary server fails (for certain kinds of deployments).

Overview

MaxScale's Aurora Monitor (auroramon) monitors the status of Aurora cluster replicas.

EXTERNAL REFERENCES

Additional information is available .

_{This page is: Copyright © 2025 MariaDB. All rights reserved.}

Overview

MaxScale's monitors deployments.

This page contains topics that need to be considered when designing applications that use the MariaDB Monitor.

Additional information is available .

MaxScale's monitors the status of Aurora cluster replicas.

What Does the Aurora Monitor Support?

The supports:

• Monitoring replicas in Amazon Aurora deployments

MaxScale's (mariadbmon) monitors deployments.

What Does the MariaDB Monitor Support?

The supports:

• Monitoring

MaxScale's MariaDB Monitor (mariadbmon) monitors deployments.

When the primary server fails, MariaDB Monitor can promote a replica server to be the new primary server automatically.

How MariaDB Monitor uses Cooperative Locks

When automatic failover is enabled for MariaDB Monitor, it does the following:

1. It selects the replica server with the latest GTID position to be the new primary server.

2. If the new primary server has unprocessed relay logs, then it cancels and restarts the failover process after a short wait.

3. It prepares the new primary server:

• It stops its replica threads by executing and .

• It configures it to allow writes by setting to OFF.

• If the handle_events parameter is true, then it enable events that were previously enabled on the old primary server.

1. It redirects all replica servers to replicate to the new primary server:

• It stops its replica threads by executing and .

• It configures that replication by executing and .

1. It checks that all slaves are replicating properly by executing .

Configuring Automatic Failover

1. Configure automatic failover by configuring several parameter for the MariaDB Monitor in maxscale.cnf.

For example:

1. Restart the MaxScale instance.

_{This page is: Copyright © 2025 MariaDB. All rights reserved.}

MaxScale's MariaDB Monitor (mariadbmon) monitors deployments.

When multiple MaxScale instances are used in a highly available deployment, MariaDB Monitor needs to ensure that only one MaxScale instance performs automatic failover operations at a given time. It does this by using cooperative locks on the back-end servers.

How MariaDB Monitor uses Cooperative Locks

When cooperative locking is enabled for MariaDB Monitor, it tries to acquire locks on the back-end servers with function. If a specific MaxScale instance is able to acquire the lock on a majority of servers, then it is considered the primary MaxScale instance, which means that it can handle .

Configuring Cooperative Locking

1. Configure cooperative locking by configuring the cooperative_monitoring_locks parameter for the MariaDB Monitor in maxscale.cnf. It has several possible values.

For example:

1. Restart the MaxScale instance.

_{This page is: Copyright © 2025 MariaDB. All rights reserved.}

Designing for MaxScale's Galera Monitor

MaxScale's Galera Monitor (galeramon) monitors Galera Cluster deployments.

This page contains topics that need to be considered when designing applications that use the Galera Monitor.

• ?

Additional information is available .

Understanding MaxScale's Galera Monitor

MaxScale's monitors deployments.

What Does the Support?

The Galera Monitor (galeramon) supports:

• Monitoring deployments

• Monitoring deployments

• Query-based load balancing with the

• Connection-based load balancing with the Read Connection Router (readconnroute)

Deploying Galera Monitor

• Deploy MaxScale with Galera Monitor and Read/Write Split Router

• Deploy MaxScale with Galera Monitor and Read Connection Router

Using SST Donors for Queries with MaxScale's Galera Monitor

MaxScale's monitors .

By default, when a node is chosen as a donor for a State Snapshot Transfer (SST), Galera Monitor does not route any queries to it. However, some SST methods are non-blocking on the donor, so this default behavior is not always desired.

Non-Blocking SST Methods

A cluster's SST method is defined by the system variable. When this system variable is set to mariadb-backup, the cluster uses to perform the SST. is a non-blocking backup method, so Galera Cluster allows the node to execute queries while acting as the SST donor.

Configuring Availability of SST Donors

1. Configure the availability of SST donors by configuring the available_when_donor parameter for the Galera Monitor in maxscale.cnf.

For example:

1. Restart the MaxScale instance.