v0.23.6 — admin QUERY close and local start/end times

Turn MySQL ROW binlogs into incident-ready reports

Fast ROW-binlog summary: hot tables, write shapes, before/after compare. A 510 MB file is typically a few seconds. STATEMENT or MIXED files come back empty or undercounted. Printed positions are file evidence — use them as mysqlbinlog --start-position only when the span covers the transaction events, not an XID-only interval.

Install BinlogViz See output surfaces

$ binlogviz analyze --from-dir /var/lib/mysql --prefix mysql-bin. --start 2026-03-15T10:00:00Z --end 2026-03-15T10:30:00Z --format json --snapshot-name incident-current
$ binlogviz analyze --from-dir /var/lib/mysql --prefix mysql-bin. --start 2026-03-14T10:00:00Z --end 2026-03-14T10:30:00Z --format json --snapshot-name incident-previous
$ binlogviz analyze --from-dir /var/lib/mysql --prefix mysql-bin. --start 2026-03-08T10:00:00Z --end 2026-03-08T10:30:00Z --format json --snapshot-name baseline-weekly-orders
$ binlogviz trend --from-snapshots 'incident-*' --baseline-snapshot baseline-weekly-orders --format html > trend.html

4Output formats

1×Streaming pipeline

0Hosted services required

HTMLBrowser-shareable report

Why BinlogViz

Answer the operator questions that matter before the incident room loses patience

BinlogViz does not replace low-level binlog tooling. It sits one layer above it: aggregating workload shape, surfacing abnormal moments, and packaging the result so it can move cleanly into an incident review, issue thread, or postmortem.

◎

Hot tables first

See where writes concentrated instead of scanning raw row events line by line.

Large transactions surfaced

Find outsized transactions before they disappear into a long stream of ordinary noise.

↗

Spike-aware investigation

Optional spike detection points attention at the minute most likely to explain impact.

Core Workflows

Start where real binlog investigations actually begin

The value of BinlogViz is clearest at the moment somebody already has binlogs and needs answers fast: validate one file, widen to an incident window, then export something a teammate can read without replaying the whole investigation.

🗂

Validate one file quickly

Use a single binlog to prove the path, preview the default report, and sanity-check event volume fast.

⏱

Constrain the incident window

Use time, schema, and table filters to reduce noise and keep the workload story centered on the event you care about.

📄

Compare and hand the answer off cleanly

Export JSON reports from analyze, compare current versus baseline, then share the result as HTML for review, JSON for automation, Markdown for docs, or text for terminal-first debugging.

How It Works

Resolve files, aggregate in a streaming pass, render the answer in the right surface

The architecture stays intentionally direct: parse, normalize, analyze, finalize, render. That makes the tool easier to reason about and keeps the product story focused on fast-to-insight investigation instead of infrastructure complexity.

Provide filessingle file or directory range

→

Apply filterstime, schema, table, object focus

→

Get a reportalerts, summaries, charts, exports

Streaming by design

Parsing, normalization, analysis, finalization, and rendering flow forward rather than collecting every event into one giant in-memory buffer first.

Automation-safe I/O contract

Reports stay on stdout while progress and runtime status stay on stderr, so redirecting output into files or pipelines remains predictable.

Output Surfaces

Analyze locally, compare when needed, hand off in the right surface

Output format is part of the product. Analyze can end as text, JSON, Markdown, or self-contained HTML. Compare turns two exported JSON reports into a text summary, structured JSON delta, or chart-based HTML review artifact.

Preview the reporting surfaces teams actually use

Use the tabs below to see how an incident answer moves across terminals, automation, docs, and browser-based review. Compare reuses text, JSON, and HTML once two analyze JSON reports exist.

=== Workload Summary ===
transactions: 438
rows: 1,842,977
events: 28,194
time range: 2026-03-15 10:00 → 10:30 UTC

