Replica lag reported, although no replica configured #1135

Activity

1. SystemKeeper

   added

   0. Needs triage

   bug

   on Aug 15, 2026
2. JenniferHatches commented on Aug 25, 2026

   

   JenniferHatches

   on Aug 25, 2026

   More actions

   I see this on Server version: 10.11.14-MariaDB-0ubuntu0.24.04.1-log Ubuntu 24.04 as well
3. tobiasKaminsky commented on Aug 28, 2026

   

   tobiasKaminsky

   on Aug 28, 2026

   Member

   More actions

   Same here.

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

   transferred this issue fromnextcloud/dbdoctoron Sep 11, 2026
5. tobiasKaminsky commented on Sep 11, 2026

   

   tobiasKaminsky

   on Sep 11, 2026

   Member

   More actions

   On TP:
   MariaDB [nextcloud]> show replica status;
   Empty set (0.001 sec)
6. unknown-error-maker commented on Sep 16, 2026

   

   unknown-error-maker

   on Sep 16, 2026

   More actions

   I only had this with NC35.
7. mafsi commented on Sep 17, 2026

   

   mafsi

   on Sep 17, 2026

   More actions

   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.
8. Bad-and-Mad commented on Sep 17, 2026

   

   Bad-and-Mad

   on Sep 17, 2026

   Last edited by Bad-and-Mad

   More actions

   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.
9. kesselb commented on Sep 30, 2026

   

   kesselb

   on Sep 30, 2026

   Collaborator

   More actions

   Fixed by #1158
10. kesselb

    closed this as completedon Sep 30, 2026
11. kesselb

    marked serverinfo "Replica lag" check (Slave_running) always fails on standalone (non-replica) MySQL/MariaDB servers #1170 as a duplicate of this issue on Sep 30, 2026