no the point is that "optimize table" is available with file-per-table mode IMHO that this is not default is pretty dumb because it does more harm as it helps with fragmentation
a innodb-file works like a growable VMware disk it never get smaller after it has grown without manual work imagine a dbmail server with a big customer using 50 GB mail storage goes somewhere else - without file-per-table you never get back the disk-usage and take backups in count you end up with large files for no benefit Am 21.01.2014 16:46, schrieb Gray, Patrick: > Is there any way to see how much space will be freed before migrating to > file-per-table mode? > > -----Original Message----- > From: dbmail-boun...@dbmail.org [mailto:dbmail-boun...@dbmail.org] On Behalf > Of Paul J Stevens > Sent: Tuesday, January 21, 2014 10:42 AM > To: DBMail mailinglist > Subject: Re: [Dbmail] Dbmail-util functionality problems > > On 21-01-14 16:37, Gray, Patrick wrote: >> That makes a lot of sense. Sorry if anything got confused from my end. >> >> I'm trying to clean up our database and delete all mail older than 30 days >> old, but nothing I do seems to free up any space or make any difference to >> the size that I see on our Amazon RDS page. >> >> Maybe I'm not completely understanding the dbmail-util command's purposes or >> capabilities? >> >> I need to get these databases cleaned as soon as possible because we're >> getting closer and closer to having to increase the size above 100gb. > > This is an InnoDB issue. Down-side of using a single data file for InnoDB. > Cleaning out tables, or rows does *not* decrease the overall size. It will > prevent or delay further growth - I think. > > The only way out is by migrating to file-per-table mode: > > http://dev.mysql.com/doc/refman/5.6/en/innodb-multiple-tablespaces.html
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
