The MariaDB Monitor is not only capable
of monitoring the state of a MariaDB primary-replica cluster but is also
capable of performing failover and switchover. In addition, in some
circumstances it is capable of rejoining a primary that has gone down and
later reappears.
Note that the failover (and switchover and rejoin) functionality is only
supported in conjunction with GTID-based replication and initially only
for simple topologies, that is, 1 primary and several replicas.
The failover, switchover and rejoin functionality are inherent parts of
the MariaDB Monitor, but neither automatic failover nor automatic rejoin
are enabled by default.
The following examples have been written with the assumption that there
are four servers - server1, server2, server3 and server4 - of
which server1 is the initial primary and the other servers are replicas.
In addition there is a monitor called TheMonitor that monitors those
servers.
Somewhat simplified, the MaxScale configuration file would look like:
Since failover is by default not enabled, the failover mechanism must be
invoked manually:
$ maxctrl call command mariadbmon failover TheMonitor
OK
There are quite a few arguments, so let's look at each one separatelycall command indicates that it is a module command that is to be
&#xNAN;invoked,mariadbmon indicates the module whose command we want to invoke (that
is the MariaDB Monitor),failover is the command we want to invoke, andTheMonitor is the first and only argument to that command, the name of
the monitor as specified in the configuration file.
The MariaDB Monitor will now autonomously deduce which replica is the most
appropriate one to be promoted to primary, promote it to primary and modify
the other replicas accordingly.
If we now check the cluster state we will see that one of the remaining
replicas has been made into primary.
If you are continuously monitoring the server states, you may notice for a
brief period that the state of server1 is Down and the state ofserver2 is still Slave, Running.
Rejoin
To enable automatic rejoin, simply add auto_rejoin=true to the
monitor section in the configuration file.
Assuming auto_failover=true has been specified in the configuration
file, when server1 goes down for some reason, failover will be performed
and we end up with the following cluster state:
If server1 now reappears, the MariaDB Monitor will detect that and
attempt to rejoin the old primary as a replica.
Whether rejoining will succeed depends upon the actual state of the old
primary. For instance, if the old primary was modified and the changes had
not been replicated to the new primary, before the old primary went down,
then automatic rejoin will not be possible.
If rejoining can be performed, then the cluster state will end up looking
like:
Switchover is for cases when you explicitly want to move the primary
role from one server to another.
If we continue from the cluster state at the end of the previous example
and want to make server1 primary again, then we must issue the following
command:
$ maxctrl call command mariadbmon switchover TheMonitor server1 server2
OK
There are quite a few arguments, so let's look at each one separatelycall command indicates that it is a module command that is to be
&#xNAN;invoked,mariadbmon indicates the module whose command we want to invoke,switchover is the command we want to invoke, andTheMonitor is the first argument to the command, the name of the monitor
as specified in the configuration file,server1 is the second argument to the command, the name of the server we
&#xNAN;want to make into primary, andserver2 is the third argument to the command, the name of the currentprimary.
If the command executes successfully, we will end up with the following
cluster state:
