Is there a way to salvage the structure of a broken mysql table?
I've been searching, but can't find anything other than repair table x.
When I issue a select on the table, the server responds: Incorrect key file for table 'click'; try to repair it
But repairing doesn't work. MySql comes back with a Msg_text of Corrupt. Gee, I kinda knew that already.
The data in the table isn't all that important and can be lost, but I do want to salvage the table structure which I can't get (describe click): Incorrect key file for table 'click'; try to repair it.
I was hoping truncate might solve my problem, but alas: Table 'click' is marked as crashed and should be repaired.
Does anybody know how I can fix this problem?
Related
I've been trying hard to migrate a Wordpress project and after a thousand attempts, this is the closest I got. I notice that the tables I imported from my previous project are the ones that Wordpress can't reach. Then I thought it was a matter of adding the "56z7sj5c2a" suffix to the tables I moved. So I executed the code ALTER TABLE wp_options RENAME TO wp_56z7sj5c2a_options;, for example. It didn't work. Does anyone have any idea how I establish this link with the new tables? Below the message error after pressing the button "repair and optimize".
The wp_56z7sj5c2a_users table is okay.
Failed to optimize the wp_56z7sj5c2a_users table. Error: Table does not support optimize, doing recreate + analyze instead
The wp_56z7sj5c2a_usermeta table is okay.
Failed to optimize the wp_56z7sj5c2a_usermeta table. Error: Table does not support optimize, doing recreate + analyze instead
The wp_56z7sj5c2a_posts table is not okay. It is reporting the following error: Table 'djt443375729453.wp_56z7sj5c2a_posts' doesn't exist. WordPress will attempt to repair this table…
Failed to repair the wp_56z7sj5c2a_posts table. Error: Table 'djt443375729453.wp_56z7sj5c2a_posts' doesn't exist
The wp_56z7sj5c2a_comments table is okay.
The wp_56z7sj5c2a_links table is okay.
The wp_56z7sj5c2a_options table is not okay. It is reporting the following error: Table 'djt443375729453.wp_56z7sj5c2a_options' doesn't exist. WordPress will attempt to repair this table…
Failed to repair the wp_56z7sj5c2a_options table. Error: Table 'djt443375729453.wp_56z7sj5c2a_options' doesn't exist
The wp_56z7sj5c2a_postmeta table is not okay. It is reporting the following error: Table 'djt443375729453.wp_56z7sj5c2a_postmeta' doesn't exist. WordPress will attempt to repair this table…
Failed to repair the wp_56z7sj5c2a_postmeta table. Error: Table 'djt443375729453.wp_56z7sj5c2a_postmeta' doesn't exist
The wp_56z7sj5c2a_terms table is okay.
The wp_56z7sj5c2a_term_taxonomy table is okay.
The wp_56z7sj5c2a_term_relationships table is okay.
The wp_56z7sj5c2a_termmeta table is okay.
The wp_56z7sj5c2a_commentmeta table is okay.
I was trying to drop a column of my table but I got an error message.
After a few attempts, suddenly the table disappeared, but I have never dropped it.
I was in the page "table structure" of phpmyadmin, I clicked "drop column" and an error message appeared, which told me "table doesn't exist".
This proves that I dind't drop it, because if I was working in the page table structure of the table it means that the table was there.
And I don't know what happened, seems totally irrational to me.
The table simply disappeared (autodropped) while I was working on it.
However, doesn't matter so much what happened. The question is: how can I restore the table? Given the fact that I didn't drop the table, maybe the table is still somewhere?
It's possible that the table was dropped and an error occured after the table got dropped. Double triple check in PHPMyAdmin, but I think your table has gone forever.
To prevent this happening in the future, always run daily backups on your site and store them in a location that's not on the server hosting your database.
I have no idea what is going on. I have a table called project_share_invite. A few hours ago (in our production environment) I could no longer issue SELECTs against this table. MySQL claims the table does not exist, though it shows on show tables. The only noteworthy event that has happened on the machine today is a routine package upgrade (via apt).
mysql> use analytics;
Database changed
mysql> show tables like 'project_share_invite';
+--------------------------------------------+
| Tables_in_analytics (project_share_invite) |
+--------------------------------------------+
| project_share_invite |
+--------------------------------------------+
1 row in set (0.00 sec)
mysql> select count(*) from project_share_invite;
ERROR 1146 (42S02): Table 'analytics.project_share_invite' doesn't exist
Ideas? This doesn't make any sense to me.
Update: The files for the table are still present on disk (project_share_invite.frm and project_share_invite.idb respectively) and have content in them.
A quick restart of MySQL has not fixed this.
Update: Same results when using root account instead of specific user account.
Update: I am unable to recreate the tables either.
CREATE TABLE `analytics`.`project_share_invite` ( ... )
ERROR 1146 (42S02): Table 'analytics.project_share_invite' doesn't exist
Update: Should have checked the error logs first:
InnoDB: Load table 'analytics/project_share_invite' failed, the table has missing foreign key indexes.
Though I've no idea how it's got in this state.
Looks like you hit a known bug in MySQL where a foreign key constraint exists, but the associated index was dropped. See: http://bugs.mysql.com/bug.php?id=68148
Depending on the version of MySQL (Seems like you need 5.6 or >) you can fix this problem by turning off foreign key checking and then recreating the missing index(es).
SET FOREIGN_KEY_CHECKS=0;
You should check the structure using SHOW CREATE TABLE table name
Then use CREATE INDEX to recreate the missing indexes.
This error is usually caused by moving files around at the filesystem level.
Keep in mind that SHOW TABLES just reads the .frm file, but once you query the table, MySQL invokes the storage engine. InnoDB has its own internal way of managing metadata, in a "data dictionary" which is always stored in ibdata1.
So if you moved the datadir but forgot the ibdata1 file (or copied an ibdata1 from another instance), then the InnoDB data dictionary wouldn't know about the table, even though SHOW TABLES does.
Another possibility is that you copied data files around, and now they don't have the write ownership or file permissions. So for example the .frm file is readable but the .ibd is not. They should be owned and writeable by mysql:mysql.
If your apt upgrade changed file locations or file permissions, that could cause it too. I would advise using ls -l to verify the permissions on the files.
I am quite new to MySQL and I have encountered a problem that I find quite puzzling. If I create a table with MySQL Workbench, when I set the PK I can choose it to auto-increment or not, as should be. However, if I change my mind later on, once the table has been created, I cannot alter the auto-increment flag any longer, as MySQL tells me that the "table already exists". That happens even if the table is empty.
The auto-generated SQL is as follows:
ALTER TABLE tablename
CHANGE COLUMN `ID` `ID` INT(11) NOT NULL AUTO_INCREMENT ;
and it fails with the error stated above. I have tried changing the algorithm and lock type, to no avail.
This does not happens in T-SQL or Oracle, for instance, so I fail to see a reason why it should fail in MySQL. Is there any way to fix this without having to drop and re-create the table?
Thanks.
From experience all the GUIs get a bit confused when you start changing primary keys, the number of error messages I've seen from SQL Server...
You don't need to drop the whole table, but it might be easiest to drop and then re-create the offending column.
Also, check out the MySQL dev docs, but I think either ALTER or MODIFY column are the two I'd go for and I'm not sure why the column name is there twice if you're not renaming it.
Ok, I discovered the culprit thanks to dbForge Studio. The same thing happens there, but this time the error is more explicit: I cannot change the auto-increment flag apparently because it is used as a foreign key on another table. I deleted the FK and then I was able to set the auto-increment.
Thank you all who helped me, I have learned some new things thanks to your comments.
In mysqlworkbench, I created a view, committed it to the database, but I no longer needed it.
As such, I deleted the view in mysql workbench and then updated the database.
I thought all was fine, however in phpmyadmin, it says that the table still exists. What's more, it is constantly in use.
I tried to drop the table within phpmyadmin, however when I try to drop the table, it provides an error message saying:
1051 - Unknown table ... indicating to me that the table is not there.
but it still remains showing in the database, and under collation, it says that the table is 'in use'.
Any advice here?
Problem solved.
It appears as though you cannot delete a view from the database by normal means. The following solved the problem for me.
DROP VIEW IF EXISTS viewName;