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
Related
I was running an optimize on a 70GB+ data table (after adding a bit column), and the database just crashed.
When browsing the data folder, I have a [table].ibd file and a #sql-*.ibd orphan file.
The only way I could restart mysql daemon was to start it with innodb_recovery_mode = 6.
But when reading the table, the columns have values that do not make any since.
One of the columns that is of type BIGINT just repeats the same number for rows on end...
I tried do DISCARD TABLESPACE and the IMPORT it again - it crashes the service while doing it.
InnoDB warns about corrupted table and also corrupted indexes.
I'm looking for help to try and recover the data, since it is very important.
Is it possible to read the .ibd file and recover the data?
I also used "undrop-for-innodb" to try to recover the data, but the values in the rows make no sense.
Thank you in advance.
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/
I was looking for ibdata1 file size but got wondered by seeing it just 11MB. There is also another folder by name manu which is same as database name and it is 15GB. ( on my local machine)
I looked into live server and their it is quite opposite!
ibdata1 file is 128 GB and folder having .frm + .MYD +.MYI files size was less.
If I look for statistics (local machine)-
manu DB is 15GB
ibdata1 is 11MB
and along with this, in folder 'manu', every table has 3 files - (just for an example: table NEWS).
NEWS.frm
NEWS.MYD
NEWS.MYI
many times I have dropped all the tables from 'manu' (on my local) and recreated table.
My question is- why the live DB has everything in ibdata (I assume ibdata1 will contain all data what we see in mysql tables) and why on live ibdata1 is very less and files related to them are large in size. Is it not storing all the data in ibdata1 on my local?
What may be the issue.
Actually I wanted to rebuild the DB and set innodb_file_per_table since many deleted table have not released the space and DB size is growing bigger.
This is because your local server uses a different engine for tables than your live server.
When tables are of engine InnoDB their data is stored in ibdata1, when they are stored in .MY* files they are of engine MyISAM.
In a database there can be even a mix of tables with different engines.
The main difference is, that InnoDB is capable of transactions. Which means that statements can get reverted when anything fails, while this is not possible with MyISAM.
A default engine for newly created tables can be specified when creating the database. I guess that happened in your case. You can simply dump your tables and in the created backup script you can replace the engine at the end of each CREATE TABLE statement. Then insert the data again and you're fine.
I Know that this is a bit old question, but an important thing to add is that ibdata stores the data from InnoDB Tables by 2 ways:
1- Without my.cnf (my.ini) innodb_file_per_table enabled, all the data from InnoDB tables are stored into the ibdata file, if somewhat it corrupts, congratulations, you just lose everything!
2- with my.cnf (my.ini) innodb_file_per_table enabled, each table (.frm) will have its own data file (.ibd) and ibdata1 will be used as "cache"/"working file", if you corrupt your mysql you can recover your data with the .ibd files.
Some ways to recover your tables for dump (after the operations the tables become useless) are as follows:
http://www.chriscalender.com/recovering-an-innodb-table-from-only-an-ibd-file/
http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html
http://www.quora.com/Jordan-Ryan/Web-Dev/How-to-Recover-innoDB-MySQL-files-using-MAMP-on-a-Mac
If you lose your data, never, EVER use "innodb_force_recovery" before backing up your files, as this will destroy your ibdata files, even with values 1, 2 and 3, there is a risk, with values 4, 5 and 6, its certain to cause damages as they're a more agressive way to force mysql to read the data for dumping. (details: http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_force_recovery)
Lastly but not less important, to avoid getting a corrupt ibdata file and losing your data, ALWAYS EXPLICITY DECLARE innodb_fast_shutdown=0 in your my.cnf (my.ini) file, as its default value if you don't declare it, is "1", fast shutdown will ignore some security operations and can easily corrupt your ibdata file.
details: http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_fast_shutdown
More InnoDB Parameters:
http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html
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 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?