DOCS-6581 Document the replica gate on automatic binlog purge

[mariadb-stefan-hinz]

Reported by Shawn Green in #docs-talk, filed by Tauseef Khan as DOCS-6581. Both items in the ticket, plus two drive-by fixes the verification turned up.

1. The binlog maintenance page never mentioned the gate

slave_connections_needed_for_purge gates every automatic purge Using and Maintaining the Binary Log describes — max_binlog_total_size, binlog_expire_logs_seconds and expire_logs_days alike — and appeared nowhere on it. The default is 1, so a primary with no connected replica never purges automatically and its disk can fill up even when expiry is configured correctly.

Added a warning that names the three mechanisms, the default (1, and 0 on Galera cluster nodes), the error-log note each refusal writes, and the escape hatch.

Executed rather than reasoned about, on the live 12.3.3 server with zero dump threads and 34 binlogs: SET GLOBAL binlog_expire_logs_seconds=60; FLUSH BINARY LOGS; deleted nothing, and the error log got exactly the note the page now quotes.

2. The :mm: emoji — already "fixed" by deleting the minutes

GITBOOK-2395 (adc902e87, 2026-09-03) removed the Hungarian flag from the format string by removing mm, leaving `YYYY-MM-DD hh:ss` — no emoji, and no minutes either. Restored to `YYYY-MM-DD hh:mm:ss`, code-spanned so the shortcode cannot parse.

The ticket asked for a grep for other unfenced occurrences: two, both in the datetime guide's format-specifier list (%r, %T), now code-spanned. Every other hh:mm:ss in the repo is already inside a fence or a code span.

3. Manual purge vs. the gate — the ticket's version claim was wrong twice

The ticket said manual PURGE BINARY LOGS was blocked in 11.4.0–11.4.2. Both bounds are wrong and so is the scope:

• The variable arrives with 18dfcfdecf4 (MDEV-31404), first released in 11.4.1 — there is no 11.4.0 behavior to describe.
• Per MDEV-34504's own commit message, only PURGE BINARY LOGS BEFORE observed the limit; TO ignored it from the start.
• dd997809679 (MDEV-34504) first ships in 11.4.3, after which can_purge_log() passes 0 for an interactive purge.

But it does not end there, and this is the part a reader hitting it needs: the short circuit at sql/log.cc:6592 sits before the interactive check and caches the last failed purge, so a manual purge of a file whose automatic purge was just refused is refused too — reported as it is the current active binlog when it is not. Reproduced live (two refusals against …-bin.000001 while …-bin.000035 was active), and cleared by writing to the variable, after which the same statement purged. Documented as observed.

Server-side finding, not fixed here: that wrong reason string looks like an MDEV worth filing.

Drive-by fixes

• slave_connections_needed_for_purge's documented range carried a ulonglong max (18446744073709551615). It is a Sys_var_uint with VALID_RANGE(0, UINT_MAX), and the live server reports 4294967295.
• Three missing spaces on the PURGE BINARY LOGS page, KB→GitBook migration debris: "name ordate", "synonyms.Deleted", "MASTER).To".

Verification

Source: mariadb-server @ b2a8c2234dbc276fe3947633c9ffea454badf48f (ref main). Oracle: live 12.3.3-MariaDB-log. Eleven claims — 8 VERIFIED, 3 CORRECTED, 0 UNVERIFIED; the full fact-check report goes on the ticket at handoff.

Local checks: doc-lint.sh (4 files) clean, codespell clean, lychee 401 links / 0 errors, fragcheck new origin/main reports no new dead anchors.

Not verified: the passing side of the gate (enough replicas connected → purge proceeds) is source-read only, since there is no replica here.