I'm not sure how this happens, but the cache_rules table is corrupted and it prevents me from doing a drush cache clear all. I dropped the table successfully, but now I can't create it. Throws this error:

ERROR 1005 (HY000): Can't create table 'cache_rules' (errno: -1)

Luckily i have my db backed up and don't have to lose too much data. Now I tried to drop my entire database and that's not working neither. It does in fact drop all the tables, but it prevents the database from getting dropped entirely.

enter image description here

  • Confirm that the disk isn't full. – mpdonadio Jun 17 '14 at 23:08
  • Every hit on Google says you need to run mysql_upgrade or mysqlcheck -r mysql proc -u root -p to repair your corrupt proc table – Clive Jun 17 '14 at 23:13

I tried dropping the database multiple ways. via command line and phpmyadmin. none of that worked.

What did work was going into the database files directory and deleting it manually. These mysql database tables are just regular files you can delete. Mine were located here: /var/lib/mysql/

here's what i did:


After that I was able to recreate the table via mysql command line. just copy and paste this to recreate the table with the schema:

CREATE TABLE `cache_rules` (`cid` varchar(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.', `data` longblob COMMENT 'A collection of data to cache.', `expire` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry was created.', `serialized` smallint(6) NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), KEY `expire` (`expire`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Cache table for the rules engine to store configured items.';
| improve this answer | |
  • 1
    Wowsers, the meta for the table got deleted but the data didn't (notice the missing cache_rules.frm file). It's probably worth noting this approach will only work if innodb_file_per_table is active (it is by default these days), otherwise you'll be left unpicking the binary in ibdata1. Using mysqlcheck -r on that table might be a safer option if it happens again... – Clive Jun 17 '14 at 23:17
  • yea i should have did a table repair first.. i jumped the gun and was reading some other tutorial and just dropped the table thinking i could just create it again... (-_-*) ... – Patoshi パトシ Jun 17 '14 at 23:31
  • 1
    Seriously, see how full your disk is. Really crazy things happen when it is. – mpdonadio Jun 18 '14 at 0:16
  • 2
    @Clive innodb_file_per_table is on by default in >= 5.5.7. If you update, you still need to do an OPTIMIZE to force the tables to be rebuilt, and then you still can't reclaim the idbdata1 space. – mpdonadio Jun 18 '14 at 0:18
  • @Clive I am frequently experiencing the same issue. It's not only cache_rules but with other cache tables as well. Everytime I clear the cache from the performance tab it gives me: "PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxsite_namexx.cache_rules' doesn't exist:..." I have to always recreate this table all the time. My disk is not full as I have a new laptop purchased with huge free space. I have an Acquia DevDesktop Rc2 install. Either turning off/on options for Bandwidth Optimization does not help. Should this be a bug with Drupal or InnoDB? – jan Oct 18 '14 at 11:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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