tag:blogger.com,1999:blog-4622775563416752930.post1704209081344485941..comments2022-09-01T20:53:27.194+01:00Comments on Mark's stream of verbiage: MySQL running out of disc spaceMark Robsonhttp://www.blogger.com/profile/15864507044869250062noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-4622775563416752930.post-60535835414580523812010-02-12T16:11:19.740+00:002010-02-12T16:11:19.740+00:00I am also interested in the source code for Gencon...I am also interested in the source code for Gencontrol. Do you have a live link for this tool? I use it and would like to post a link to your download page.Ryan Carverhttps://www.blogger.com/profile/09347456345822671110noreply@blogger.comtag:blogger.com,1999:blog-4622775563416752930.post-49291930453505553512009-03-04T17:34:00.000+00:002009-03-04T17:34:00.000+00:00Great! I so need help (but thats a different conve...Great! I so need help (but thats a different conversation). I am in need of the C++ Source for the app but the gensortium site seems down. I am trying to make Gencontrol be view only as we just need to monitor what our users are doing for quality control issues. Any help you can offer would be so greatly appreciated!<BR/><BR/>CraigCraig Gagnehttps://www.blogger.com/profile/11256657878481606901noreply@blogger.comtag:blogger.com,1999:blog-4622775563416752930.post-82642196705202437412009-03-04T17:02:00.000+00:002009-03-04T17:02:00.000+00:00Yes I am.Yes I am.Mark Robsonhttps://www.blogger.com/profile/15864507044869250062noreply@blogger.comtag:blogger.com,1999:blog-4622775563416752930.post-85741485018654303162009-03-04T16:23:00.000+00:002009-03-04T16:23:00.000+00:00Are you the same Mark Robson that developed Gencon...Are you the same Mark Robson that developed Gencontrol?Craig Gagnehttps://www.blogger.com/profile/11256657878481606901noreply@blogger.comtag:blogger.com,1999:blog-4622775563416752930.post-34982389522810600952009-03-04T16:22:00.000+00:002009-03-04T16:22:00.000+00:00This comment has been removed by the author.Craig Gagnehttps://www.blogger.com/profile/11256657878481606901noreply@blogger.comtag:blogger.com,1999:blog-4622775563416752930.post-2356528821133918932008-12-21T17:24:00.000+00:002008-12-21T17:24:00.000+00:00How often do we run out of space? In production, n...How often do we run out of space? In production, never, as space is managed properly and monitored vigilantly.<BR/><BR/>In non-production environments: Sometimes, but then it doesn't always matter too much.<BR/><BR/>Thankyou for your tips on saving space, although that wasn't quite what I had in mind :)Mark Robsonhttps://www.blogger.com/profile/15864507044869250062noreply@blogger.comtag:blogger.com,1999:blog-4622775563416752930.post-59312591360363521692008-12-21T15:49:00.000+00:002008-12-21T15:49:00.000+00:00How often are you actually running out of disk spa...How often are you actually running out of disk space? This should happen, well, never :) But if it does, it should be once in a blue moon. Any more often and you have a systemic problem that needs to be addressed.<BR/><BR/>MySQL does not handle running out of disk space well and you risk corrupting both your MyISAM and InnoDB tablespaces (if you use InnoDB). That turns a bad day into a worse one. <BR/><BR/>As a general rule, it's wise to keep at least 10% of disk space free all the time. Any less and you can run into performance issues, fragmentation, etc. But you also remove your safety blanket which helps allow you to make careful, calculated, decisions about how to fix the issue. Instead, if you run totally out of space, your site is down and you have to make decisions, some that should be given careful thought, fast. <BR/><BR/>Point is - the most important thing to do is fix the root problem. If you have tables which can be read only, or can be split out (say by date), compress the ones you don't need to write to using 'myisampack' or consider converting them to the ARCHIVE engine (if you can handle lack of indexes anyway). 5.1 supports partitioning to help with this as well and you could even look at the InnoDB plugin or Percona's InnoDB fork called XtraDB. Both support on-the-fly compression.<BR/><BR/>You could also look at moving your data to another disk. Though I find it gacky, you can create symlinks to move your .MYD and .MYI files to another drive. You can also do this with the database directories.<BR/><BR/>Moving to a large RAID (you are using RAID, right? :) would help too and, in an extreme case, you could split your reporting data onto a dedicated reporting server.<BR/><BR/>Now having said all that, I agree that you should be monitoring disk usage. Nagios, Nimbus, home brew scripts, etc. can help with that. Drizzle *could* do this but one of it's goals is to make the database simpler, not more complex and this is really more of a system administration issue over a DB one.<BR/><BR/>That said, you can also have the same scripts monitor disk usage by simply logging in to MySQL/Drizzle and running "SET GLOBAL read_only=1;" then removing it once the disk usage has been solved.<BR/><BR/>MySQL should also throw errors, I agree with you here as well, or even shutdown if the issue is bad enough to cause table-corruption issues. That, too, is scriptable, but it would be nice if MySQL didn't try to trudge ahead and write to the disk when it's totally full :)Anonymousnoreply@blogger.com