When you first realize that you have a problem, you’ll have a gut reaction to just delete these files, and to be quite honest, I’m not sure if that really *breaks* anything or not.  MySQL does track these files though.  So it’s possible if you yank a file out from under the server, it might get a little whacky.   The bottom line is though, they are merely a binary representation of the sql that you intend to send to another server (typically), and they have nothing to do with the integrity of the data in the database.

So if you want to do it the *correct* way, mysql has a command set to deal with these logs.  First, to get a look at the files and their sizes, you can do a show binary logs . This will give you the breakdown of all the bin logs the server knows about.

It may be prudent, if you are running in a master/slave environment to take a look at your slave status so that you know you are not behind.  basically, log into your slave and run show slave status\G . Make sure that Slave_IO_Running: Yes and Slave_SQL_Running: Yes exist, and check Seconds_Behind_Master: 0.   These 3 things will tell you that your slave is running and up to date.  While you’re here, make note of the Master_Log_File: .   This should be the most recent log listed in your show binary logs output on the master server.

Now that you know where you are in your binary log world, all you need to do is tell the master to purge the files up to the next to the last file, or less if you’re paranoid.  If you’re most recent log file is mysql-bin.104 then you might want to issue the following command:  PURGE BINARY LOGS TO ‘mysql-bin.103′.  This will leave log 103 and 104 on the server and remove the rest.

That’s about it, Happy Purging!!