=== Top Tables ===
orders.payments      814,420 rows
orders.refunds       242,199 rows
checkout.ledger      138,501 rows

=== Alerts ===
large_transaction · txn_1842 · 17,904 rows
spike · 2026-03-15T10:14:00Z · 4.7× baseline

{
  "summary": {
    "total_transactions": 438,
    "total_rows": 1842977,
    "total_events": 28194
  },
  "alerts": [
    { "type": "large_transaction" },
    { "type": "spike" }
  ]
}

# BinlogViz Report

## Workload Summary
| Transactions | Rows | Events |
| --- | ---: | ---: |
| 438 | 1,842,977 | 28,194 |

## Top Tables
| Table | Rows | Txns |
| --- | ---: | ---: |
| orders.payments | 814,420 | 216 |
| orders.refunds | 242,199 | 104 |

Why visual compare expands the product story

HTML is no longer just a prettier analyze export. It also gives DBAs a browser-ready compare view for current-versus-baseline review, with charts that make workload changes easier to scan together.

Interactive charts summarize workload shape and current-versus-baseline deltas without requiring CLI context.
Compare HTML exposes table shifts, operation mix changes, and alert additions or removals in one review surface.
Markdown stays useful when the next destination is a wiki or incident note.
JSON remains stable for automation, downstream processing, and compare inputs.

Trust Signals

Trust the contract, not just the parser

BinlogViz already has a stronger adoption story than “it parses binlogs.” It has published docs, explicit output contracts, release notes around HTML and Markdown exports, and a product boundary that makes sense for DBAs.

📘

Documented behavior

CLI flags, output formats, architecture, and limitations are already documented in a way that supports product messaging.

📄

Stable report surfaces

Text, JSON, Markdown, and HTML make it clear where the answer can go next and who can consume it.

📦

Release-driven story

Recent releases show the project moving from core analysis toward team-facing deliverable artifacts.

🧭

Focused scope

It is not trying to be a general observability platform — and that constraint makes the positioning sharper.

Releases

Release focus and recent milestones

Keep the latest workflow release front and center, skim the last few product turns quickly, and use the archive link when you want the full history.

Current release

v0.23.6

patch release

Admin QUERY close and local start/end times

Independent management QUERY closes its GTID group, and --start/--end accept YYYY-MM-DD HH:MM:SS in the machine-local timezone.

Read release notes →

v0.23.5

XA ROLLBACK and CGO-free analyze

XA ROLLBACK closes its GTID group, default analyze no longer needs CGO or DuckDB, and JSON reports unmapped parser events.

Open v0.23.5 notes →

v0.23.4

MariaDB GRANT DDL

GRANT/REVOKE close consecutive MariaDB ddl GTIDs, table filters accept SCHEMA.TABLE, --prefix accepts a complete filename, and workflow export accepts -o.

Open v0.23.4 notes →

v0.23.3

MariaDB XA recovery

Physical XA PREPARE events retain their XA identity, and zero-row XA COMMIT transactions remain visible and selectable by GTID or position.

Open v0.23.3 notes →

v0.23.2

MariaDB XA GTID fix

Physical XA PREPARE events close their GTID group, so later XA COMMIT and unrelated transactions no longer fail analysis with a conflicting GTID.

Open v0.23.2 notes →

v0.23.1

MariaDB DDL GTID fix

Consecutive MariaDB DDL GTIDs form independent implicit groups, including under object filters, so analyze reaches the report instead of exiting on a conflicting GTID.

Open v0.23.1 notes →

v0.23.0

Incident-close evidence

Position and GTID windows, comparability-gated compare/trend, replayable file:pos evidence, and complete table/transaction output so a ROW incident can be closed without a second tool.

Open v0.23.0 notes →

v0.22.1

Operator CLI contract

HTML redirect writes stdout, STATEMENT fails with empty stdout, no-data is exit 2, MIXED JSON carries an input_format alert, and release tar.gz ships the sample ROW binlog.

