Build a Safe MariaDB Status Report with mariadb-report

Staring at raw SHOW STATUS output is a fast way to miss the number that matters, which is what mariadb-report exists to fix. You will finish with a repeatable way to turn MariaDB status counters into a readable report, either from a live server or from saved data. The examples use mariadb-report v4.0 from Ubuntu's mariadb-client package, version 1:10.11.14-0ubuntu0.24.04.1. The older local manpage documents the core report options, while the installed command also provides relative reports.

Allow about fifteen minutes. You need the client package and credentials that can read the server status and variables. The normal report is read-only. One option, --flush-status, changes server counters, so it gets its own section below.

1. Check the installed command

Confirm which executable will run and record its built-in version text:

$ command -v mariadb-report
/usr/bin/mariadb-report
$ mariadb-report --help
mariadb-report v4.0 Oct 23 2015
mariadb-report makes an easy-to-read report of important MySQL/MariaDB status values.

Here is a fact worth knowing: the package also installs the historical name mysqlreport. On this machine it is a symlink to mariadb-report, so either name reaches the same program. Use the MariaDB name in new scripts so the command and package stay easy to identify.

Checkpoint: if command -v finds nothing, stop and install the client package through your normal package-management process. Do not copy a script from an unrelated host to fill the gap.

2. Run a live report without putting a password in history

Give the connection details that differ from your local defaults, then let the command prompt for the password:

$ mariadb-report --host db.example.test --port 3306 --user report_reader --password
Password for database user report_reader:

Warning: the installed help also accepts a password argument, but --password SECRET can expose the secret through shell history or process inspection. Prefer a protected ~/.my.cnf entry or the interactive prompt. The command reads ~/.my.cnf by default; add --no-mycnf when testing a connection that must ignore that file.

The output is a formatted view of many values from SHOW STATUS, with derived figures such as ratios. It is not a diagnosis on its own: read a value against workload, uptime and the server configuration behind it.

3. Select the useful report sections

The basic report is deliberately broad. Add sections when you have a specific question to answer:

$ mariadb-report --user report_reader --password --dtq --dms --com 5 --sas --tab

--all is a shortcut for --dtq --dms --com 3 --sas --qcache. It does not include --tab. The --qcache section is about the query cache, so its absence or zeroes say nothing about InnoDB buffering.

Checkpoint: save the exact command and its time whenever you compare reports. Counters are cumulative until the server resets them, so two isolated reports on their own can mislead you.

4. Read a saved status snapshot

Use --infile when a live connection is unavailable or you want a reproducible test. The input can hold copied SHOW STATUS output plus the server variables the report needs:

$ mariadb-report --no-mycnf --infile /path/to/status-snapshot.txt

Each status entry needs a name made of letters and underscores plus a positive integer. The recognised configuration lines use name = value for version, table_cache, max_connections, key_buffer_size and query_cache_size. An M suffix means mebibytes in this parser: 18M is 18 multiplied by 1024 squared, not 18 million bytes.

If those five values are missing, the documented defaults kick in: 0.0.0, 64, 100, 8M and 0. They can produce strange or unhelpful figures. Keep the snapshot and the command output together so a later reader can tell whether the report used real server variables.

Warning: do not put a password or a full client configuration in a snapshot. It should hold status and variable values only. Protect any saved report, because it can reveal workload or host details.

5. Compare intervals with the installed v4.0 options

The local manpage is dated 2006 and does not list the newer relative-report options the installed command actually offers. For a live interval report, pass seconds to --relative and choose how many reports to collect:

$ mariadb-report --user report_reader --password --relative 60 --report-count 3
Password for database user report_reader:

This asks for three live reports, 60 seconds apart. The command's help gives --report-count's default as one. A relative report is useful for rates and changes, but it keeps a connection open and samples the server repeatedly, so pick an interval that is reasonable for the host.

For saved comparisons, give --relative a list of input files instead:

$ mariadb-report --relative before.txt after.txt

The files are processed in the order supplied. Make sure they were captured with compatible server-variable context. If you need more detail while investigating, --debug prints diagnostic information, including temporary-file activity; treat that output as operational data.

6. Save the report without overwriting an old one

Use --outfile to write a copy after printing the report:

$ mariadb-report --user report_reader --password --outfile /var/tmp/mariadb-report-2026-09-25.txt
Password for database user report_reader:

Choose a new destination or check it first. The program uses a temporary file internally, then copies the report to the requested output, so shell redirection is not needed. If the destination sits in a protected directory, run the command as the account that can write there rather than making the database connection root for no reason.

The --email ADDRESS option hands the report to /usr/sbin/sendmail. Use it only once you understand the local mail path and recipient handling, since reports can disclose database activity. Check the resulting file or mail through your normal operational controls.

7. Avoid resetting counters by accident

Safety warning: --flush-status runs FLUSH STATUS after generating the report. That changes the server's status counters and may need database permission. It can wreck the meaning of monitoring comparisons, so keep it out of any routine collection command.

If you deliberately need a new counter baseline, record the old report first, announce the maintenance action, then run:

$ mariadb-report --user report_reader --password --flush-status
Password for database user report_reader:

Recovery: there is no inverse command that restores the previous counter values. Recovery means keeping the pre-flush report and starting a fresh measurement window. If the command reports a database error after printing, check account privilege and the server audit trail before retrying.

Done means