Introduction

If you are dealing with MySQL or MariaDB row-based binary logs, the key point is that the raw binlog is not directly human-readable. The correct tool for turning it into readable text is mysqlbinlog, and for row-based events you usually need verbose decoding flags as well. Without those flags, you will often only see encoded row events instead of useful before-and-after values.

Use mysqlbinlog to Decode the Binlog

The basic command is:

mysqlbinlog mysql-bin.000123

That prints the binlog in a SQL-like text form, but for row-based replication events it may still include Base64-encoded payloads that are not easy to interpret.

For row-based output, the usual command is:

mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000123

This tells mysqlbinlog to decode row events instead of leaving them in opaque encoded blocks.

Use -vv for More Detail

If you want even more detail, including column metadata comments, use double verbose mode:

mysqlbinlog --base64-output=DECODE-ROWS -vv mysql-bin.000123

This is the most common answer when someone wants to "view row-based binary logs as plain text."

Typical decoded output looks like:

1### INSERT INTO `app`.`users`
2### SET
3###   @1=101
4###   @2='[email protected]'
5###   @3='ACTIVE'

That is far easier to inspect than the raw row event payload.

Filter by Time or Position

Large binlogs are difficult to inspect all at once, so mysqlbinlog supports useful filters.

By datetime:

1mysqlbinlog \
2  --base64-output=DECODE-ROWS \
3  -vv \
4  --start-datetime="2026-03-10 10:00:00" \
5  --stop-datetime="2026-03-10 11:00:00" \
6  mysql-bin.000123

By binlog position:

1mysqlbinlog \
2  --base64-output=DECODE-ROWS \
3  -vv \
4  --start-position=120 \
5  --stop-position=980 \
6  mysql-bin.000123

These filters are essential when you are debugging one transaction or tracking one accidental data change.

Read Logs from a Remote Server

You do not always need local access to the binlog file. mysqlbinlog can read from a running server:

1mysqlbinlog \
2  --read-from-remote-server \
3  --host=db.example.com \
4  --user=replica_user \
5  --password \
6  --base64-output=DECODE-ROWS \
7  -vv \
8  mysql-bin.000123

This is useful when the database server owns the binlog files and you only have network access plus the right privileges.

Understand What Row Events Actually Show

Row-based binlogs record row changes, not the original SQL text in the same way statement-based logging does. That means you will often see output describing the affected table and column values rather than a ready-to-rerun UPDATE statement.

That is normal.

The benefit is accuracy for replication. The tradeoff is that the log is more technical to read.

Also note that how much detail appears can depend on settings such as binlog_row_image. If the server logs only minimal row images, the decoded text may not contain every column value you expect.

Common Pitfalls

The most common mistake is using plain mysqlbinlog file and expecting row events to look readable. For row-based logs, you almost always want --base64-output=DECODE-ROWS -v or -vv.

Another issue is looking for original SQL text in row-based replication logs. That is not what row mode is primarily designed to preserve.

Version mismatch can also be a problem. Use a mysqlbinlog client that is compatible with the server version that produced the log, especially when troubleshooting newer binlog features.

Finally, be careful with sensitive data. Decoded row events may expose application data directly, including values from inserted or updated rows.

Summary

• Use mysqlbinlog to view MySQL or MariaDB binary logs in text form.
• For row-based events, add --base64-output=DECODE-ROWS -v or -vv.
• Use datetime or position filters to narrow large logs to the relevant window.
• Remote decoding is possible with --read-from-remote-server.
• Row-based logs show row changes, not necessarily the original SQL statement text.