Database Disk Usage %, MariaDB

​

At a glance

Database Disk Usage % is the proportion of the data volume that the MariaDB instance has consumed: data files, indexes, binary logs, the InnoDB redo log, temporary files, and the undo log, divided by the total size of the volume holding the data directory. It is the single most consequential capacity metric on the instance, because when a MariaDB data volume fills completely, the server cannot write. Writes fail, replication stalls, and on many builds the server stops accepting transactions entirely until space is freed. This card exists to make sure that never happens by surface.

​

Calculation

​

Worked example

1. It is the binary logs, not the tables, that crossed the line. Table growth is steady; the jump came from 78 GB of binary logs. A read replica went offline two days ago and has not reconnected, so the primary is retaining every binary log the replica has not yet consumed. The logs cannot be purged while the replica still needs them.
2. The runway is short. At 8% free on a volume taking an overnight batch load, the headroom is hours, not days. If the batch writes another 50 GB before the logs are freed, the volume fills and the server stops writing, taking the order pipeline down.
3. There are two valid fixes, one fast and one correct. Fast: extend the volume (trivial on a managed service, a resize on self-hosted). Correct: bring the dead replica back so binary logs purge naturally, or, if the replica is gone for good, drop it from the topology so binlog_expire_logs_seconds can reclaim the 78 GB. The team does both: extends the volume to buy time, then fixes the replica.

Headroom framing for this snapshot:
  - Volume: 500 GB, used 92% (460 GB), free 44 GB
  - Dominant growth: binary logs 78 GB, pinned by an offline replica
  - Batch load remaining tonight: ~50 GB
  - Outcome if untouched: volume fills mid-batch -> writes stop -> order pipeline down
  - Fast fix: extend volume now
  - Correct fix: reconnect or remove the offline replica to purge binlogs

1. Disk usage is not the same as table size. Binary logs and undo logs can fill a volume while your tables are flat. Always check what is actually consuming the space before assuming you need a bigger database.
2. A pinned binary log is the classic silent filler. An offline or lagging replica stops binary logs from purging, and they grow without bound. Pair this card with the replication cards: a disk climb plus replication lag is almost always binlog retention.
3. The last 10% is the dangerous part. Below 90% you have planning time; above 90% you have response time. Treat the alert as “act now”, not “schedule a ticket”, because the consequence of hitting 100% is a write-down outage, not a slowdown.

​

Sibling cards

​

Reconciling against the source

At the OS level, df -h on the volume holding datadir is the ground truth for used-versus-total. This is what the card reports against. SELECT table_schema, ROUND(SUM(data_length + index_length)/1024/1024/1024, 1) AS gb FROM information_schema.TABLES GROUP BY table_schema ORDER BY gb DESC; to attribute table-and-index space by schema. SHOW BINARY LOGS; to list binary logs and their sizes; sum them to see how much of the volume they hold. SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; (or expire_logs_days on older builds) to confirm the retention policy that should be purging them. SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started; to find a long-running transaction that may be inflating the undo log.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre