"optimize table" is your friend in case you have files per table enabled -
before mysql 5.6 the table is locked while rebuild is running - innodb never
reclaims space
Ursprüngliche Nachricht
Von: Simon
Gesendet: 19. März 2015 04:21:52 MEZ
An: DBMail mailinglist
Betreff: [Db
Am 19.03.2015 um 04:21 schrieb Simon:
> Hi There,
>
> We are using dbmail (2.2.18) on debian with a (separate) mysql 5.1
> backend (master/slave with innodb_file_per_table enabled). We
> use innobackupex for nightly backups.
>
> Currently a SUM(curmail_size) of all mailboxes gives us about 110GB
On 19-03-15 04:21, Simon wrote:
If the later, I would really appreciate some pointers to deal with
reclaiming the space...?
As others suggested, optimize table (or the mysqloptimize command line
utility) can help you 'reclaim' space.
But you shouldn't use it unless you really need to becau
Am 19.03.2015 um 10:13 schrieb Casper Langemeijer:
On 19-03-15 04:21, Simon wrote:
If the later, I would really appreciate some pointers to deal with
reclaiming the space...?
As others suggested, optimize table (or the mysqloptimize command line
utility) can help you 'reclaim' space.
But y
On Thu, Mar 19, 2015 at 10:27 PM, Reindl Harald
wrote:
>
> 1. Optimize table rewrites the entire table into a new file. This means
>> you'll need about 110G-150G of storage space to be able to perform this
>> action in the first place
>>
>
> sadly yes, maybe it's too late
I can provision new sp
Am 19.03.2015 um 21:16 schrieb Simon:
What im trying to understand is why is the SUM of curmail_size is approx
110GB, yet the database size (even dump'ed) is 400GB. Surely dbmail does
not have that much overhead in its database?
mailsize has barely to do with database size
completly different
On Fri, Mar 20, 2015 at 9:31 AM, Reindl Harald
wrote:
>
> Am 19.03.2015 um 21:16 schrieb Simon:
>
>> What im trying to understand is why is the SUM of curmail_size is approx
>> 110GB, yet the database size (even dump'ed) is 400GB. Surely dbmail does
>> not have that much overhead in its database?
Am 19.03.2015 um 21:54 schrieb Simon:
On Fri, Mar 20, 2015 at 9:31 AM, Reindl Harald wrote:
Am 19.03.2015 um 21:16 schrieb Simon:
What im trying to understand is why is the SUM of curmail_size
is approx
110GB, yet the database size (even dump'ed) is 400GB. Surely