Skip to main content

VillageSQL is a drop-in replacement for MySQL with extensions.

All examples in this guide work on VillageSQL. Install Now →
The MySQL binary log records every change made to the database — inserts, updates, deletes, schema changes. It’s the foundation for replication and point-in-time recovery. Most production MySQL servers run with binary logging enabled.

Enabling Binary Logging

Binary logging is enabled by default in MySQL 8.0. To verify:
Configure it in my.cnf / my.ini:
After log_bin is set, MySQL names binlog files as mysql-bin.000001, mysql-bin.000002, etc., with an index file (mysql-bin.index) listing them all.

Binary Log Formats

MySQL supports three binlog formats: ROW format is the recommended default. It replicates correctly even when non-deterministic functions like RAND() or UUID() are involved. The downside is larger log files — a single UPDATE touching millions of rows produces one statement in STATEMENT format but one row event per affected row in ROW format.

When to enable binary logging and which format to choose

Binary logging is enabled by default in MySQL 8.0+. The question is usually which format to use and whether to leave it on at all. Check and change the format:

Listing and Viewing Binary Logs

List all binary log files:
Check the current binlog file and position:
View the events in a binlog from SQL:

mysqlbinlog

The mysqlbinlog tool decodes binary log files into human-readable SQL. It’s used for point-in-time recovery and auditing:

Point-in-Time Recovery

Combining a full backup with binary logs lets you restore to any point in time after the backup was taken. Typical workflow:
  1. Take a full backup with mysqldump --single-transaction --source-data:
--source-data=2 writes the binlog filename and position as a comment in the dump. This is your recovery starting point.
  1. Restore the full backup:
  1. Find the binlog file and position from the dump:
  1. Replay binlogs from that position up to just before the event you want to undo:

Managing Binary Logs

Manually purge old binary logs:
Auto-purge with binlog_expire_logs_seconds (MySQL 8.0+) or expire_logs_days:
Never delete binlog files directly with rm — use PURGE BINARY LOGS so the index file stays consistent.

Frequently Asked Questions

Does binary logging affect write performance?

Yes, modestly. ROW format logging adds overhead proportional to the amount of data changed. For write-heavy workloads, the overhead is typically 5–15%. It’s almost always worth it for the recovery and replication capabilities it enables.

Can I skip binary logging for a specific session?

This is useful for loading data on a replica that doesn’t need to propagate further, or for bulk operations you want to exclude from point-in-time recovery scope. Requires the BINLOG_ADMIN or SUPER privilege.

How do I know how much disk space my binary logs are using?

Or on disk: du -sh /var/log/mysql/mysql-bin.*

Troubleshooting

See also