Bug #1594 | zero length binlog file is not removed with PURGE MASTER LOGS | ||
---|---|---|---|
Submitted: | 18 Oct 2003 6:33 | Modified: | 18 Oct 2003 7:20 |
Reporter: | [ name withheld ] | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 4.0, 3.23 | OS: | |
Assigned to: | CPU Architecture: | Any |
[18 Oct 2003 6:33]
[ name withheld ]
[18 Oct 2003 6:34]
[ name withheld ]
I forgot to add that this has been experienced on various versions of RedHat linux although I'd suspect that it's OS independent
[18 Oct 2003 7:20]
Guilhem Bichot
Hi! The problem is not that the file is of length 0. First, a binlog is always at least 4 bytes, so if you have a 0-byte one then something strange happened. Yes, that was during an upgrade; it could be that MySQL was killed before it had time to write the 4 first bytes, or there was some manual operations on the binlogs, I don't know. Anyway, the reason why MySQL does not delete the binlog is that this binlog is not listed in your .index file: look, you .index file is 68 bytes before you do the PURGE, which is 17*4, and 17 is the length of the name of one binlog. So before PURGE, the .index file probably contains porter-bin.014 porter-bin.015 porter-bin.016 porter-bin.017 and that's all, not porter-bin.009. PURGE MASTER LOGS works like this: open the .index file while (true) { read one line of the .index file if equals to the argument of PURGE MASTER LOGS, break; else delete the file } rebuild the .index file accordingly. So as .009 was not in the index file (which was caused by the strange things at upgrade time probably), it is not deleted. I tested on our machines: a zero-length binlog is deleted, if it is in the .index file. So that's not a bug. But your report was very clear, thank you! Guilhem