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
- Check current disk usage
Rundu -sh /var/lib/mysqlto see how much space logs take. Then list binary logs withSHOW BINARY LOGS;in mysql client. - Stop MySQL if you can
If disk is critically full (like 100%), MySQL may refuse to start. Stop it withsystemctl stop mysql(orservice mysql stopfor older systems). This lets you free space safely. - 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. - Set automatic expiry
Edit your my.cnf file (usually in/etc/mysql/my.cnfor/etc/my.cnf) and under the[mysqld]section add:expire_logs_days = 7
For MySQL 8.0+, usebinlog_expire_logs_seconds = 604800instead (seconds in 7 days). Then restart MySQL. - Verify it worked
After restart, runSHOW 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:
- Stop MySQL.
- Move or delete old binary log files manually from
/var/lib/mysql/. Look for files namedmysql-bin.xxxxxx. Keep only the most recent one. Move the rest to another drive or just delete them. - Also check
mysql-bin.indexfile – this lists all log files. Delete its contents or remove entries for deleted logs. - 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(orbinlog_expire_logs_secondsfor 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/mysqlis over 80% full. - If you don't need replication or point-in-time recovery, disable binary logs entirely by setting
skip-log-binin 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.