# Server diagnostics & operations

Use the Server place to connect query behavior with server evidence. The data available depends on the engine, version, effective privileges and instrumentation that is already enabled.

## Begin with Health

Health takes two counter samples per reading; live charts start after two completed readings. It refreshes itself while the view is on screen: Auto-refresh defaults to **While visible** (using the sampling window), with Off and fixed 10, 30 and 60 second intervals as the other choices; each automatic read waits one full interval after the previous read finishes, never replaces another connection's greyed report until **Refresh** (resuming the schedule afterwards), and reads immediately on return unless a failure backoff is still pending. **Capture when…** can save processlist, InnoDB status and lock evidence into an investigation when a configured condition is met.

The watcher checks only while Health is on screen and for the connection it started on. A missing measurement is reported as Not judged or Partly judged, rather than interpreted as zero.

**Is this normal?** **Save baseline** in the Refresh menu keeps the reading on screen on this computer, and **Compare with baseline** shows under each tile what it was and marks each verdict that changed. If the server restarted since, rates built from counters read Not compared, because a restart starts the counters over; Health refuses a verified server or version change between its two samples, and saving requires a verified matching identity and a reading that does not predate a detected restart. A baseline belongs to the server itself (its `server_uuid`, or host name and port on MariaDB, read in the same call as the Health or Query digest report), so it matches through any address that reaches that server; each server keeps up to 20 baselines of each kind.

## Follow a specific question

| Question | Where to look |
| --- | --- |
| What is running or holding a transaction open? | Processlist |
| Who blocks this statement or DDL? | Locks: blocking trees, metadata locks, row locks and latest deadlock |
| Where does the server wait? | Waits and InnoDB |
| Where does the server's memory go? | Memory (Workload > Resources) |
| Which files or tables are busy? | I/O |
| Which indexes need investigation? | Indexes and Tables |
| How is the server configured? | Parameters, Versions and parameter comparisons |
| What deserves a broader review? | Tuning and Full analysis report |

In Processlist, the Lock / Trx column shows the session a waiter waits on and the number of sessions a blocker holds up, and the Locked filter puts root blockers first. The **Root blocker** pill leads the Lock / Trx cell. Select a row to follow the chain and see its longest wait; a session hidden by your filters is marked (not in this list). The inspector also loads the session's recent statements when the server's statement history is on. The Kill sheet keeps **What to end** directly below **Statement to send**, including in the minimum window. Before confirming a Kill, check the selected mode: Kill query only can leave an open transaction and its locks in place; Kill connection rolls the transaction back, and another blocker can still keep a session waiting.

In Memory, choose By category, By session or By account; when categories were not collected but sessions were, it opens on By session. Values use binary units; select a row for its exact bytes, its source and the buffer pool context in its inspector. The table uses **Sum of highs** and **Share (%)**, with full names on hover; the inspector calls the former **Sum of event highs** (upper bounds, not a recorded peak), or **Session high** for MariaDB's processlist counters. A missing total high reads "sum of highs not collected". General rules of thumb appear once in the notes (ⓘ); a finding about a row has a status pill there and its reason in the inspector. Refresh takes two samples over the chosen window; growth is flagged only above both 1% of the starting total and 16 MiB, and it is a reason to inspect the workload, not proof of a leak. The 25% category rule of thumb covers only temporary tables, sort, join and hash buffers, and network. Not collected means attribution is unavailable; open Server > Instruments to review coverage. Tracked allocation bytes are not the server process's RSS or the machine's memory use. MariaDB can show allocator and session memory even with Performance Schema off.

The Full analysis report composes several diagnostic modules. Error log and Locks are outside that report's coverage; inspect those views separately.

Parameters and Users and roles show **Changed through myflames** in the selected object's inspector: the latest matching change the Audit log kept on this computer, with readable operation names (raw keys on hover), the hint "Kept on this computer.", and its stored statements in boxes with Copy beside them and the outcome. Only successful or outcome-unknown records qualify. **Open in Audit log** shows that exact record; **Show all records** returns to the full log. Where **Undo** is offered for a parameter, it opens the usual review with the earlier value filled in; review the current server and the exact statement before confirming. This history covers only changes made through myflames on this computer, and an index's history matches only records that name that index: a change recorded against the whole table is not attributed to one index.

## Replication, clusters and maintenance

Dedicated places inspect replication channels, GTIDs, workers and lag; MariaDB Galera, Percona XtraDB Cluster, MySQL InnoDB Cluster and Group Replication; ProxySQL backend pools, query rules and digests; and Readyset shallow and deep caches, proxied queries, base-table snapshotting, dynamic parameters and performance telemetry across ProxySQL + Readyset + MySQL or MariaDB topologies.

