I have a MyISAM database with MyISAM and InnoDB tables, I want to migrate this database to another server, For MyISAM simply copying the .frm .MYI and .MYD works but for the InnoDB tables how they can be moved to new server?
Assuming that the configuration and versions are identical, and that the source server is completely shut down, you can move the ibdata file and all of the *.frm and *.ibd files. But it isn't advised.
The portable way to move all (or some) of the databases is to dump them using mysqldump and restore them on the target using mysql.
Related
this isn't my exact situation but close enough for description.
On a MySQL 8.0.28 instance on an ubuntu 22.08 server, I have a database 'important' that contains only MyISAM tables. Within MySQL I:
DROP DATABASE important;
then continue to 'do stuff' with other databases etc. Some time later, I decide I want that 'important' database back (without restoring other databases). Luckily I have a physical backup of the MySQL data folder, specifically including the 'important' directory.
If I stop the server, copy the 'important' directory back in place, then restart the server I hoped (and was the case under MySQL 5) that the database would re-appear, but it doesn't.
As far as I can sell, MySQL 5 used to physically scan the directory to look for databases whereas MySQL 8 seems to have a separate idea of what databases exist. To clarify, I am only using MySQL 8.0.28 in this scenario - the backup was made under the same version as I'm restoring to.
My question is, how can I make this database reappear? Perhaps that's "How can I make MySQL 8 rescan its database of databases"?
I think you're in uncharted territory.
It's true that in MySQL 5.x, you could create a schema simply with mkdir, creating a subdirectory under the data directory. Within that directory, each MyISAM table has three files: tablename.MYD, tablename.MYI, and tablename.frm. The frm file has metadata about the table and its columns, so the MyISAM storage engine could discover new tables simply by reading their respective frm file.
This was not possible for InnoDB in 5.x, because InnoDB had an internal data dictionary stored in the ibdata1 tablespace in the data directory. The data dictionary had to maintain duplicate metadata about InnoDB tables.
In MySQL 8.0, they eliminated frm files completely. Tables of all storage engines are managed by the InnoDB data dictionary. There is no interface to the data dictionary besides DDL statements like CREATE/ALTER/DROP. There are several benefits to this change.
This means you can't use external shell commands like mkdir and cp to create schemas and tables. You have to use DDL to communicate to the data dictionary. It's not only stored on disk in the InnoDB tablespace, but it's also cached as objects in the MySQL Server process. Using DDL updates both.
I have not tried this with MyISAM tables (I haven't used MyISAM tables if I can avoid it for over ten years), but in theory you could use CREATE SCHEMA and CREATE TABLE to recreate empty tables that match the definition of the tables you're restoring. Then outside of MySQL, use cp to copy the tables you want to restore over the empty data and index files. I would shut down MySQL Server before doing this, to hopefully avoid any race conditions or conflicting with file caches.
I have no idea if that will work. I would test these steps first on a test instance (not your production instance).
If innodb database is same, and I need to restore table from previous backup, is it ok to copy paste ibd.frm file or do I need to restore separately and then import it?
NO. If all you have is files, not a mysqldump, then it is "all or none" for InnoDB.
You could create another MySQL instance (on the same machine or different), mysqldump the one table, then reload it.
I physically moved the database and now I am not able to restore Innodb database.
I am getting this error-
140131 13:03:41 [ERROR] Cannot find or open table table_t1/t1#P#p0 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.
Help me to restore this db
Put it back and move it through the SQL interface (e.g. RENAME TABLE).
looking to optimize mysql5.5 databases for INNODB. I have tried the link
Note: The databases also contains MYISAM tables.
Howto: Clean a mysql InnoDB storage engine?
As per the instructions I have dropped all databases as well as ibdata* and ib_logfile* and made changes in my.cnf like
[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
Now on restoring the backup, not only mysql storing INNODB tables in separate files, but it is doing it for MYISAM tables as well.
This is resulting in MYISAM database unusable.
when I am trying to access the website having MYISAM tables I am getting the error - Error displaying the error page: Application Instantiation Error
Can't makeout why mysql is storing MYISAM tables in separate files.
Thanks.
AFAIK MyISAM always stores tables in their own files (3 files per table: .MYI, .MYD and .frm).
It is not allowed to remove the ibdata file. Do you have a backup of that file? To move from single file to file per table you need to do as stated here: http://dev.mysql.com/doc/refman/5.0/en/innodb-multiple-tablespaces.html (see under "Enabling and Disabling Multiple Tablespaces")
I'm the lucker owner of a webhotel where the host changes settings without telling.
When thats said,
I have some tables in my database that are running with InnoDB engine.
But over the night the host have disabled InnoDB, so I cant convert it to MyISAM with ALTER command.
Anyway I can get the data out of the database, or convert it to MyISAM when InnoDB is disabled?
Only thing I see all the time is,
#1033 - Incorrect information in file: 'file.frm'
Thanks.
Unfortunately, you need to have InnoDB enabled so that MySQL could read the data for conversion.
To recover the data on another instance, you would need ibdata* files from MySQL root data directory as well as all *.ibd files from your database directory (if your MySQL setup had innodb_file_per_table enabled).