Introduction

Yesterday Go2Linux was down, and all the problem was disk full, but how that happened? Well, it was MySQL fault, the files like

mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
....
mysql-bin.00000n

They were taking thousands of megas of disk space, let's see now why they are there, and how you can avoid running out of disk.

The binary log

The binary log contains events that describe database changes such as table creation operations or changes to table data. As of MySQL 4.1.3, it also contains events for statements that potentially could have made changes (for example, a DELETE which matched no rows). The binary log also contains information about how long each statement took that updated data. The binary log has two important purposes:

For replication, the binary log is used on master replication servers as a record of the statements to be sent to slave servers. Certain data recovery operations require use of the binary log. After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed.

Read more about MySQL binary log.

Stop MySQL from logging

You can stop MySQL from saving this logs by looking for the line log-bin=mysql-bin or log-bin= something else and comment it. That way MySQL will stop logging.

Delete old logs

If you want to continue logging (which may be the best approach), be sure to delete old logs.

From MySQL reference manual,

For the binary log, you can set the expirelogsdays system variable to expire binary log files automatically after a given number of days.

Add this line to your my.cnf file:

expire_logs_days = X

Where X is the number of days you want your logs to be kept in your hard disk.