Replica lag reported, although no replica configured

[SystemKeeper]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Install dbdoctor
2. Check the alerts

Expected behaviour

No alert about replication (since there's no replication)

Actual behaviour

Server configuration

Database: 12.0.2-MariaDB-deb13

[JenniferHatches]

I see this on Server version: 10.11.14-MariaDB-0ubuntu0.24.04.1-log Ubuntu 24.04 as well

[tobiasKaminsky]

Same here.

Maybe this could be changed to be an enhancement? Having replica obviously would speed it up.

[tobiasKaminsky]

On TP:
MariaDB [nextcloud]> show replica status;
Empty set (0.001 sec)

[unknown-error-maker]

I only had this with NC35.

[mafsi]

Root cause, for whoever picks this up in triage.

The rule is Slave_lag in lib/Database/RuleSet/Mysql.php:

id: 'Slave_lag',
formula: 'Slave_running',
test: 'value == 0',
issue: 'A configured replica is not running.',
requires: ['Slave_running'],

On MariaDB, Slave_running reports OFF whenever the server is not a replica connected to a primary — including when replication was never configured at all. The rule cannot distinguish "replica configured but stopped" (a real problem, worth an Alert) from "standalone server, no replication" (the normal case for most Nextcloud installs). So it fires on every replica-less MariaDB.

Measured on my instance — Nextcloud 35.0.0, serverinfo 7.0.0, MariaDB 10.11.18-0+deb12u1, no replication ever set up:

MariaDB> SHOW REPLICA STATUS\G
Empty set

MariaDB> SHOW SLAVE STATUS\G
Empty set

MariaDB> SHOW GLOBAL VARIABLES LIKE 'log_bin';
log_bin  OFF

MariaDB> SHOW GLOBAL STATUS LIKE 'Slave_running';
Slave_running  OFF

Three reasons none of the Advisor's existing escape hatches catch this:

1. requires doesn't help. Slave_running is present in SHOW GLOBAL STATUS on any MariaDB, so the "skip if the key is missing" path never triggers.
2. The privilege path doesn't help either. DatabaseProbe notes that rules needing PROCESS / REPLICATION CLIENT skip gracefully without the privilege — but Slave_running is visible to an unprivileged account. My Nextcloud DB user has only GRANT USAGE ON *.* plus ALL PRIVILEGES on its own schema, and it reads the variable fine. So pointing the checks at a lower-privileged connection does not make the rule skip.
3. The uptime gate doesn't apply. Slave_lag is not in COUNTER_SENSITIVE_RULE_IDS, so unlike the rate/ratio rules it is evaluated from the first second after a restart. There is no window where it is quiet.

Net effect: on a standalone MariaDB the check is red permanently, at Alert severity, and there is no configuration on the database side that can clear it. I went through the whole DB tuning pass on this host — every other failing check either got fixed or was explained — and this is the only one with no reachable end state.

Suggested fix: gate the rule on replication actually being configured, rather than on Slave_running alone. SHOW REPLICA STATUS returning an empty set is the unambiguous signal that there is no replica to complain about; DatabaseProbe would need to capture that (or a Slave_connections / Rpl_status style indicator) and the rule would requires it. Anything derived purely from Slave_running cannot tell the two cases apart.

Happy to test a patch against MariaDB 10.11 if that helps.

[Bad-and-Mad]

dirty hack:

apps/serverinfo/lib/Database/RuleSet/Mysql.php

test: 'value == 999',

// ── Replication ─────────────────────────────────────────────

                $rules[] = new Rule(
                        id: 'Slave_lag',
                        name: 'Replica lag',
                        category: 'Replication',
                        severity: Rule::SEVERITY_ALERT,
                        formula: 'Slave_running',
                        test: 'value == 999',
                        issue: 'A configured replica is not running.',
                        recommendation: 'Check the replica with SHOW REPLICA STATUS; resolve any IO/SQL errors and restart replication.',
                        justification: 'Slave_running is reporting OFF.',
                        justificationFormula: '',
                        requires: ['Slave_running'],
                );

Unfortunately, Nextcloud's management has shifted very strongly toward “enterprise marketing” in recent years. They are determined to prove that they can keep up with the tech giants in terms of functionality, and in doing so, they often forget their core target audience: the admins who keep the system running.

[kesselb]

Fixed by #1158