When changing the content of an InnoDB MySQL table the following files on the file system appears to be involved/changed:
/path/to/mysql/data/[database]/[table].ibd (due to innodb_file_per_table)
/path/to/mysql/data/data/ib_logfile0
/path/to/mysql/data/data/ib_logfile1
/path/to/mysql/data/data/ibdata1
For each of these files:
When is the file created?
When will the file be written to?
When will the file be read from?
What would be the consequence if the file is corrupt or deleted?
/path/to/mysql/data/[database]/[table].ibd (due to innodb_file_per_table)
This is where you data are stored. They are created when you create the tables.
/path/to/mysql/data/data/ib_logfile0
/path/to/mysql/data/data/ib_logfile1
These are logfiles.
All data changes are written into the logfiles sequentially, which allows write-ahead logging (crucial for transactions)
/path/to/mysql/data/data/ibdata1
This is where system data and UNDO data are stored.
If ibdata is not found, MySQL will think that InnoDB engine is not initialized and just create the new ibdata. Same with logfiles.
If a query is issued against a table, and .ibd file is not found, MySQL will fail with this message:
Cannot find table database/table from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
Related
MySQL server suddenly stopped working and the service would go on and off and I could not take backup as the service would not run so best I could do is Copy the whole DATA folder .
Also I had a earlier backup so using that along with the ibd files i restored all the table except one for one last table its saying :
ERROR 1808 (HY000): Schema mismatch (Clustered index
validation failed. Because the .cfg file is missing, table
definition of the IBD file could be different. Or the data file
itself is already corrupted.)
And I have no clue what to do.
I think the only thing you can do is rely on the version of the table from your backup. You cannot restore the .ibd file you copied.
The error message is saying one of two things happened:
The table structure changed since the backup was made, so the .ibd file no longer matches the metadata stored in the data dictionary. When the content of the tablespace file doesn't match the metadata, InnoDB is in the same boat as you are: "I have no clue what to do."
Even if the table structure did not change, the .ibd file was physically corrupted enough that it cannot be read by InnoDB.
Either way, that tablespace file cannot be read by InnoDB.
Obviously this creates a problem if you restored all the other tables successfully. Now you have more current data in most of your tables, except for the last one, which is outdated. If there are any rows in these tables that reference each other, they may have orphaned records (for example, a record showing a certain user bought a product, but the user doesn't exist in the users table).
That's unfortunate, and difficult to correct.
In general, copying .ibd files is not a reliable way of backing up an InnoDB database. You need to use proper backup tools like mysqldump or Percona XtraBackup.
Another solution to restore data after your last backup is to use point in time recovery using binary log files. But for that to work, you would need all the binary log files since your most recent backup, and the backup would need information about the binary log position when the backup was taken. See https://dev.mysql.com/doc/refman/en/point-in-time-recovery.html
I want to clone an InnoDB table.
Because of the large scale of data (nearly 10G), I'm tring to clone it by copy data file *.frm and *.ibd.
However, It didn't work.
Whatever I executed on the new copied table, it said:
ERROR 1146 (42S02): Table 'XXX' doesn't exist
So, how can I fix it ? or is there an efficient way to clone a large-scale table ?
As you noticed just copying the files is not enough. That's because in order for a table to work tablespace metadata InnoDB stores in .ibd file needs to match metadata stored in ibdata1 file. That's why the recommended way of restoring InnoDB table is using backup tools like mysqldump.
There is however a way to make it work by copying files, but you need to take some extra actions to update tablespace metadata files. You can find detailed instructions here: http://www.chriscalender.com/tag/innodb-error-tablespace-id-in-file/
Can you create a copy of a table by simply making a duplicate of .frm file?
I intend to do something like this:
Suppose my database's name is mydb and it has a table called mytab.
Browse to the folder named mydb in the file system and it has a mytab.frm file.
Then copy the contents of mytab.frm into a file called copy.frm
Then i login to mysql and run the following commands:
use mydb; //Selects the database mydb
show tables; //To see the list of tables. I can see the table named copy.
select * from copy; //This throws the error mentioned in the title.
So what am I missing? What files do you copy to take the backup of a database?
I know that table can be copied by a couple of sql statements But i want to learn something knew so I am experimenting around. Thanks! :)
Just throwing this down as an answer:
You can't do what you have tried for InnoDB tables. InnoDB stores all table data in a single file - ibdata. You can modify this with the innodb_file_per_table setting in my.cnf, but it isn't retroactive, it will only apply to new tables. Even if you DO have file per table setup, you still shouldnt try and just copy the data files, because innodb may not have flushed all changes from the ib_logfile's to the ibdata / .ibd file, so you could well end up with corrupt data.
You can do it for MyISAM tables but you shouldn't (and there are also other files that to be copied as well, as the .FRM is only the table definition. The .MYD file contains the data and the .MYI file contains the indexes). Why? because you are entrusting your data to a database, you should be using database tools to duplicate it. The only time you should be touching the data files directly is during data recovery, and only when the server is not running - you dont want to be copying the files as they're being written to.
To duplicate a table, simply do this:
create table new_table as select * from old_table
To backup an entire database, use mysqldump or one of the other available backup tools.
TL;DR
Copying/moving MySQL tables by altering the underlying files is possible in some conditions but it is highly unrecommended.
Always use MySQL commands to do it.
The .frm file contains only the table definition. The data and the indexes are stored in other files and they depend on the storage engine of the table.
Several excerpts from the official documentation:
MyISAM
15.2 The MyISAM Storage Engine
Each MyISAM table is stored on disk in three files. The files have names that begin with the table name and have an extension to indicate the file type. An .frm file stores the table format. The data file has an .MYD (MYData) extension. The index file has an .MYI (MYIndex) extension.
InnoDB
14.1 Introduction to InnoDB
By default, with the innodb_file_per_table setting enabled, each new InnoDB table and its associated indexes are stored in a separate file. When the innodb_file_per_table option is disabled, InnoDB stores all its tables and indexes in the single system tablespace, which may consist of several files (or raw disk partitions).
14.2.15.1 Role of the .frm File for InnoDB Tables
MySQL stores its data dictionary information for tables in .frm files in database directories. Unlike other MySQL storage engines, InnoDB also encodes information about the table in its own internal data dictionary inside the tablespace. When MySQL drops a table or a database, it deletes one or more .frm files as well as the corresponding entries inside the InnoDB data dictionary. You cannot move InnoDB tables between databases simply by moving the .frm files.
14.12 InnoDB Startup Options and System Variables
innodb_file_per_table
When innodb_file_per_table is enabled (the default in 5.6.6 and higher), InnoDB stores the data and indexes for each newly created table in a separate .ibd file, rather than in the system tablespace.
MySQL Glossary
system tablespace
One or more data files (ibdata files) containing the metadata for InnoDB-related objects (the data dictionary), and the storage areas for the undo log, the change buffer, and the doublewrite buffer. Depending on the setting of the innodb_file_per_table, when tables are created, it might also contain table and index data for some or all InnoDB tables. The data and metadata in the system tablespace apply to all the databases in a MySQL instance.
Prior to MySQL 5.6.7, the default was to keep all InnoDB tables and indexes inside the system tablespace, (...) In MySQL 5.6.7 and higher, the default is file-per-table mode, where each table and its associated indexes are stored in a separate .ibd file.
Let's draw some (partial) conclusion
Before anything else you have to stop the MySQL server (to be sure all the data is safely stored into files).
If the table you want to copy uses the MyISAM engine then you need to copy/rename the .frm, .MYD and .MYI files having the same name as the table.
If the table uses the InnoDB engine and at the moment when it was created the innodb_file_per_table setting was ON then you need to copy/rename the .frm and .ibd files having the same name as the table.
If the table uses the InnoDB engine and it was created while the innodb_file_per_table setting was OFF then you cannot copy or move the table data from outside MySQL.
If the table uses the MEMORY table then it's enough to copy the .frm file and restart the server. The table data and indexes are stored in memory, there is no file for them and the source table will be empty after the server restart, so you get an exact copy of an empty table ;-)
But wait, there is more!
MySQL implements several other storage engines that are probably less used than the ones mentioned above. Each of them has its own rules of storing the data in files.
And more
If the server you want to hack this way is part of a replication cluster the changes you do either are ignored (do not propagate to the other servers in the cluster if you change a slave server) or break the replication (the slave servers are required to query and update a table they don't have, if you change the master server).
The conclusion
Even if, in certain conditions, copying or moving a table by changing the underline files is possible, it is strongly not recommended.
The correct (and many times the only) way to copy a table is to use the commands provided by MySQL.
13.1.14 CREATE TABLE Syntax
Use LIKE to create an empty table based on the definition of another table, including any column attributes and indexes defined in the original table:
CREATE TABLE new_tbl LIKE orig_tbl;
The copy is created using the same version of the table storage format as the original table. The SELECT privilege is required on the original table.
You can then use:
INSERT INTO `new_tbl` SELECT * FROM `orig_tbl`
to copy the data.
Another way
An alternative way to copy a table without writing SQL commands is to export the table definition and data using mysqldump, open the export file in a text editor, change the table name in all the places where it appears, save the file and import it into the database using the mysql command line tool (or other MySQL client).
You have to copy 3 files: copy.frm copy.MYD copy.MYI
Make privileges for files, owner and group
chown mysql.mysql copy.*
chmod 660 copy.*
and refresh tables in mysql :
mysql DATABASE
mysql> flush tables;
and voila!
I have a serious problem in my MySQL tables , once there were InnoDB tables which were IN USE and now are somehow hidden
look at this [pic] *Link removed - the number of tables in heading is 79 and actual counted number is 74.
these tables are those that were IN USE
I don't have any recent backup of my database , so this would game of life and death for me
I checked my VPS, I found them at /etc/lib/mysql/db_name/.
EDIT :
I Searched around internet and I found out that every table should have 3 files related to it.
For example, the table table_users has:
-- table_users.frm
-- table_users.MYD
-- table_users.MYI
and for those hidden table , there are only .frm files and the other two files of a table are missing.
I should change my question to: How to recover a innodb table from a .frm file?
InnoDB does not have those three files
InnoDB data is stored in "ibdata1" for all databases and tables.
the table definition is stored in "tablename.frm"
I would say that your InnoDB file has become corrupted, you may want to have a look at these tools:
https://launchpad.net/percona-innodb-recovery-tool
UPDATED
First of all, about the files:
.frm - table structure;
.myd - table data;
.myi - indexes.
To recover tables, you can try (make backup first):
1) run check table tablename - for all db tables;
2) run repair table tablename - for necessary tables.
UPDATED ONCE AGAIN
Another idea... Try this:
Create a new database to restore and create the tables with same name as .frm files (with the one field - only to create new .frm files);
Stop mysql service and replace the created .frm files with yours;
Start mysql service and check.
I expect correct tables (without data, of course). And sorry, for now I have no PC to check, before suggesting...
actually me too was having the same problem with the missing two files. later i found that when the table's type is innodb then the database folder would have only one associated file.
but you can change the table type to myisam to get all three file for the table.
now as per the backup, you can export the database whenever and wherever you want :)
PHP is GREAT :)
![innodb image][1] INNODB SYSTEM TABLESPACE
INNODB system tablespace is contain in the mysql data directory---
INNODB is system tablespace is divde into two parts
1>.frm
it can describe the table format or you can say it is a table *definition*
2>.ibd
it is contain all system related file and it is also contain data and index and ( InnoDB main table space contain – ibdata1 – and redo logs – ib_logfile*.)
ibdata1 contains your InnoDB database and ib_logfile0 and ib_logfile1 are log files for InnoDB.
If you delete your ibdata1 file, then all your InnoDB tables will be lost.
By default, InnDB uses a shared "tablespace," which is one or more files from a single logical storage area. All InnoDB tables are stored together within the tabespace (from all the databases). By default, InnoDB creates two 5MB log files in the data directory: iblogfile0 and iblogfile1. The information is logged in circular fashion, with old information at the front of the log being overwritten when the log fills up.. Consequently, a larger log allows InnoDB to run longer without having to force changes recorded in the logs to be applied to the tablespace on disk.
When recovering a MyISAM table the only file that is strictly needed is the data file (tablename.MYD) - the rest of the files (the index file tablename.MYI and tablename.frm) can be recreated from the data file using REPAIR TABLE.
Assume I'm using InnoDB (with the "innodb_file_per_table" setting) instead - what is the minimum set of files needed to recover a database table from file?
As long as you have the data file and the log files then InnoDB will be able to recover. See this page (and containing chapter) on MySQL.com for more. InnoDB recover is quite different to MyISAM in that is more "built-in" as it were.
To recover MyISAM table you need frm and MYD file. myisamchk can rebuild the index (MYI file)
For InnoDB - depends on innodb_file_per_table. If it's OFF (default), your data in ibdata1. But you need .frm file too.
If it's ON - you need ibdata1, the respective .ibd and .frm file.