Maintenance finds the MySQL and MariaDB tools on this computer as soon as it opens and runs upgrade checks, dumps, restores and MySQL CLONE. In **Tools**, **Used for this server** names the program, version, origin and selection reason for queries, dumps, restores and MySQL Shell when selected, with warnings for missing or older tools. The list below shows every copy found, including its path and origin. **Change…** opens **Client tools**, also available from **Settings > Client tools…**, where **Automatic (best match for each server)** or a chosen installation applies separately to MySQL and MariaDB servers. SQL restores and CLONE use the client from the selected dump installation; a missing program in a chosen installation is reported without substituting another installation. **Start dump…**, **Start restore…** and **Start clone…** check first (reading only), then show the exact commands for you to confirm. When no client tool can run a dump or restore for the server (for example a MariaDB server on a computer without MariaDB client tools), the tab names the missing program, with **Choose client tools…**, instead of starting. The dump **Tool** list offers only tools that can run, and **Automatic** names `mysqldump` when no MySQL Shell is installed. A running job shows a progress bar, the step it is on and the elapsed time. MySQL Shell reports its own percent. `mysqldump` and `mariadb-dump` print nothing, so for them the bar is an estimate ("≈46%") from the bytes written to `dump.sql` against the server's table sizes, while that estimate exists and the output stays below it; otherwise the bar keeps moving without a percent. The job card also shows the bytes written and, once measurable, the rate. A compact summary beside the Start button shows the job's state, the percent when known and the bytes written, with **Show progress** to jump to the job card. A dump you started opens its folder in Finder when it completes, and **Open in Finder** opens it again; on Windows, use **Open in File Explorer**. In **Upgrade check**, the target list comes from the vendor: MySQL Community versions from the official release notes, Percona Server versions from Percona's package repositories. It offers only releases on a supported upgrade path (patches of your series, the next LTS series, and Innovation releases before it), newest first, with the newest release of the next LTS chosen for you. Under the list, myflames says how the server was installed (RPM packages, DEB packages, Ubuntu's own package or a generic archive, with the evidence under **How this was decided**) and what that means: which repository publishes the target, or for Percona the `percona-release enable-only` command for the target's repository. Releases Oracle removed from download, or published only as a Docker image, are left out. Offline, MySQL targets come from the releases bundled with myflames. Account management and protected server changes require review. Read the [write-safety guide](https://myflames.io/docs/safety.md) before taking an action.

New dumps suggest a dated folder inside **Documents/myflames dumps** in your home folder (`%USERPROFILE%\Documents\myflames dumps` on Windows). If Documents does not exist, the default is **myflames dumps** directly in your home folder. A parent used by an earlier dump in the same window takes precedence; **Browse…** chooses another existing parent. Suggesting a path creates nothing. When the default parent is missing, the review says `Creates the folder <path>.` and confirming the dump creates it. Other missing parent folders are refused, and a linked Documents folder cannot be used to create the default.

A picked-tables SQL dump can restore after its source database was dropped. If the chosen target database is missing, the review includes its `CREATE DATABASE` before loading, using the source character set and collation recorded in newer dump manifests (older manifests use server defaults with a warning). Choosing the dump folder reads its manifest first. **New database…** is offered only when the dump can load into another database: a picked-tables dump with no CREATE DATABASE, CREATE SCHEMA, USE or database-qualified reference, or a single-schema Shell table dump. Otherwise **Default database** offers only **As in the dump**, with the reason under it. For a very large dump the restore review decides. Whole-database SQL dumps restore into the databases named in the dump. Review the target and commands before confirming. A load that fails before its session marker reports that nothing was loaded; after the marker, inspect the target because part of the dump may be loaded.

**Tables > Fragmentation** ranks InnoDB tables by Reclaimable bytes (the free extents a rebuild could return) and shows Fragmentation % beside it. Select a table for its **Rebuild** statements, `OPTIMIZE TABLE` and `ALTER TABLE ... ENGINE=InnoDB`, to copy or open in the Query editor, plus a variant that is refused instead of blocking writes. Read the notes first: both rebuild online unless the table has a FULLTEXT or SPATIAL index, they need free disk about the size of the table, and replicas rebuild too. Fragmentation counts whole free extents only, so pages that are partly empty are not included.

An unused-index finding is a candidate to investigate, not proof that dropping the index is safe. Collection windows, restarts, instrumentation and less frequent workloads all affect the evidence.

## Move files over SSH

**File transfer**, in the sidebar after Tuning, moves logs, dumps and configuration files between this computer and your servers over SSH/SFTP, in two panes side by side. It does not use the database connection in use: save **SSH connections** of their own (host, port, user, and sign-in with your SSH agent, a key file or a password; on Windows, the SSH agent or a key without a passphrase), or start one from a saved database connection or a `~/.ssh/config` alias. The first connection to a server shows its host key fingerprint to compare before you trust it. Right-click a saved SSH connection to open, edit, duplicate, test, copy or delete it, and a file of this computer to show it in Finder or File Explorer. Drag files between the panes or from Finder. Transfers show their progress, with the rate and time left when known; a running transfer has **Cancel**, and a failed or cancelled one has **Retry**. On Windows, uploads and downloads are not available yet.