Bug #33737 PURGE MASTER LOGS works only if log-bin option enabled in my.cnf
Submitted: 8 Jan 2008 10:11 Modified: 13 Jan 2008 11:39
Reporter: Maciej Dobrzanski Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:4.1+ OS:Any
Assigned to: Jon Stephens CPU Architecture:Any
Tags: binary logs

[8 Jan 2008 10:11] Maciej Dobrzanski
Description:
PURGE MASTER LOGS command has no effect on the existing binary log files if log-bin parameter is not set. Either this is a bug or if you consider this behavior correct, it should be documented.

How to repeat:
1. Produce some binary logs to purge

-rw-rw---- 1 mysql mysql        117 Oct 28 21:32 mysqld-bin.000001
-rw-rw---- 1 mysql mysql        117 Oct 28 21:33 mysqld-bin.000002
-rw-rw---- 1 mysql mysql        455 Oct 31 06:47 mysqld-bin.000003
...
-rw-rw---- 1 mysql mysql 1073741960 Jan  7 05:40 mysqld-bin.000259
-rw-rw---- 1 mysql mysql 1073741977 Jan  7 16:47 mysqld-bin.000260
-rw-rw---- 1 mysql mysql 1073741900 Jan  8 03:45 mysqld-bin.000261
-rw-rw---- 1 mysql mysql   35724725 Jan  8 04:39 mysqld-bin.000262

2. Disable log-bin parameter in my.cnf and restart MySQL.
3. Enter MySQL console:

mysql> purge master logs to 'mysqld-bin.000262';
Query OK, 0 rows affected (0.00 sec)

0.00 sec - rather quickly for 250GB worth of files.

4. List the directory where your binlogs are to find out nothing has been removed.
[8 Jan 2008 10:12] Magnus BlÄudd
Probably expected behaviour
[8 Jan 2008 11:59] Hartmut Holzgraefe
I'd say expected behavior, too, as without an active "log-bin" it is not clear what the base name for binlog files is supposed to be, and just removing files based on the default "$hostname-bin" basename doesn't seem to be the right IMHO.
[8 Jan 2008 14:41] Valeriy Kravchuk
I think this is a reasonable documentation request. http://dev.mysql.com/doc/refman/5.1/en/purge-master-logs.html should include a note about this.
[10 Jan 2008 21:34] Stefan Hinz
We can document this, but it seems odd that the PURGE MASTER LOGS statement returns with no error (or at least a warning) when it obviously does not do what it can reasonably be expected to do.

I'd suggest to document it, then reset the bug to Open and change the category to Server:Replication.
[13 Jan 2008 11:39] Jon Stephens
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.