fix(monitor): send SHOW SLAVE STATUS to MariaDB older than 10.5.1

DA
1mo ago
+21-9

Problem

The replication lag monitor chooses between SHOW SLAVE STATUS and SHOW REPLICA STATUS with a plain numeric check:

if (mysql_get_server_version(mysql) < 80023) { "SHOW SLAVE STATUS" } else { "SHOW REPLICA STATUS" }

MariaDB reports versions >= 100000 (e.g. 10.4.x -> 100400), so every MariaDB 10.x backend gets SHOW REPLICA STATUS. MariaDB only accepts that statement from 10.5.1 (MDEV-20601). On MariaDB 10.0 ā€“ 10.5.0, every replication lag check fails with ER_PARSE_ERROR (1064), so lag is never measured and max_replication_lag cannot work for those backends.

Fix

Move the choice into get_replica_status_query(). It uses 10.5.1 (100501) as the threshold when the server version string contains MariaDB, and keeps the existing 8.0.23 threshold for MySQL. Both call sites use it:

  • the async monitor path, MySQL_Monitor_State_Data::init_async() (MON_REPLICATION_LAG)
  • monitor_replication_lag_thread()

MariaDB Connector/C strips the 5.5.5- replication-compat prefix from the handshake version, so mysql_get_server_version() returns the real MariaDB version and the 100501 comparison is valid. The TEST_REPLICATIONLAG simulator branches are unchanged. Behavior for MySQL, Percona heartbeat and ReadySet is unchanged.

Testing

The commit applies cleanly to v3.0.11. I built v3.0.11 + this commit as the almalinux8 x86_64 package (upstream packaging container). Then I ran it, and the official v3.0.11 almalinux9 RPM for comparison, against mariadb:10.4 (10.4.34) and mariadb:10.6 (10.6.27). Both servers were in mysql_servers with max_replication_lag=10, and monitor_replication_lag_interval=2000.

MariaDB 10.4.34MariaDB 10.6.27
official v3.0.1113/13 checks failed: You have an error in your SQL syntax; ... near 'REPLICA STATUS' at line 10/13 errors
v3.0.11 + this PR0/63 errors0/64 errors

The backends' general logs confirm that with this PR, 10.4 receives only SHOW SLAVE STATUS and 10.6 only SHOW REPLICA STATUS.

Without the fix, the 10.4 server stays ONLINE while every check fails, and monitor_replication_lag_process_ready_tasks() logs an [ERROR] every interval. So max_replication_lag silently has no effect.

No TAP test is included: the MariaDB TAP infra (infra-mariadb10*) runs 10.11.9, which supports SHOW REPLICA STATUS, so it cannot exercise this path. Happy to add a test if you'd like a MariaDB 10.4 backend added to the infra.

šŸ¤– Generated with Claude Code

Summary by cubic

Fixes replication lag monitoring on MariaDB 10.0 through 10.5.0, where every check failed with a syntax error and max_replication_lag silently had no effect.

  • MariaDB reports versions as 100000+, so the existing >= 80023 check always sent SHOW REPLICA STATUS, which MariaDB only supports from 10.5.1.
  • The new get_replica_status_query() applies the 10.5.1 threshold for MariaDB and keeps the 8.0.23 threshold for MySQL, and is used by both the async monitor path and monitor_replication_lag_thread().
  • MariaDB is detected via the connector's mariadb_connection(), which also recognizes the -maria- version string form.
  • Behavior for MySQL, Percona heartbeat, and ReadySet is unchanged.

Summary by CodeRabbit

  • Bug Fixes
    • Replication-lag monitoring now selects the appropriate replication status command based on the database type and server version. This improves compatibility across MariaDB and MySQL versions in both synchronous and background monitoring, including servers that do not support newer status commands.