Take the 2-minute tour ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

Suddenly, I got my website down (drupal 6.19) and could not start mysql (too many tables got crashed). by checking df -h, I found that the MySQL partition is full due to very large binary log files (I keep binary logs for one day only, expire_logs_days = 1); by checking mysqlbinlog for one of the bin logs I found out that most of the entries are for cache tables (cache_form, boost_cache, boost_cache_relationships, cache_content, etc) and for sessions table; some of the data is repeated many times.
by the way, i have watch ls -lh and the bin-log files got larger exponentially (every one or two minutes i got new binlog file with 100M file size!!)

Do you have any idea of what causes this? How can I fix this problem?

share|improve this question
    
I updated my answer. Thank you for pointing out that those were tables and not DBs. –  RolandoMySQLDBA Jun 8 '11 at 16:27
    
It's been 1 year, how did you solve it? –  confiq Sep 23 '12 at 17:23

2 Answers 2

up vote 6 down vote accepted

I guess one obvious improvement would be to use a different cache backend.

If you have a single server and enough memory, you could use an APC backend (D6: http://drupal.org/project/cacherouter, D7: http://drupal.org/project/apc) to have various of the often used caches directly in shared memory. That is probably the fastest cache solution you can get.

Another alternative is Memcached, which is especially interesting if you have multiples servers that should share a cache.

Note that you can't move the cache_form because that contains information about currently displayed forms and is not really a cache since it contains unique information, not just aggregated things like the others, which can always be cleared. Also, some other caches, especially cache_update, you might want to keep in the database, because that shouldn't be cleared like the rest as it contains information about update information of your used modules, something that doesn't change that often and can be very slow to re-fetch if you have many of them.

You can also move the sessions information out of the database, for example can you place it in MongoDB, and there are probably others too.

share|improve this answer

Have you checked the date of your bin logs ? expire_logs_days setting is not "auto-magic". It only takes effect when restarting mysql or when executing the command flush_logs or when max_binlog_size is reached.

Then mysql should rotate the current log file (creating a new one) and deleting the files older than 1 day (in your case)

Try to set up this last setting in your my.cnf and see if it works combined with expire_log_days.

share|improve this answer
    
all of them are created in the same day and by watching ls -lh, the bin-log files got larger exponentially!!. i got new file with 100M every 1 or 2 minuts –  Alaa May 23 '11 at 8:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.