MySQL is a big pain in the neck in Windows because of the way open files behave.
In Linux, whenever I see a log file filling up a disk (i.e., /var/log/mysqld.log), I attempt to truncate the file
echo -n > /var/log/mysqld.log
Linux and mysqld has no problem with it. Windows, on the other hand, does.
I tried to do this in MySQL 5.5.12 on my desktop, that is, zapping the error file and I got this message:
C:\>copy con C:\MySQL_5.5.12\data\LW-REDWARDS2.err
^Z
The process cannot access the file because it is being used by another process.
0 file(s) copied.
C:\>
You must go to the Task Manager and kill the mysqld process.
Then, with the lock of the file handle released, you could attempt a zap of the log file.
Then, restart mysql with
C:\> net start mysql
You will have to allow time for mysqld to perform InnoDB Crash Recovery
UPDATE 2012-04-25 17:37 EDT
Diskspace is needed to write shutdown information into the mysql error log. During any mysql operation that produces temp tables (which are always MyISAM), diskspace is always needed. What happens if there is no diskspace for temp tables?
According to MySQL 5.0 Certification Study Guide Page 408,409 Section 29.2 bulletpoint 11 says:
If you run out of disk space while adding rows to a MyISAM table, no
error occurs. The server suspends the operation until space becomes
available, and then completes the operation.
Trying a standard shutdown of mysqld with no available diskspace complicates the problem. Just kill the process, delete the 18G log file, start mysql back up again, and live with InnoDB crash recovery. Trust me, it is better than looking for alternatives in a Windows environment which will not work because of the same disk issue.
Best Answer
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 anotherThey got created because there is a line in my.ini that looks like this:
Note the timestamps on each file
mysql-bin.000068
has10/31/2012 2:13 PM
mysql-bin.000069
has11/1/2012 11:13 AM
mysql-bin.000070
has11/5/2012 11:51 AM
mysql-bin.000071
has11/9/2012 11:50 AM
mysql-bin.000072
has11/13/2012 11:13 AM
mysql-bin.000073
has11/16/2012 12:05 AM
Here is what has been going
mysql-bin.000068
surpassed 1GB (1048576 KB)mysql-bin.000068
closedmysql-bin.000069
openedmysql-bin.000069
closed due to mysql restart orFLUSH LOGS;
mysql-bin.000070
openedmysql-bin.000070
closed due to mysql restart orFLUSH LOGS;
mysql-bin.000071
openedmysql-bin.000071
surpassed 1GB (1048576 KB)mysql-bin.000071
closedmysql-bin.000072
openedmysql-bin.000072
closed due to mysql restart orFLUSH LOGS;
mysql-bin.000073
openedmysql-bin.000073
surpassed 1GB (1048576 KB)mysql-bin.000073
closedmysql-bin.000074
openedBy the way, the reason it autorotates at 1GB? The default setting max-binlog-size is 1GB.
As long as you do not have mysql replication installed, then yes.
First login to mysql and run
This will erase all binary logs and leave you with
mysql-bin.000001
with 107 bytes.Next, if you comment it out like this
and restart the mysqld process
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 !!!