I am attempting to restore my old databases to a new Wamp installation. However, I did not take a backup of Mysql files before I did this. Thankfully the uninstallation has not deleted all the files, but in my data folder I have :
1) All the databases (As folders)
2) auto.cnf
There are no ib* files in the old folder. Is it still possible to restore my databases somehow?
I have tried to replace the entire mysql5.6.17 folder (there has been no change of version between the installations), but Wamp remains orange and never turns green.
If I replace only the data folder, the MySQL service starts, I can see the databases, but not the tables.
If I change the path in my.ini to point to the old wamp's data folder, I cannot see the old databases at all.
EDIT : Was experimenting a bit, copying the database folders directly into the new Wamp's data folder allows me to get a list of all the tables properly, but there is no actual data in the tables, and trying to query it using MySQLWorkbench gives me the error :
Error Code: 1146. Table 'testdb.users' doesn't exist
EDIT 2 : Found this in the error log file in my data folder :
2014-08-03 06:24:46 25164 [Warning] InnoDB: Cannot open table testdb/users from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
As I thought, its a problem with InnoDB's own mapping. Is there a way to resolve this manually?
If you created an INNODB database, and made no other config changes to store the actual data in seperate table spaces then all the actual data for that INNODB databases will have been stored in the \wamp\bin\mysql\mysql5.6.17\ibdata1 file.
If you do not have that file from the old install then your data is lost.
There will also be info in a \wamp\bin\mysql\mysql5.6.17\data\DATA_BASE_NAME\ folder, one .frm file for each table that was in the database, but this is basically just schema information and not actual data.
For future reference, InnoDB Backup and Recovery
GOLDEN RULE:
Always backup database (from phpmyadmin) before major changes.. better to spend 1 minute for that, than going into trouble..
How to Copy data folder
If you want to copy the database, then INSTALLATION/mysql versions should be same.. then rename newly installed data folder to i.e. data_my_old,so now there you can place the backuped data folder (it should contain ibdata1 file).
Depends on innodb_file_per_table setting.
If it was OFF then all your tables were in ibdata1. Now you have quite new ibdata1 (since you see errors "Cannot open table testdb/users from the internal data dictionary", that means InnoDB runs fresh new dictionary). That means that now the data is somewhere on the disk. The recovery is quite difficult and requires a lot of tedious work. You need to take an image of the disk, scan it with stream_parser to find InnoDB pages, then recover the InnoDB dictionary, then find index_id of every table and if the stream_parser has found this index run c_parser to extract records from the index.
If innodb_file_per_table was ON and you do see .ibd files in the databases directories then recovery is much easier. First, you may try to reconnect individual ibd files with ibdconnect or extract records from the ibd files with stream_parser/c_parser.
The mentioned tools are part of TwinDB data recovery toolkit
i have just done a google search and found this....
Go to C:\wamp\bin\mysql\mysql5.5.24\data
Find a file called "mysql-bin.index"
Rename that file to "mysql-bin.index-corrupt"
Restart the server and it will work fine, all your database will be where you left them.
Related
I am running Windows 10 with XAMPP and several dozen Drupal sites installed on localhost. Everything has been working fine for months.
This morning I performed a Windows restore from a restore point two days ago to get rid of an unwanted Windows update. After I did that, my MySQL stopped working. I tried deleting the file ibdata1 (I now know that that was a bad idea), but when things got worse, I restored the initial ibdata1 that I'd deleted. All the table data (.frm and .ibd files) is still in C:\xampp\mysql\data. Now MySQL will at least start, but all the tables are "gone"... I can load phpMyAdmin in the browser, and when I drop down the databases at left, all the tables show... but when I try to click on one, it tells me "table not found."
In mysql_error.log there are several errors like InnoDB: Cannot open table mysql/slave_master_info from the internal data dictionary of InnoDB though the .frm file for the table exists. There is a URL mentioned in the error message that supposedly tells you how to resolve this issue, but it is uninformative.
I don't think ibdata1 is corrupted... and all the articles regarding recovering data are complicated to a degree that is insanely out of proportion to the problem. No one has a simple spelled-out solution. Am I Googling wrong? This has happened to me at least twice before, and each time the problem spontaneously resolved itself before I was able to start following the 10-hour-long procedures I found online. Not this time, unfortunately. Surely I'm missing something simple. I had hundreds and hundreds of tables in a few dozen databases, and it seems hopeless to try to find the schema for each one and manually plug it in, which is what most recovery articles seem to suggest.
Shouldn't the database just know how to read the .frm and .ibd files, and, you know... work? It feels like there's just one value out of place somewhere, and if I could just find it, everything would just "pop" back into place.
What did the work for us was this link (Restoring Orphan File-Per-Table ibd Files).
In brief, you do:
ALTER TABLE ..... DISCARD TABLESPACE;
For each affected table.
Then, for each affected table:
ALTER TABLE .... IMPORT TABLESPACE; SHOW WARNINGS;
You could do that on the same schema or create a new schema in other database and copy all *.ibd files. In this case:
Create the new schema with table definitions.
Do the discard tablespace for all tables.
Copy the new *.ibd files to the right folder of new schema.
Do de import tablespace for all tables.
IMPORTANT! It's better that the new schema has the same name as the old one.
What worked for me:
https://dba.stackexchange.com/a/42932
My dbs was InnoDB, so there is a problem with id and when upgrading the macos, I got this. I will quote the main part:
You must have:
-ibdata1
-ib_logfile0
-ib_logfile1
-.FRM files from your mysql_database folder
-Fresh installation of MAMP / MAMP Pro that you are willing to destroy (if need be)
SSH into your web server (dev, production, no difference) and browse to your mysql folder (mine was at /var/lib/mysql for a Plesk
installation on Linux)
Compress the mysql folder
Download an archive of mysql folder which should contain all mySQL databases, whether MyISAM or innoDB (you can scp this file, or move
this to a downloadable directory, if need be)
Install MAMP (Mac, Apache, MySQL, PHP)
Browse to /Applications/MAMP/db/mysql/
Backup /Applications/MAMP/db/mysql to a zip archive (just in case)
Copy in all folders and files included in the archive of the mysql folder from the production server (mt Plesk environment in my case)
EXCEPT DO NOT OVERWRITE:
-/Applications/MAMP/db/mysql/mysql/
-/Applications/MAMP/db/mysql/mysql_upgrade_info
-/Applications/MAMP/db/mysql/performance_schema
In my case, I was restoring the backup (done by galera-arbitrator and xtrabackup. Using the first one we took state-snapshot and using the last one we backed up the physical data) for Percona_XtraDB_Cluster. So, after placing the backed up data to the dir /var/lib/mysql of the new mysql server, we did the following select query and got error.
$ mysql -uroot -p$MYSQL_ROOT_PASSWORD -h<NEW_SERVER_HOST_NAME> -e 'show columns from <MY_DB>.<MY_TABLE>'
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1146 (42S02) at line 1: Table 'playground.equipment' doesn't exist
And the server log was:
[Warning] InnoDB: Cannot open table <MY_DB>/<MY_TABLE> from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
We just restarted the container the new data. That's it
Just rename slave_master_info.frm to slave_master_info.BAK and that's it. Restart the mysql service.
Yesterday, the hard drive from my dedicated server crashed. The only choice I had was to save what I could, before replacing the hard drive with a new one.
The only thing I could save was the /var/lib/mysql folder. Now I have a new hard drive with a new MySQL database running, but empty. I want to restore the data from the database I had.
I tried several things, and read over the internet that InnoDB export wasn't as easy as copying all the /var/lib/mysql folder, so I'm not sure what solution I have.
I tried to replace the new /var/lib/mysql folder with the new, but now mysqld won't run. The error log looks a lot like this, but adding innodb_force_recovery = 1 is not helping at all.
Now I'm kinda lost and out of options. Anyone faced something similar recently?
Thanks
There is a tool that can retrieve MySQL database from corrupted disk https://launchpad.net/undrop-for-innodb .
I hope you still have old hard drive attached to the server or at least an image taken from it.
Download the last revision and compile it. You'd need gcc, flex and bison as the dependency.
Let's say you have attached the old (corrupted) disk as /dev/sdb
First, you need to scan the disk and find InnoDB pages
./stream_parser -f /dev/sdb
Then you need to recover InnoDB dictionary to know table name -> index_id correspondence. See "Recover InnoDB dictionary" for details.
You would also need tables structure. Take it from some old backup. (Other options would be to recover the structure from .frm files or from InnoDB dictionary)
When you know table structure and index_id of a table you can extract the table records from InnoDB pages:
./c_parser -6f pages-actor.ibd/FIL_PAGE_INDEX/0000000000002655.page -t actor.sql
actor.sql is CREATE TABLE statement
c_parser will generate LOAD DATA INFILE command to load the dump back in MySQL.
By some reason these files ibdata1, ib_logfile0, ib_logfile1 were been deleted from hard drive, mysql server was restarted and of course one of the database stoped with error "db.table does not exist!". Is it possible to restore somehow these files, if there are only *.frm, db.opt files?
Thanks.
Take disk image as soon as possible or mount MySQL partition read-only(if it was not on /).
Then you need to compile data recovery toolkit(install dependencies if "make" fails):
make
Then scan the disk image with page_parser. It will find InnoDB pages and sort them per page type, per index_id.
./page_parser -f /path/to/disk.img
Then you need table structures (either take them from old backup or restore from .frm). You need the structure to compile constraints_parser - a tool that fetches records from InnoDB page(s).
./constraints_parser -5f pages-XXXXXX/FIL_PAGE_INDEX/0-x/
Save output in some file. It will also generate LOAD DATA to stderr to upload the dump back to MySQL.
Check the documentation on Percona's website for more details.
From my experience, 70-80%% of data should be recoverable after this kind of accident.
I have a requirement to store two Innodb database files on separate partitions. (one database on raid0 for speed, the other on raid1 for stability)
From what I've read, the only way to accomplish this is by using innodb_file_per_table and symlinking .ibd and .frm files wherever-they-may-live to the configured mysql storage directory (/var/lib/mysql on my system), where the ibdata1 file must live (for table metadata).
Is this the only way to accomplish the split?
Is there an innodb analog to myisam's TABLE/INDEX DIRECTORY?
Just to update this post if someone ever come across this, InnoDB now support data directory since version 5.6. No symlink (not recommended), and works for both *nix and Windows.
Requirements:
MySQL 5.6 and above
innodb_file_per_table is enabled
innodb_file_per_table = 1
Scenario 1 (create new tables):
It is as simple as specifying the DATA DIRECTORY options during creation of table.
CREATE TABLE t1 (c1 INT PRIMARY KEY) DATA DIRECTORY = '/alternative/directory';
Scenario 2 (moving existing table to separate disk):
This involves few more steps (MySQL server restart required) but still pretty straight forward. And it doesn't requires the table to have DATA DIRECTORY option specified during table creation.
Stop MySQL server
Move the innodb table table_name.ibd file to separate disk/volume by simple file copy/file move
Create a text file with .isl extension e.g. table_name.isl
Edit the .isl file and type in the new path to the table_name.ibd file that you moved.
/alternative/directory/table_name.ibd
Make sure the original .ibd file in old path was removed
Start MySQL server
Now subsequent changes to the moved table will be save into .ibd file in new path.
For reference please refer to MySQL official doc: http://dev.mysql.com/doc/refman/5.6/en/tablespace-placing.html
I just wrote a blog post on this today:
http://www.mysqlperformanceblog.com/2010/12/25/spreading-ibd-files-across-multiple-disks-the-optimization-that-isnt/
You don't want to do the symlinking thing - and InnoDB does not support DATA DIRECTORY/INDEX DIRECTORY.
You actually need stability of the data system wide for InnoDB. Let's say -
You have critical tables A,B,C.
Non-critical tables are D,E,F.
If you relocated D,E,F to /mnt/RAID0, and you lost this volume, InnoDB will actually not allow you to access tables A,B,C any more either.
Unless it can access all your data, InnoDB will refuse to start.
If you have two very different data requirements, you need two installs of MySQL ;)
Scenario 2 MOVE 1 TABLE TO NEW DATA DIRECTORY
Platform - Windows Server,MySQL 5.6
Database - Test
Table - Employee
Source Data directory - D:\Program Files\MySQL\MySQL Server 5.6\data\test\
Destination Data directory -E:\data\New_data\test\
STEPS
Ensure the global variable innodb_file_per_table = 1
Stop MySQL server
Move the innodb file employee.ibd file to separate disk/folder by simple file move to E:\data\New_data\test\
Note - Keep the employee.frm in the original data directory D:\Program Files\MySQL\MySQL Server 5.6\data\test\
in the source data directory - D:\Program Files\MySQL\MySQL Server 5.6\data\test\ - Create a text file with .isl extension e.g. employee.isl
Edit the .isl file and type in the new path to the employee.ibd file that you moved.
In the File -D:\Program Files\MySQL\MySQL Server 5.6\data\test\employee.isl
E:\data\New_data\test\employee.ibd
grant write permission to teh folder E:\data
Start MySQL server
use test;
select * from employee
I have to restore a database that has been inadvertently DROPped in MySQL 5.0. From checking the backup files, I only seem to have .FRM files to hold the database data.
Can anyone advise whether this is all I need to perform a database restore/import from the backup, or are there other files I should have to hand to complete this?
.frm files are not the data files, they just store the "data dictionary information" (see MySQL manual). InnoDB stores its data in ib_logfile* files. That's what you need in order to do a backup/restore. For more details see here.
Restoring innodb:
(assuming your data folder is C:\ProgramData\MySQL\MySQL Server 5.5\data)
Copy the folders of the databases (named after the database name) you want to restore to C:\ProgramData\MySQL\MySQL Server 5.5\data
Copy the 3 ibdata files to the data folder ex. (C:\ProgramData\MySQL\MySQL Server 5.5\data)
_ib_logfile0
_ib_logfile1
_ibdata1
Get the size of the _ib_logfile0 in MB (it should be the same as _ib_logfile1) by File Right click -> Properties
Edit the mysql config file (mysql\bin\my.ini) for the innodb_log_file_size=343M to be exactly the ibdata files size
Run
mysqld --defaults-file=mysql\bin\my.ini --standalone --console
--innodb_force_recovery=6
Now your data should be back in your database. Export them using phpmysql or any other tool
The detailed solution you can found here:
http://www.unilogica.com/mysql-innodb-recovery/ (Article in Portuguese)
Besides the flag of innodb_force_recovery, I found another solution: innodb_file_per_table, that splits InnoDB tables in each file like MyISAM tables.
In a crash recovery you can lost less data than in single file ibdata1.