I want to purge the ibdata1, ib_logfile0 and ib_logfile1 files in MySQL. Because these files are taking too much space of my C:\ disk. And I don't want to move these files anywhere else in the Hard disk. I heard about purging which can shrink the data. I am using Windows Vista. What are the steps to be done to purge the data ?
The log files can be removed anytime. Only the most recent log is kept open/locked. However, deleting id_data will trash all of your InnoDB databases - that's the actual data store.
As pointed out by MarcB, you can delete the (old) logfiles without problems; MySQL does not need them to run.
The data file ibdata* must not be deleted, it contains the actual database data.
I will grow as the database grows; unfortunately there is not way to shrink it, even if you later delete data from the database. The only way is to dump and reimport the whole database.
Also see this question: MySQL data file won't shrink
It explains various options to better cope with growing data files.
Short answer: There's no way to reduce the size of the ibdata files once they grew to a certain size. MySQL recommends dumping all innodb type data, shutting down mysql, deleting the ibdata files and restarting, then loading the data again. A one-click "compact" solution like other systems have is still missing.
Related
I have a MySQL-Server 5.5 with around 5.000.000 records in each table.
Now i want to activate the variable "innodb_file_per_table = 1".
Is this possible?
Is there any risk to do that?
The Reason is for activating the option, is to optimize performance.
Thanks and Regards
Chris
innodb_file_per_table is a dynamic variable -- changing it can safely be done without even restarting the server... but the big caveat is that you can never reclaim the disk space consumed by the ibdata file.
Tables that are rebuilt with the setting enabled will have their own tablespace files, but ibdata1 cannot be shrunk without a dump, followed by removal of ibdata1 and reinitialization of the server, and then a reload of all the data.
"Performance" is not necessarily a valid reason to change the setting on a working server.
It is possible. All advantages and possible disadvantages are mentioned in official docs
Also you should be aware that only new tables will be created in separated tablespace or you can rebuild any existing table to moved from shared tablespace.
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.
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 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.
The short question:
Is it safe skip ib_logfile* files while creating custom-made backup of MySQL installation with InnoDB engine used?
Custom-made backup is just copy all (or subset of) /var/lib/mysql + /etc/my.cnf to safe place.
As I know ib_logfile* files are recreated by MySQL on start + the files are really huge, so that may not be wise to store them in backup. And yes, assume MySQL is (correctly) stopped before backup.
It's not safe to back up a database in the manner you're describing.
The reason is that you cannot know if some data pages are still in MySQL Server's memory, pending an I/O flush to disk. So copying the files has a good chance of copying garbage, whether or not you include the ib_log files.
Don't do what you're doing. Use mysqlbackup or InnoDB's Hot Backup product.
edit:
Read Farhan Mashraqi's blog article about InnoDB Performance Optimization, in which he says you can delete the ib_log files if you have shut down MySQL Server.
InnoDB log resizing: is not as simple
as changing option and restarting. You
need to shut down MySQL server and
make sure it shuts down normally
(check error log for errors to
confirm). Then move away InnoDB log
files ib_log*. Then start the MySQL
server and check error log files to
see if it successfully created new log
files.
So yes, you should be able to do a filesystem copy of the ibdata files only. You don't need to include the ib_log files, because they should be recreated as MySQL Server starts up. I reiterate, however, that I do not recommend backing up databases with filesystem copy.
Suppose you back up a database today in this manner, using MySQL 5.0. Someday later you need to restore the backup, but by that time you'll be using some future version like MySQL 6.5 for example. Do the ib_data files still use the same internal format in that future version? Will MySQL 6.5 read those files you backed up today? You can't be sure. The backup format is intended to be more portable.