I have this problem with an table. i want to delete it and does not work
I tried to delete de .ibd file, them rename some frm file to the same name as te ibd to drop the table , does not work
when i drop table, and then create it again, it gives me this error #1813 table space for table name still exist, please discart tablespace before import. and if i try ti discard, says that nametable does not exist
I even tried to alter the table
I`m using xampp
does anyone knwo how to fix this?
In my case, I solve this with: DROP TABLE IF EXISTS yourtablename, yourtablename, yourtablename; and reload the db backup.
I use XAMPP in Osx,You can also see logs:
tail /Applications/XAMPP/xamppfiles/var/mysql/yourFile.local.err
You can also remove .ibd, I use XAMPP:
You should now work with your backup.
Related
I have MySQL running on SSDs, SSDs that I'm about to run out of space on. My webhost overcharges for SSDs and the majority of the data in MySQL is "archived" data (i.e. data that isn't actively used). I have larger HDDs that can hold this data. As such, I want to be able to move specific InnoDB tables from the SSDs to the HDDs.
One solution I've thought about and researched is moving the individual .ibd files (I have innodb_file_per_table enabled) for the specific tables in question to the HDDs and then symlink. However, researching this, it looks like that is a bad idea for InnoDB.
I've also seen that since 5.6, MySQL supports the DATA DIRECTORY command:
To create a new InnoDB file-per-table tablespace in a specific
location outside the MySQL data directory, use the DATA DIRECTORY =
absolute_path_to_directory clause of the CREATE TABLE statement.
Plan the location in advance, because you cannot use the DATA
DIRECTORY clause with the ALTER TABLE statement. The directory you
specify could be on another storage device with particular performance
or capacity characteristics, such as a fast SSD or a high-capacity
HDD.
The problem is, it looks like this is only supported for new tables. I want to do it for existing tables. Any tips on how? I'm running Percona MySQL, if it helps.
Thanks!
UPDATE: Here is what I tried, but I'm getting a syntax error:
CREATE TABLE abc_2 LIKE abc ENGINE=InnoDB DATA DIRECTORY='/xxx/mysql/archive/'
Apparently CREATE ... LIKE ... DATA DIRECTORY ... is a combination that is not supported.
Do SHOW CREATE TABLE to get the current definition. Edit it to add DATA DIRECTORY and INDEX_DIRECTORY. Then use the edited text to create the new table.
Then INSERT INTO new_tbl SELECT * FROM real_tbl; and shuffle the names: RENAME TABLE real_tbl TO old_tbl, new_tbl TO real_tbl;.
Verify the results and finally DROP old_tbl;
I have dealt with this problem myself, and eventually found a more elegant solution than 'create new - copy - switch': detaching, moving and re-importing the underlying tablespace files. This is much more efficient on large and/or heavily indexed tables as MySQL does not have to redo work it has already done.
In short, it comes down to the following steps:
FLUSH TABLES `table_name` FOR EXPORT;
While keeping the connection open, move the tablespace files in a shell:
$ mv /var/lib/mysql/database_name/table_name.{ibd,cfg} ~
Now back in MySQL release the lock, drop the table, re-create it with the correct DATA DIRECTORY and discard its tablespace:
UNLOCK TABLES;
SHOW CREATE TABLE `table_name`;
DROP TABLE `table_name`;
CREATE TABLE `table_name` /* ... */ DATA DIRECTORY='/path/to/desired/location';
ALTER TABLE `table_name` DISCARD TABLESPACE;
Now copy the moved tablespace files to the desired location:
$ cp -a ~/table_name.{ibd,cfg} /path/to/desired/location
And import them:
ALTER TABLE `table_name` IMPORT TABLESPACE;
More background and motivation for why 'create new - copy - switch' is inefficient can be found in a blogpost I wrote on this topic: https://www.moxio.com/blog/28/moving-individual-mysql-tables-on-disk.
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 have a mysql table y in database xxx which I attempted to change compression type before using
alter table y row_format=compressed key_block_size=8
the process stopped half way. I removed temp file '#sql-ib265.frm and #sql-ib265' in mysql lib directory and restarted the server. However
Now when I attempt the alter table y (with the same command above) again I get error.
ERROR 1050 (42S01) at line 1: Table 'xxx/#sql-ib265' already exists
I can't drop table 'xxx/#sql-ib265' because it can't be found.
what should I do?
Edit
Solution:
I ended up dropping the old database and recreate the database.
Try to restart mysql client with the --skip-auto-rehash option and try DROP TABLE again.
If above does not work, try this from MySQL Manual:
You have a corrupt innodb data dictionary..
https://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting-datadict.html
Problem with Temporary Table
If MySQL crashes in the middle of an ALTER TABLE operation, you may end up with an orphaned temporary table inside the InnoDB tablespace. Using the Table Monitor, you can see listed a table with a name that begins with #sql-. You can perform SQL statements on tables whose name contains the character “#” if you enclose the name within backticks. Thus, you can drop such an orphaned table like any other orphaned table using the method described earlier. To copy or rename a file in the Unix shell, you need to put the file name in double quotation marks if the file name contains “#”.
There are two ways to fix this problem.
As other answer suggests, official MySQL documentation suggests to drop a specially crafted table. But please note in versions >= 5.1 you need to prefix table name with #mysql50#.
Move (use RENAME TO) all good tables to a temporary database, drop&recreate the original one and then move the tables back. See a blog post for details.
in additional I'm loging in with root to do the recover job but failed. then i chown the .frm file to meet the owner of mysql service and succeed.
For anyone still facing this problem, I have just followed the following steps to solve it, which (to me at least) seem far less daunting than other solutions:
Use mysqldump to back up the database with all its data.
Drop and recreate the database.
Reload the database and all its schema from the file generated in (1).
Because the orphaned tables are hidden anyway, they don't get backed up, so you end up with a database without them. I had all my procedures/functions scripted out anyway, so was able to restore them easily - if you don't, make sure you use the --routines parameter to dump those too.
My dump file was around 1.5GB for the database in question (so it's not small), and the whole thing was completed in a few minutes.
I had the same error. I fixed it by switching the order in which I dropped the tables at the beginning of the file:
DROP TABLE IF EXISTS table_name;
This line is repeated for each table. Tables with foreign keys need to be deleted before the tables with the primary keys to which they point.
The series of events that lead to this oddity are as follows:
mysql> DROP TABLE `mytest`;
ERROR 1051 (42S02): Unknown table 'mytest'
mysql> CREATE TABLE `mytest` (id INT NOT NULL PRIMARY KEY,_modified DATETIME, KEY(_modified));
ERROR 1050 (42S01): Table '`mydb`.`mytest`' already exists
mysql> show tables like '%mytest%';
Empty set (0.01 sec)
I initially thought this might be a file permission issue in the data directory, but I have checked and the files that should be present to represent this table do not exist.
This is mysql version 5.1, myisam tables.
I should probably also mention that this occurs during an automated nightly restore of a large database, which is pulled from backup location as a gzipped tar archive, extracted into the mysql data directory and then myisamchk is run against all MYI files in the new directory.
After 2 hours of investigation I am still lost as to what could be causing this - any assistance would be appreciated.
try this
CREATE TABLE `mytest` IF NOT EXISTS ELSE TRUNCATE `mytest`
Use TRUNCATE to empty the table and reset cardinality instead of deleting the table and recreating it.
try this :
mysql> DROP TABLE '`mydb`.`mytest`'
Seems like broken indexes or definition files.
Try to stop mysql, go to the mysql's data directory, delete the files for the particular table, and restart mysql. Be careful not to delete other files.
If it's InnoDB type, than some command to repair broken tables could help.
IIRC it's CHECK TABLE ... and REPAIR TABLE.
I'm trying to import this sql in my database name symfony
CREATE TABLE IF NOT EXISTS ingredient (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
and i get
#1146 - Table 'symfony.ingredient' doesn't exist
This seems rather odd since i'm trying here to CREATE this table, so... why is it not working ?
I've got the same problem if i try
CREATE TABLE symfony.ingredient
Or the feature in symfony 2
c:\Dev\Symfony>php app/console doctrine:schema:create
PS: I have this problem only with the new version of xampp.
EDIT
Well, i somehow managed to solve my problem.
I dropped my database, then created one (not with the interface) and finally i restarded mysql service.
I don't know why and how it unstuck me, but i hope this will help someone.
I had the same problem.
My solution:
Change table name in the create table query, exequte it and then rename the table.
Then, you can also drop this table and after it create it without getting error.
What worked for me was:
Going to the folder xampp/mysql/data/database-name/
You'll see only the .frm file. The files .MYD and .MYI are missing for empty tables.
Delete the .frm file.
Stop MySQL process and restart it.
After that I was able to create the table.
The old version of xampp created tables in MyISAM format the new version as InnoDB!
I had this same problem. I got a "server went away" message when creating the table and after that I was getting table doesn't exist messages, but I couldn't try to re-create the table because then I got a message saying that it did exist. I solved it by executing this at the command line:
mysqlcheck --repair --all-databases -u root -p
It also wouldn't hurt to restart the mysql server after this as well just in case.
Hmm, are you sure you have a database and are priviledged to do CREATE statements.
If you have phpmyadmin:
To test the first possibiblity, create a new (empty) test database, click it in the menu and
then press the SQL button in the top navigation and copy paste your statement again. If this doesn't work try the second.
For the second you can click on the 'home' button and then go to 'Privileges'. If there are only two or three accounts, but all with root privileges, you have the privileges to do a CREATE. Otherwise you can check your account and give yourself the privileges.
If both possibilities didn't work-out I don't know either. It worked fine for me :(
I had the same issue: #1146 - Table 'tutsplus_ci.posts' doesn't exist. I solved this issue following these steps:
I made an export of the incriminated table in a sql file. I noticed that the table name in the .sql file has a suplemental trailing space.
I switch back to phpmyadmin in Operations section of my table and I rename the table from ' posts' to 'posts'. After taken all these actions the error didn't show up.
To conclude, indeed the table 'posts' didn't exist as error message said. Because the the actual name of the table was ' posts' not 'posts'. The space before the name is hard to be notice in phpmyadmin. This is the story. Nothing special.
I hope it helps!
Go to the database in phpadmin and in sql drop the table .Then create the table.
may case in win & mac with case-insensitive fs
lower_case_table_names=1
reference https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_lower_case_table_names