MySQL binary logs eating your disk space? Here's the fix

Binary logs fill up disk fast, especially on busy servers. Purge old ones with PURGE BINARY LOGS or set expiry. Don't just delete files.

Quick answer for advanced users

Run PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY; to remove logs older than a week. Then set expire_logs_days = 7 in my.cnf and restart MySQL. That's it.

Why binary logs fill up your disk

Binary logs record every write to your MySQL database. They're needed for replication and point-in-time recovery. But if you don't clean them, they just pile up. I've seen servers where logs took over 200GB of disk. The culprit here is almost always the default setting: expire_logs_days = 0, which means logs never expire. So they stay there forever until disk runs out. Then MySQL itself may crash because it can't write anything.

This usually happens on busy production servers with lots of writes. Or on a server that's been running for months without a reboot. You check disk space, see it's 99% full, and the /var/lib/mysql folder is the biggest offender.

How to fix it – step by step

  1. Check current disk usage
    Run du -sh /var/lib/mysql to see how much space logs take. Then list binary logs with SHOW BINARY LOGS; in mysql client.
  2. Stop MySQL if you can
    If disk is critically full (like 100%), MySQL may refuse to start. Stop it with systemctl stop mysql (or service mysql stop for older systems). This lets you free space safely.
  3. Purge old logs directly
    Log into MySQL and run:
    PURGE BINARY LOGS BEFORE NOW();

    This removes all binary logs except the current one. If you want to keep, say, 7 days of logs:
    PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;

    This is the safe way – don't delete files manually.
  4. Set automatic expiry
    Edit your my.cnf file (usually in /etc/mysql/my.cnf or /etc/my.cnf) and under the [mysqld] section add:
    expire_logs_days = 7

    For MySQL 8.0+, use binlog_expire_logs_seconds = 604800 instead (seconds in 7 days). Then restart MySQL.
  5. Verify it worked
    After restart, run SHOW VARIABLES LIKE 'expire_logs_days'; to confirm. Then check disk space again.

Alternative fixes if the main one fails

If you can't start MySQL because disk is full, you need to free space outside MySQL. Do this:

  1. Stop MySQL.
  2. Move or delete old binary log files manually from /var/lib/mysql/. Look for files named mysql-bin.xxxxxx. Keep only the most recent one. Move the rest to another drive or just delete them.
  3. Also check mysql-bin.index file – this lists all log files. Delete its contents or remove entries for deleted logs.
  4. Start MySQL again, then run PURGE BINARY LOGS BEFORE NOW(); to clean the index.

Another option: set a max size for binary logs. Add max_binlog_size = 100M to my.cnf so each log file stays small. This won't stop accumulation but makes cleanup easier.

How to prevent this from happening again

Don't rely on memory. Set a retention policy immediately. Here's what I do on every MySQL server I build:

  • Set expire_logs_days = 7 (or binlog_expire_logs_seconds for MySQL 8+).
  • Add a cron job that runs weekly: mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;" – just in case the setting fails.
  • Monitor disk space with a simple script that alerts you if /var/lib/mysql is over 80% full.
  • If you don't need replication or point-in-time recovery, disable binary logs entirely by setting skip-log-bin in my.cnf. But think twice – this kills backup options.

One last thing: never, ever just delete binary log files without updating the index. That breaks MySQL and you'll get errors like ERROR 1236 (HY000): Could not find first log file name in binary log index file. I've seen junior admins do this. Don't be that person.

Related Errors in Database Errors
SQL Server Error 9002 SQL Server Log File Exploding? Stop It Now Table 'wp_*' doesn't exist WordPress 'Table Doesn't Exist' After Plugin Install 0XC0190040 Fix STATUS_TRANSACTED_MAPPING_UNSUPPORTED_REMOTE (0XC0190040) 1045 Fix MySQL ERROR 1045 Access Denied for User

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.