Dump Could Read Status Information for Table
I've been seeing the post-obit on a number of sites recently:
$ drush @example.com sql-dump [...] Fault: Couldn't read status data for tabular array cache_admin_menu () mysqldump: Couldn't execute 'show create table `cache_admin_menu`': Tabular array 'examplecom.cache_admin_menu' doesn't exist (1146)
Source: https://www.drupal.org/project/admin_menu/issues/2135373
Comments
Comment #i
ergonlogic
English
Montréal, Québec 🇨🇦
Credit Attribution: ergonlogic commented
I've never seen this behaviour before:
Odder withal:
Comment #2
ergonlogic
English language
Montréal, Québec 🇨🇦
Credit Attribution: ergonlogic commented
It 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, merely that appears to exist the only table with this trouble. Removing cache_admin_menu.frm was sufficient to go the sqldump working over again.
So is this a code trouble or merely an issue with a corrupt table. If a decadent table then nosotros can probably close this consequence, right?
Tin can this be explained by anyone?
I tried stopping MySQL and removing the files equally described in #2. This does indeed allow mysqldump to create a correct dump of the DB, yet 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 Primal: Unique cache ID.', `data` LONGBLOB Aught DEFAULT NULL COMMENT 'A collection of data to cache.', `expire` INT NOT Zippo DEFAULT 0 COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` INT NOT NULL DEFAULT 0 Annotate 'A Unix timestamp indicating when the cache entry was created.', `serialized` SMALLINT NOT Zippo DEFAULT 0 COMMENT 'A flag to point whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), Index `expire` (`elapse`) ) ENGINE = InnoDB DEFAULT Grapheme SET utf8 COMMENT 'Cache tabular array for Administration menu to store client-side...'; Assortment ( ) in db_create_table() (line 2720 of /data/www/dm7/includes/database/database.inc).
Cheers, 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 over again.
Aforementioned trouble hither, last dark cpanel backup reported
Just just a minute ago when I tried manual dump, mysqlcheck, etc everything is fine.
No idea is this mysql related trouble or admin_menu.
Comment #8
ergonlogic
English
Montréal, Québec 🇨🇦
Credit Attribution: ergonlogic commented
I only came across this aforementioned issue again. Thankfully Google brought me dorsum to this issue, as I hadn't seen information technology since.
Nosotros did experience some mysql issues recently, we suspect from poorly tested Boob code. But that said,
cache_admin_menu
was by far the most prevalent tabular array experiencing this issue. The only similar failure was forcache_rules
, but an order of magnitude less frequently. Yet, this departure could simply exist due to the popularity of admin_menu on our sites.disable admin_menu
uninstall admin_menu
i'thousand search #2 cache_admin_menu.frm file,
stop mysql
remove cache_admin_menu.frm file
kickoff mysql
install admin_menu
get error and press F5 =)
admin_menu work, "drush arb" also work!
Some other idea:
Related: #2160645: PDOException: SQLSTATE[42S02]: Base tabular array or view not found: 1146 Tabular array 'cache_rules' doesn't exist
Besides read: [#2097037]
I'k experiencing this on an old site i'm updating later 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 piece of work earlier June 2015. Got a drush ard with all tables from earlier June, and this site didn't receive whatever huge changes. And in my example the table didn't exist when i confirmed via mysql. And so i'one thousand 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 big?)
thanks for the snippet Rob C. Tried everything, but this ane fixed the errors in about the missing table.
#10 worked for me thanks. I couldn't get SSH access on the host but managed to run the required queries successfully in PHPMyAdmin.
Thanks Rob C #x worked for me after a lot of trial and mistake.
@Rob C, give thanks yous for the code snippet. Information technology helped me complete the migration of a Drupal seven.14 web site from ane cPanel server to some other that was beingness held up due to mysqldump failing with the error related to cache_admin_menu.
Your snippet besides looks a cleaner solution that #2 - I wasn't sure how safe it would be to delete files straight from the database directory.
I am sorry for no respond until now.
In that location are many problems regarding this module admin_menu which is a bit difficult for us to follow up since some of the problems might be already outdated, or is already fixed by the module or whatever other modules or itself core which means that the trouble might no longer demand to be fixed.
We can see that the upshot has been created for a few years ago, I promise it is okay for you lot that I am postponing the outcome, and requite you around two weeks. If you still face the problem, could yous tell us the pace past step when until you lot get the error message or what is frustrated you, and a list of modules yous are using related to admin_menu and a screenshot that might assistance u.s.a.? So it makes the states easier to reproduce your issue.
However, after 2 weeks with no feedback - we will shut this effect. And so in case, you lot noticed information technology after the result is closed, exercise not hesitate to reopen it similar and fill information which is mentioned above.
And so earlier giving united states of america a feedback, do y'all mind to test information technology once again with our latest 7.x-three.ten-dev?
Thank you lot for agreement! :)
This issue has been automatically marked as airtight because it has non had recent activeness later on the final post.
However, if you or someone is nonetheless facing the same upshot as described to the result, could you please to re-open the result by changing the condition of the issue, and add an explanation with more details which tin can help us to reproduce your situation.
Once again, thank you for your contributions.