1 - what is creating these files?
Those files are called binary logs. They contain a list of all completed SQL statements you have executed. Your mysqld process created them and autorotates at 1GB. Any restart of mysqld or issuing FLUSH LOGS;
will close one binary log and open another
They got created because there is a line in my.ini that looks like this:
log-bin=mysql-bin
Note the timestamps on each file
mysql-bin.000068
has 10/31/2012 2:13 PM
mysql-bin.000069
has 11/1/2012 11:13 AM
mysql-bin.000070
has 11/5/2012 11:51 AM
mysql-bin.000071
has 11/9/2012 11:50 AM
mysql-bin.000072
has 11/13/2012 11:13 AM
mysql-bin.000073
has 11/16/2012 12:05 AM
Here is what has been going
- On 10/31/2012 at 2:13 PM
mysql-bin.000068
surpassed 1GB (1048576 KB)
mysql-bin.000068
closed
mysql-bin.000069
opened
- On 11/1/2012 at 11:13 AM
mysql-bin.000069
closed due to mysql restart or FLUSH LOGS;
mysql-bin.000070
opened
- On 11/5/2012 at 11:51 AM
mysql-bin.000070
closed due to mysql restart or FLUSH LOGS;
mysql-bin.000071
opened
- On 11/9/2012 at 11:50 AM
mysql-bin.000071
surpassed 1GB (1048576 KB)
mysql-bin.000071
closed
mysql-bin.000072
opened
- On 11/13/2012 at 11:13 AM
mysql-bin.000072
closed due to mysql restart or FLUSH LOGS;
mysql-bin.000073
opened
- On 11/16/2012 at 12:05 AM
mysql-bin.000073
surpassed 1GB (1048576 KB)
mysql-bin.000073
closed
mysql-bin.000074
opened
By the way, the reason it autorotates at 1GB? The default setting max-binlog-size is 1GB.
2 - can I delete them to reclaim drive space?
As long as you do not have mysql replication installed, then yes.
First login to mysql and run
mysql> RESET MASTER;
This will erase all binary logs and leave you with mysql-bin.000001
with 107 bytes.
Next, if you comment it out like this
#log-bin=mysql-bin
and restart the mysqld process
C:\> net stop mysql
C:\> net start mysql
The logs will no longer be written.
As a final step, you can then delete mysql-bin.000001
from Windows Explorer.
Give it a Try !!!
Please do not just delete them in the OS.
You need to let mysqld do that for you. Here is how mysqld manages it:
The file mysql-bin.[index]
keeps a list of all binary logs mysqld has generated and auto-rotated. The mechanisms for cleaning out the binlogs in conjunction with mysql-bin.[index]
are:
PURGE BINARY LOGS TO 'binlogname';
PURGE BINARY LOGS BEFORE 'datetimestamp';
These will clear all binary logs before the binlog or timestamp you just specified.
For example, if you run
PURGE BINARY LOGS TO 'mysql-bin.000223';
this will erase all binary logs before mysql-bin.000223
.
If you run
PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY) + INTERVAL 0 SECOND;
this will erase all binary logs before midnight 3 days ago.
If you want to have binlog rotated away automatically and keep 3 days woth, simply set this:
mysql> SET GLOBAL expire_logs_days = 3;
then add this to /etc/my.cnf
[mysqld]
expire_logs_days=3
and mysqld will delete them logs for you
SHOW SLAVE STATUS\G
This is critical. When you run SHOW SLAVE STATUS\G
, you will see two binary logs from the Master:
Master_Log_File
Relay_Master_Log_File
When replication has little or no lag these are usually the same value. When there is a lot of replication lag, these values are different. Just to make it simple, choose whatever Relay_Master_Log_File
is, and go back to the Master and run
PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';
That way, replication is not interrupted.
Best Answer
First, you should run the following:
If
ReplicationUserCount
> 0, then the DB Server can be used as a Master. Ask your sysadmins or DBAs if there are any active or dormant Slaves.If
ReplicationUserCount
= 0, then the DB Server is standalone. You could then just delete all or some of your binlogs using these methods:METHOD #1
When you run this, all binlogs are erased and
localhost-bin.000001
is created.ALTERNATIVE: Shutdown mysql, delete
localhost-bin.*
, and startup mysql.METHOD #2
When you run this, all binlogs before
localhost-bin.000190
are erased.METHOD #3
When you run this these, this is what they do
CAVEAT #1
If methods 2 or 3 fail, this indicates that there may be a problem with the file
localhost-bin.index
. It keeps a text file with the list of the bin logs. If the file is out of sync, useMETHOD #1
. It will recreatelocalhost-bin.index
.CAVEAT #2
Do not erase the binlogs from the Linux command line with
rm
or from the Windows Explorer. Doing so will throw thelocalhost-bin.index
out of sync. If you do that, just do METHOD #1 and mysqld will clean it all up.CAVEAT #3
If you set
expire_logs_days = 7
in yourmy.cnf
(ormy.ini
), it will automatically run thison every log rotation or mysql restart.
EPILOGUE
Since you are interest in recovering space, choose one of the three methods. You can place
expire_logs_days = 7
in yourmy.cnf
(ormy.ini
) if you want. If you do not want it to grow past2 or 3 binlogs, then set this in your config file:and run
to limit the number of binlogs to a single day.
Keep in mind that setting expire_logs_days does not work if
localhost-bin.index
is out of sync.