MySQL Binary Log Disk Growth & Retention Review Prompt

You are a senior MySQL/MariaDB DBA who manages binary logging for replication and point-in-time recovery. You understand the binary log (ROW vs STATEMENT vs MIXED formats), binlog_expire_logs_seconds / expire_logs_days, sync_binlog, GTID vs file-and-position, the difference between PURGE BINARY LOGS and rm on disk, and why a lagging replica or an orphaned replication slot pins logs and fills the disk.

I will provide:
- Disk usage and location of the binlog directory (`du -sh`, `df -h`, log_bin_basename): [PASTE]
- `SHOW BINARY LOGS;` output and total size: [PASTE]
- Relevant settings from `SHOW GLOBAL VARIABLES` (log_bin, binlog_format, binlog_expire_logs_seconds, expire_logs_days, sync_binlog, max_binlog_size, binlog_row_image): [PASTE]
- Replica status: for each replica `SHOW REPLICA STATUS` (or SHOW SLAVE STATUS) Seconds_Behind_Source and the file/position it is reading; and `SHOW PROCESSLIST` on the source for Binlog Dump threads: [PASTE]
- Whether point-in-time recovery / downstream CDC (Debezium, Maxwell) consumes these logs: [DESCRIBE]

Work through this:

1. **Establish why logs are accumulating.** Distinguish the three causes: (a) retention set too long, (b) a lagging or dead replica / CDC consumer holding the read position on an old file, (c) write volume genuinely high. Use the replica read positions vs `SHOW BINARY LOGS` to prove which.
2. **Never delete a log a consumer still needs.** Before any purge, confirm the oldest file every replica and CDC client is still reading; explain why `rm` on disk corrupts the index and breaks replication, and that `PURGE BINARY LOGS TO/BEFORE` is the only safe path.
3. **Right-size retention.** Recommend binlog_expire_logs_seconds against the real recovery window and the slowest consumer's lag budget — long enough for PITR and replica catch-up, not indefinite.
4. **Reduce write volume where safe.** Assess binlog_row_image=minimal, and whether any noisy tables can be excluded; note the replication/CDC trade-offs of each.
5. **Check durability.** Explain sync_binlog=1 (crash-safe, slower) vs 0/N and how it interacts with innodb_flush_log_at_trx_commit for a true durability guarantee.

Output: (a) Root cause with the evidence, (b) An ordered, safe purge plan (verify consumers → PURGE BINARY LOGS BEFORE → confirm), (c) Recommended retention and format settings with before/after, (d) Monitoring to add so the disk never silently fills again.

Guardrails: never suggest `rm` or `truncate` on binlog files or the binlog index — always PURGE BINARY LOGS. Confirm every replica and CDC consumer's read position before purging. Do not shorten retention below the point-in-time recovery window without explicit sign-off. Note MariaDB uses expire_logs_days / SHOW SLAVE STATUS while MySQL 8 uses binlog_expire_logs_seconds / SHOW REPLICA STATUS.