I ran into a rather interesting situation today with a client. It seems that the mysqld daemon stopped with no errors in the error log. I ran through the obvious problems … not enough disk space, memory utilization etc and came up empty.

The server was running MySQL 4.1 on Fedora Core 5. We can save the discussion about running your database on reasonable up to date hardware and operating system for another post. Core 5 runs the GNU/Linux kernel 2.4 along with the ext3 filesystem and so the thought was in the back of my mind that it might be an issue with file size. Well, as Sun’s own documentation shows this shouldn’t be the case.

During the investigation it was uncovered that the general query log was not only enabled but 16 gigabytes in size. Aside from being so large it was absolutely useless for anything, it was the obvious culprit for too large a file. After zapping the log file, it was possible to start the MySQL server  successfully. It was then that I looked up the previously referenced information about file size limits in the kernel and MySQL itself and found out that 16 GB shouldn’t have been a problem.

Checking through http://bugs.mysql.com didn’t uncover anything. I have already thought of how I can reproduce the problem pretty painlessly if it’s a general problem and not something specific to Fedora Core 5. But before I take several hours to run tests I wanted to see if anyone else had heard of this issue.

The rather obvious lessons that the client should take away from this:

1) There was no reason to have the general query log on in the first place and it should have been turned off.

2) If you need to use either slow or general query logging taking the time to set up log rotation.

Ever seen this before? If so please take 30 seconds and let me know. I would really appreciate it. And who knows, it could be one of your servers down the road that could be saved if it really is a bug. Of course you would never let your log files get that large, right? Right?