Open v0.22.1 notes →

v0.22.0

HTML UI redesign

Complete visual redesign with modern dark aesthetics, sortable BINLOG BYTES physical volume in Top Tables, multi-chart synchronization, and interactive range zoom.

Open v0.22.0 notes →

v0.21.1

Operator dogfood

Text findings match JSON, MariaDB txn spans use real file positions, usable txns print mysqlbinlog commands, and the archive ships a sample ROW binlog.

Open v0.21.1 notes →

v0.21.0

HTML file output

Default HTML writes to a file instead of stdout, --output picks the destination, and Top Tables show INSERT/UPDATE/DELETE/DDL shares.

Open v0.21.0 notes →

v0.20.3

Sequential inference

Replaces unreliable offset-based last-timestamp probing with sequential inference from next file's first timestamp, making time-window filtering reliable on files of any size.

Open v0.20.3 notes →

v0.20.0

Fast discovery probing

Discovery-mode probing now uses two-phase timestamp extraction instead of full file scans, and text report sparklines are downsampled to stay readable for multi-hour windows.

Open v0.20.0 notes →

v0.18.1

Performance validation

Analyze reports keep the v0.18 DBA workflow while tightening memory and batching behavior against a real 988 MB MySQL ROW binlog smoke workload.

Open v0.18.1 notes →

v0.16.0

Analyze drilldowns

Analyze reports expand high-signal write patterns into bounded drilldown summaries with window-level context.

Open v0.16.0 notes →

v0.15.0

Trust boundary

Workflow status and resume now trust only rooted plan files inside the workflow root, blocking symlink escapes and arbitrary external plan paths.

Open v0.15.0 notes →

Release archive

All versions

Browse the full release history when you want older milestones, detailed changelogs, or download artifacts beyond the latest workflow surface.

View all release notes →

Install & Start

Install once, validate one file, widen only when the question demands it

The right onboarding path for a product site is simple and credible: install the binary, analyze one binlog, then move to ordered directory ranges and named snapshots when the incident story gets wide enough to compare against a baseline.

Quick start

                  # macOS only (Homebrew cask)
$ brew tap Fanduzi/binlogviz
$ brew install --cask binlogviz

# Linux: install.sh or tarball
$ curl -fsSLO https://raw.githubusercontent.com/Fanduzi/BinlogVisualizer/v0.23.6/install.sh
$ sh ./install.sh --version v0.23.6

# verify install with the sample ROW binlog
$ curl -fsSLO https://raw.githubusercontent.com/Fanduzi/BinlogVisualizer/main/cmd/binlogviz/testdata/minimal.binlog
$ binlogviz analyze minimal.binlog

# save current + baseline snapshots, inspect them as JSON, then open a visual compare report
$ binlogviz analyze --from-dir /var/lib/mysql --prefix mysql-bin. --start "2026-03-15T10:00:00Z" --end "2026-03-15T10:30:00Z" --format json --snapshot-name incident-current
$ binlogviz analyze --from-dir /var/lib/mysql --prefix mysql-bin. --start "2026-03-08T10:00:00Z" --end "2026-03-08T10:30:00Z" --format json --snapshot-name baseline-weekly-orders
$ binlogviz snapshot show incident-current --format json
$ binlogviz compare --current-snapshot incident-current --baseline-snapshot baseline-weekly-orders --format html > compare.html
                

What a good first session looks like

Validate one file to confirm the default report shape.
Use --from-dir and --prefix when the window spans multiple binlogs.
Add --start, --end, schema, or table filters to cut noise.
Save named snapshots when you need a baseline, inspect them as JSON when automation needs context, then use compare --format html for browser-based review.

Open repository Read docs

Make the next binlog investigation easier to explain

BinlogViz gives you a local-first path from raw MySQL ROW binlogs to an answer the rest of the incident room can actually read.

View releases Preview reports