From time to time I need to replicate a Magento database from the production site to the staging environment. It’s common to find out that a mysql dump of a Magento database is two, three or more gigabyte.
With such sizes, even when using gzip and catz, backup and restoring a database requires disk space and a lot of time.
But which is the table that uses most of the space? And can we save something acting on it?
If you list the Magento tables by space used, you may find a situation like the on visible in the picture below. There we have a table, “log_url_info” using 4 gigabytes.
Usually, while copying a database from production to staging, this table is not required, or better the content of that table is not required. So excluding it from the dump (if you use mysqldump you can add –ignore-table=[database].log_url_info) will save you space and time.
The picture shows other big tables, always containing logs which can be excluded from a dump (the second table has been removed because not a Magento table).
I left the “aw_followup_queue” table, because AheadWorks plugins is widely used and the cited table and another one named “aw_core_logger” grow huge quickly. The “aw_core_logger”, for unknown reason, is never cleaned up (even if configured to do so), but being a logger, can be safely empty from time to time.