Daniel Mejia wrote:
Josh Marshall-2 wrote:
It only recovers empty space and re-orders (like a defrag). If your
usage is increasing, the best way is to remove emails. Maybe you need to
run a dbmail-util to remove the deleted emails (there might be a SQL you
can run manually)
i did a cronjob to take care of this, every 2 & 6 am daily. (dbmail-util
-ay)
the cronjob also runs a custom SQL that would clear the trash & spam folder
older than 30 days.
still, the database size is increasing average 2GB per day. btw, do u happen
to know the maximum size mysql can handle? with the rate this is going, its
gonna be 2TB at the end of next year..
would ANALYZE TABLE gives any performance speed increase etc?
I would consider a MySQL upgrade, I'm not sure how good MySQL 4.0 is
with dbmail.
Oops, typing error! its mysql 5.0.45. i guess that's what happen when u only
get 3 hours of sleep for the past week. xD
you could have a backup server, replicating away, then flip over to that
for maintenance.
(not that nice really)
or perhaps just replicate the table in question, then shut down, stop
replication, rename the table on the main system to a temp name, create
a federated table on the main that points to the secondary
do the optimise table on the main, stop everything again, take out the
federated table, restart replication, (so the main synchs up with the
changes to the secondary) and your done.
Personally all that implies to me the table should be sharded.
shouldn't be that hard, split it based on the hash, hashes starting with
a 1 go into table mimeparts_1 etc
you can easily split it based on that to 10,100 or 1000 tables.
1000 tables should give good enough performance for some pretty decent
scaling ;-> especially if you spread them over the spindles.
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
