check_mysql_slavestatus monitoring plugin now supports both REPLICA and SLAVE replications

Written by - 0 comments

Published on - last updated on March 22nd 2026 - Listed in Monitoring MySQL MariaDB Databases


The monitoring plugin check_mysql_slavestatus has a special place in my Open Source heart: It's the first monitoring plugin (back then: Nagios-Plugin) I publicly released back in 2008. Today it's still alive and helps to monitor MySQL and MariaDB replications.

Monitoring database replications

The command wording has changed

But since 2008 a lot has happened. 

  • In 2008, MySQL AB, the company behind the Open Source database MySQL, was acquired by Sun Microsystems. 
  • In 2010, Sun was acquired by Oracle. This caused a lot of drama around the Open Source Code of MySQL. MySQL was forked and MariaDB was created as a real open source alternative.
  • MySQL and MariaDB remained relatively close in configuration and command syntaxes over the next few years.
  • In 2013, MariaDB introduced Multi-Source-Replication using Connection Names in its 10.0.1 release.
  • In 2015, MySQL introduced Multi-Source-Replication using Communication Channels in its 5.7.6 release.
  • In 2015 Galera Cluster, active/active database cluster architecture for MySQL and MariaDB, was released
  • In 2020, MySQL's release 8.0.22 changed the command wording from SLAVE to REPLICA (SHOW REPLICA STATUS) and MASTER to SOURCE. Besides the commands, the field names in the output changed, too.
  • In 2020, MariaDB's release 10.5.2 added aliases for SLAVE (REPLICA) and MASTER (PRIMARY). The field names in the output remained.

In the past, the check_mysql_slavestatus plugin simply used the SHOW SLAVE STATUS command to obtain information about the current replication status. But with all the wording changes, which are even different depending on the database vendor, this broke the plugin.

Plugin adjustments for versions and naming convention

More or less a year ago, a first PR was sent in the GitHub repository. However the PR only changed the wording, which would have worked for newer MySQL releases. But neither would it have worked on older MySQL releases nor for MariaDB servers. But the PR was very helpful to me to get into this topic more and understand the underlying changes. 

My two main goals of the monitoring plugins I share is: "Keep it simple" and "backward compatible". Although not always possible, I try to adjust the plugins in a way, that existing monitoring setups don't break, when a new version of the plugin is installed.

In this situation, the plugin first needs to know...

  • the database type (either MySQL or MariaDB)
  • the database version/release

... it is checking.

Checking the database type and version 

To achieve this, the plugin now uses the SELECT VERSION() command. Luckily this command is still universal and supported by both database types. 

As you could have guessed, the output looks different:

ck@mysql:~$ mysql -h localhost -u monitoring -Bse "SELECT VERSION();"
8.4.7-7 

ck@mariadb:~$ mysql -h localhost -u monitoring -Bse "SELECT VERSION();"
11.8.3-MariaDB-0+deb13u1 from Debian

From the output you can see the MySQL version just shows a version. The MariaDB version output shows the string "MariaDB" in it. This helps to differ between the two database types, without having to run yet another command. 

But due to the completely different release numbers, the plugin can't simply say "everything starting from version 8.x now uses the new wording", as MariaDB 10.1 for example still uses the old wording. 

Based on the releases that changed the Slave to Replica wording, the plugin now internally checks:

  • If this is a MySQL database server and the major release is bigger than 8, use REPLICA.
  • If this is a MySQL database server and the major release is less than 8, use SLAVE.
  • If this is a MySQL database server and the major release is 8, the minor version is 0 and the patch version is less than 22, use SLAVE.
  • If this is a MySQL database server and the major release is 8, the minor version is 0 and the patch version is 22 or higher, use REPLICA.
  • If this is a MariaDB database server and the major release is bigger than 11, use REPLICA.
  • If this is a MariaDB database server and the major release is 10, the minor version is less than 6, use SLAVE.
  • If this is a MariaDB database server and the major release is 10, the minor version is 6 or higher, use REPLICA.

Adjusting the field names

Based on the detected database type, the field wording (from the SHOW REPLICA STATUS output) also needed adjustments. In MySQL 8.0.22 and newer, the output changed:

mysql> SHOW REPLICA STATUS\G;
*************************** 1. row ***************************
Replica_IO_State: Waiting for source to send event
                  Source_Host: xxx.xxx.xxx.xxx
                  Source_User: repl
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: binlog.001215
[...]

Slave_* fields have become Replica_* fields. Master_* fields have become Source_* fields.

But MariaDB kept the old wording and only changed the command. 

Monitoring MySQL and MariaDB replications

Now with the changes in place and merged, replications on both MySQL and MariaDB can be monitored again. The plugin supports newer and older releases of both database types.

On MySQL 8.4: 

$ ./check_mysql_slavestatus.sh -H localhost -u user -p secret
OK: Replica SQL running: Yes Replica IO running: Yes / Source: xxx.xxx.xxx.xxx / Replica is 0 seconds behind Source | delay=0s

On MariaDB 10.5: 

$ ./check_mysql_slavestatus.sh -H localhost -u user -p secret
OK: Slave SQL running: Yes Slave IO running: Yes / Master: xxx.xxx.xxx.xxx / Slave is 0 seconds behind Master | delay=0s 

Enjoy :-)


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Observability   Office   OpenSearch   PHP   Perl   Personal   PostgreSQL   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder