I've been seeing the following on a number of sites recently:
$ drush @example.com sql-dump
[...]
Error: Couldn't read status information for table cache_admin_menu ()
mysqldump: Couldn't execute 'show create table `cache_admin_menu`': Table 'examplecom.cache_admin_menu' doesn't exist (1146)
Comments
Comment #1
ergonlogicI've never seen this behaviour before:
Odder still:
Comment #2
ergonlogicIt looks like this table got corrupted somehow:
While cache_admin_menu.frm exists, its corresponding .ibd doesn't. I have no idea how this happened, but that appears to be the only table with this problem. Removing cache_admin_menu.frm was sufficient to get the sqldump working again.
Comment #3
mgiffordSo is this a code problem or just an issue with a corrupt table. If a corrupt table then we can probably close this issue, right?
Comment #4
nerdcore commentedCan this be explained by anyone?
Comment #5
nerdcore commentedI tried stopping MySQL and removing the files as described in #2. This does indeed allow mysqldump to create a correct dump of the DB, however I am unable to re-enable the admin_menu module:
PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table '"oc2014_t_D7"."cache_admin_menu"' already exists: CREATE TABLE {cache_admin_menu} ( `cid` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.', `data` LONGBLOB NULL DEFAULT NULL COMMENT 'A collection of data to cache.', `expire` INT NOT NULL DEFAULT 0 COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` INT NOT NULL DEFAULT 0 COMMENT 'A Unix timestamp indicating when the cache entry was created.', `serialized` SMALLINT NOT NULL DEFAULT 0 COMMENT 'A flag to indicate whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), INDEX `expire` (`expire`) ) ENGINE = InnoDB DEFAULT CHARACTER SET utf8 COMMENT 'Cache table for Administration menu to store client-side...'; Array ( ) in db_create_table() (line 2720 of /data/www/dm7/includes/database/database.inc).Comment #6
Ace Cooper commentedThank you, had the same problem:
#2 helped to solve my problem. After removing opt_cache_admin_menu.frm and restarting MySQL my ability to create backups is available again.
Comment #7
pivica commentedSame problem here, last night cpanel backup reported
But just a minute ago when I tried manual dump, mysqlcheck, etc everything is fine.
No idea is this mysql related problem or admin_menu.
Comment #8
ergonlogicI just came across this same issue again. Thankfully Google brought me back to this issue, as I hadn't seen it since.
We did experience some mysql issues recently, we suspect from poorly tested Puppet code. But that said,
cache_admin_menuwas by far the most prevalent table experiencing this issue. The only similar failure was forcache_rules, but an order of magnitude less frequently. However, this difference could simply be due to the popularity of admin_menu on our sites.Comment #9
masdzen commenteddisable admin_menu
uninstall admin_menu
i'm search #2 cache_admin_menu.frm file,
stop mysql
remove cache_admin_menu.frm file
start mysql
install admin_menu
get error and press F5 =)
admin_menu work, "drush arb" also work!
Comment #10
rob c commentedAnother idea:
Related: #2160645: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'cache_rules' doesn't exist
Also read: #2097037: cache_rules does not exist in database
I'm experiencing this on an old site i'm updating after a transfer to a new host back in January. Figured it had to do with the database dump from the transfer, but that wasn't the case. I am 100% sure this used to work before June 2015. Got a drush ard with all tables from before June, and this site didn't receive any huge changes. And in my case the table didn't exist when i confirmed via mysql. So i'm kinda stunned, because the table is in an archive dump from May. Recreating the table fixed drush, so... to be continued. (mysql server update? or are tables getting to large?)
Comment #11
geresy commentedthank you for the snippet Rob C. Tried everything, but this one fixed the errors in about the missing table.
Comment #12
davewilly commented#10 worked for me thanks. I couldn't get SSH access on the host but managed to run the required queries successfully in PHPMyAdmin.
Comment #13
morybel commentedThanks Rob C #10 worked for me after a lot of trial and error.
Comment #14
venkat-rk commented@Rob C, thank you for the code snippet. It helped me complete the migration of a Drupal 7.14 web site from one cPanel server to another that was being held up due to mysqldump failing with the error related to cache_admin_menu.
Your snippet also looks a cleaner solution that #2 - I wasn't sure how safe it would be to delete files directly from the database directory.
Comment #15
truls1502I am sorry for no reply until now.
There are many issues regarding this module admin_menu which is a bit difficult for us to follow up since some of the issues might be already outdated, or is already fixed by the module or any other modules or itself core which means that the problem might no longer need to be fixed.
We can see that the issue has been created for a few years ago, I hope it is okay for you that I am postponing the issue, and give you around two weeks. If you still face the problem, could you tell us the step by step when until you get the error message or what is frustrated you, and a list of modules you are using related to admin_menu and a screenshot that might help us? So it makes us easier to reproduce your issue.
However, after two weeks with no feedback - we will close this issue. So in case, you noticed it after the issue is closed, do not hesitate to reopen it like and fill information which is mentioned above.
So before giving us a feedback, do you mind to test it again with our latest 7.x-3.x-dev?
Thank you for understanding! :)
Comment #16
truls1502This issue has been automatically marked as closed because it has not had recent activity after the last post.
However, if you or someone is still facing the same issue as described to the issue, could you please to re-open the issue by changing the status of the issue, and add an explanation with more details which can help us to reproduce your situation.
Again, thank you for your contributions.