Where i can find MySQL data file - mysql

Where I can find file with all records from my Database?
I have DB "selloffi_bot" with 1 table "gen" where are ~12.000.000 records. Table size is 1.5GB. I want to copy all data files without mysqldump. Just copy 1:1 from my VPS to my PC.
I checked /var/lib/mysql/selloffi_bot and i found only 2 files
db.opt - 65B
gen.frm - 8620B
Debian 7.0 64-bit minimum
PHP Version 5.4.4-14+deb7u14
MySQL Version: 5.5.40

If you're using InnoDB, it's in the ibdata files. Also see here:
https://dba.stackexchange.com/questions/80320/where-does-mysql-store-data/80332
Edit: As Isaac notes below, the ibdata files aren't really meant to be portable, so the only reliable thing to do is to dump and load the data.

Related

Restoring MySQL Databases when reinstalling Wamp

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.

How to restore innodb tables without ibdata1 and *.ibd files

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.

MySQL db had disappeared how to track what happened?

Two days ago I have installed RoundCube mail script working on:
PHP
Name : php
Arch : x86_64
Version : 5.3.18
Release : 1.el6.remi
MySQL
Name : mysql
Arch : x86_64
Version : 5.5.28
Release : 1.el6.remi
Anything worked just great till today morning, script refers that Round Cube database has problems. How wonder was I am looking at directory:
/var/lib/mysql/roundcubemail
There is only frm files, no any .myd or .myi
cache.frm
cache_index.frm
cache_messages.frm
cache_thread.frm
contactgroupmembers.frm
contactgroups.frm
contacts.frm
db.opt
dictionary.frm
identities.frm
searches.frm
session.frm
users.frm
My server has 12 databases and now only Round Cube db missing .myd .myi files. Re-install this script is not a problem but I am interesting to figure out what was happened to this database and to be sure that it will not going to happen again.
MySQL error log has only this information:
121117 7:38:06 [ERROR] Cannot find or open table roundcubemail/session 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?
or, the table contains indexes that this version of the engine
doesn't support.
See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
how you can resolve the problem.
My question is: Is there any other methods to track this situation and find the reason that database just had disappeared?
.myd and .myi files only exist for MyISAM tables.
If you followed the standard Roudcube installation procedure (verified with v0.8.4), tables were set to use the InnoDB storage engine.
Have you messed with any file under /var/lib/mysql/ ? By default, InnoDB tables are stored in one single file, probably /var/lib/mysql/ibdata1 in your case. If not, look for the innodb_data_file_path directive in your my.cnf configuration file.

Having different ibdata file for multiple databases

I have my MySQL server running with 4 databases and innodb_data_file_path set to the default configuration[ibdata1]. I see the size of this file on disk growing as big as 1GB. This file will only grow as the application that runs this server is collecting the monitoring data.
Just not sure how this will have performance issue with such a large file size.
Is there a way to split this file per database? so that each database can have its own ibdata file. I know InnoDB has an option where this data file can be split per table (still maintaining a shared tablespace), but could not find any option to split this file per database.
Can someone please help me out here?
Add this option to my.cnf : *innodb_file_per_table*
Reference :
http://dev.mysql.com/doc/refman/5.0/en/innodb-multiple-tablespaces.html
There should be a separate tablespace file per database already. You should see an ibdata file in each subdirectory for the different databases in the mysql data directory.

MySQL InnoDB database restore

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.