I've read several posts on this forum and others and still can't read some MYD/MYI/FRM files which contain data that I want to import into SQL Server.
I stopped the MySQL service at the client location and copied all the files (the same way that we would do with SQL Server).
I have installed the most recent MySQL ODBC connector, MySQL engine and MySQL Workbench on my Windows 10 PC. The engine is running and the ODBC connector is configured with a username and password. Using the workbench, I have been able to successfully log in.
I created a MyTest database which created a C:\ProgramData\MySQL\MySQL Server 8.0\Data\mytest folder.
I stopped the MySQL service and copied MyData.MYD, MyData.MYI and MyData.FRM to the mytest folder.
I restarted the MySQL service.
But if I run a "Select * from mytest.MyData" query in the workbench or using the MySQL 8.0 Command Line Client, it keeps indicating that the table mytest.MyData doesn't exist. Now, I read that it might be appropriate to run a CHOWN command but I don't know what if syntax would be different for a Windows system and whether this command would be executed directly from a Command prompt.
Any assistance would be greatly appreciated. Thanks!
Older versions of MySQL let you get away with that for MyISAM tables, but MySQL 8.0 introduced a whole new implementation of "data dictionary" which is a meta-database maintained internally, and it has a bias for InnoDB over MyISAM. So I would believe that moving files around ad hoc no longer works as it once did. To move tables from one instance to another, you should really do the export and import steps properly.
For InnoDB, you may use transportable tablespaces. At least you don't have to do a full data import that way, but it takes a few more steps than just file copy.
P.S.: I haven't used MyISAM in many years anyway. I prefer my database to support ACID properties, and MyISAM does not support any of the ACID properties.
Related
I am currently using mysql server 5.0 with innodb storage engine. I want to backup a database from source server and restore the same to one of the available destination servers.
Option 1: Use innodb_file_per_table option in my .cnf and try to copy the table.ibd file to the other server and recover. I saw examples over other websites where it was being supported in mysql 5.6, but I am not sure if that is supported in mysql server 5.0. I tried the steps given in https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html, but that did not work for me.
Option 2: Use mysqldump to get a dump of the database and use mysqlimport in the destination to perform mysql export/import. But, by doing so, I need to lock the database at source before performing the export. This can prevent any incoming requests to the source database while the mysqldump is ongoing.
I am still exploring other options, but I am not sure if option 1 is not viable due to mysql version 5.0 or because I am missing something.
http://dev.mysql.com/doc/refman/5.7/en/replication-howto.html
You are talking about replication.
During development, how our local WAMP servers get up-to-date data from the test server is that a dump of the database is made and we upload that dump using the source command to load the .sql file.
Recently, at the very end of the import we have been getting errors about the #old variables which stored the original settings like foreign key constraints before they’re changed (so turning off foreign key constraints so that the import doesn’t throw errors when it recreates tables and attempts to create foreign keys when one of the tables has yet to be created). I have worked out that the cause is that the product table is getting more and more data and at a point the session has timed out during the import.
I’m wondering what setting can I set (either as part of the SQL query on in the my.ini file) that will stop all timeouts, in effect making a session last forever while we are signed in.
Strategies for importing large MySQL databases
PHPMyAdmin Import
Chances are if you’re reading this, PHPMyAdmin was not an option for your large MySQL database import. Nonetheless it is always worth a try, right? The most common cause of failure for PHPMyAdmin imports is exceeding the import limit. If you’re working locally or have your own server, you can try changing the MySQL ini settings usually found in the my.ini file located in the MySQL install folder. If you’re working with WAMP on Windows, you can access that file using the WAMP control panel under MySQL > my.ini. Remember to restart WAMP so your new settings will be used. Settings you may want to increase here include:
max_allowed_packet
read_buffer_size
Even with enhanced MySQL import settings you may still find that imports time out due to PHP settings. If you have access to PHP.ini, you can make edits to the maximum execution time and related settings. In WAMP, access the PHP.ini file under the WAMP control panel at PHP > php.ini. Consider raising the limits on the following settings while trying large MySQL imports:
max_execution_time
max_input_time
memory_limit
Using Big Dump staggered MySQL dump importer
If basic PHPMyAdmin importing does not work, you may want to try the Big Dump script from Ozerov.de for staggered MySQL imports. What this useful script does is run your import in smaller blocks, which is exactly what is often needed to successfully import a large MySQL dump. It is a free download available at http://www.ozerov.de/bigdump/.
The process of using Big Dump is fairly simple: you basically position your SQL import file and the Big Dump script together on the server, set a few configs in the Big Dump script and then run the script. Big Dump handles the rest!
One key point about this otherwise great option, is that it will not work at all on MySQL exports that contain extended inserts. So if you have the option to prevent extended inserts, try it. Otherwise you will have to use another method for importing your large MySQL file.
Go command line with MySQL console
If you’re running WAMP (and even if you’re not) there is always the option to cut to the chase and import your large MySQL database using the MySQL console. I’m importing a 4GB database this way as I write this post. Which is actually why I have some time to spend writing, because even this method takes time when you have a 4GB SQL file to import!
Some developers (usually me) are intimidated by opening up a black screen and typing cryptic commands into it. But it can be liberating, and when it comes to MySQL databases it often the best route to take. In WAMP we access the MySQL console from the WAMP control panel at MySQL > MySQL Console. Now let’s learn the 2 simple MySQL Console commands you need to import a MySQL database, command-line style:
use `db_name`
Command use followed by the database name will tell the MySQL console which database you want to use. If you have already set up the database to which you are importing, then you start by issuing the use command. Suppose your database is named my_great_database. In this case, issue the following command in the MySQL Console. Note that commands must end with a semi-colon.
mysql-> use my_great_database;
mysql-> source sql_import_file.sql
Command source followed by the location of a SQL file will import the SQL file to the database you previously specified with the use command. You must provide the path, so if you’re using WAMP on your local server, start by putting the SQL file somewhere easy to get at such as C:\sql\my_import.sql. The full command with this example path would be:
mysql-> source C:\sql\my_import.sql;
After you run that command, the SQL file should begin to be imported. Let the queries run and allow the import to complete before closing the MySQL console.
Further documentation for MySQL command line can be found here: http://dev.mysql.com/doc/refman/5.5/en/mysql.html.
Another solution is to use MySQL Workbench.
This solution worked for me:
max_allowed_packet <-- --> upped size to 8M
read_buffer_size <-- --> upped from 256 to 512
Using Xampp control panel on localhost. After making the changes to the my.ini file in MySQL config, don’t forget to quit Xampp (or Wamp) and restart it for changes to take effect.
(Four days of head-banging and I finally got it fixed!)
Symptoms were on Import: #2006 MySql server went away. However, only 10 table rows were being imported out of 87 table rows.
Consider using MySQL Workbench, it's free and handles very large script very well (from the menu choose: File -> Open SQL Script - if it's large, it will ask you if you'd like run it). Has served me well over the years when working with large SQL dumps.
During development, how our local WAMP servers get up-to-date data from the test server is that a dump of the database is made and we upload that dump using the source command to load the .sql file.
Recently, at the very end of the import we have been getting errors about the #old variables which stored the original settings like foreign key constraints before they’re changed (so turning off foreign key constraints so that the import doesn’t throw errors when it recreates tables and attempts to create foreign keys when one of the tables has yet to be created). I have worked out that the cause is that the product table is getting more and more data and at a point the session has timed out during the import.
I’m wondering what setting can I set (either as part of the SQL query on in the my.ini file) that will stop all timeouts, in effect making a session last forever while we are signed in.
Strategies for importing large MySQL databases
PHPMyAdmin Import
Chances are if you’re reading this, PHPMyAdmin was not an option for your large MySQL database import. Nonetheless it is always worth a try, right? The most common cause of failure for PHPMyAdmin imports is exceeding the import limit. If you’re working locally or have your own server, you can try changing the MySQL ini settings usually found in the my.ini file located in the MySQL install folder. If you’re working with WAMP on Windows, you can access that file using the WAMP control panel under MySQL > my.ini. Remember to restart WAMP so your new settings will be used. Settings you may want to increase here include:
max_allowed_packet
read_buffer_size
Even with enhanced MySQL import settings you may still find that imports time out due to PHP settings. If you have access to PHP.ini, you can make edits to the maximum execution time and related settings. In WAMP, access the PHP.ini file under the WAMP control panel at PHP > php.ini. Consider raising the limits on the following settings while trying large MySQL imports:
max_execution_time
max_input_time
memory_limit
Using Big Dump staggered MySQL dump importer
If basic PHPMyAdmin importing does not work, you may want to try the Big Dump script from Ozerov.de for staggered MySQL imports. What this useful script does is run your import in smaller blocks, which is exactly what is often needed to successfully import a large MySQL dump. It is a free download available at http://www.ozerov.de/bigdump/.
The process of using Big Dump is fairly simple: you basically position your SQL import file and the Big Dump script together on the server, set a few configs in the Big Dump script and then run the script. Big Dump handles the rest!
One key point about this otherwise great option, is that it will not work at all on MySQL exports that contain extended inserts. So if you have the option to prevent extended inserts, try it. Otherwise you will have to use another method for importing your large MySQL file.
Go command line with MySQL console
If you’re running WAMP (and even if you’re not) there is always the option to cut to the chase and import your large MySQL database using the MySQL console. I’m importing a 4GB database this way as I write this post. Which is actually why I have some time to spend writing, because even this method takes time when you have a 4GB SQL file to import!
Some developers (usually me) are intimidated by opening up a black screen and typing cryptic commands into it. But it can be liberating, and when it comes to MySQL databases it often the best route to take. In WAMP we access the MySQL console from the WAMP control panel at MySQL > MySQL Console. Now let’s learn the 2 simple MySQL Console commands you need to import a MySQL database, command-line style:
use `db_name`
Command use followed by the database name will tell the MySQL console which database you want to use. If you have already set up the database to which you are importing, then you start by issuing the use command. Suppose your database is named my_great_database. In this case, issue the following command in the MySQL Console. Note that commands must end with a semi-colon.
mysql-> use my_great_database;
mysql-> source sql_import_file.sql
Command source followed by the location of a SQL file will import the SQL file to the database you previously specified with the use command. You must provide the path, so if you’re using WAMP on your local server, start by putting the SQL file somewhere easy to get at such as C:\sql\my_import.sql. The full command with this example path would be:
mysql-> source C:\sql\my_import.sql;
After you run that command, the SQL file should begin to be imported. Let the queries run and allow the import to complete before closing the MySQL console.
Further documentation for MySQL command line can be found here: http://dev.mysql.com/doc/refman/5.5/en/mysql.html.
Another solution is to use MySQL Workbench.
This solution worked for me:
max_allowed_packet <-- --> upped size to 8M
read_buffer_size <-- --> upped from 256 to 512
Using Xampp control panel on localhost. After making the changes to the my.ini file in MySQL config, don’t forget to quit Xampp (or Wamp) and restart it for changes to take effect.
(Four days of head-banging and I finally got it fixed!)
Symptoms were on Import: #2006 MySql server went away. However, only 10 table rows were being imported out of 87 table rows.
Consider using MySQL Workbench, it's free and handles very large script very well (from the menu choose: File -> Open SQL Script - if it's large, it will ask you if you'd like run it). Has served me well over the years when working with large SQL dumps.
I had MySql 5.1.13 Database on Windows 2008, then on one fine day I took backup of my server [300+ databases]. Uninstall Old version and install 5.5 Version of MYSql. Now I copy the Data Folder back in Mysql 5.5 data location and I got all my Databases, but later I realise that around 250 Databases though did present at location but they do not show Tables in PHPmyadmin. I try to run "Show Tables" on couple of those database and Tables name does shows [and so as tablename.frm files exits] .
not to mention all tables that are Innodb are only one missing. How can get them back with ease. I have backup of each database but running 250 SQL files is not easy :).
Your innodb engines can have their own seperate folder where they store their data files. According the MySQL manual InnoDB creates tablespace files in the MySQL data directory by default see: http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html.
Normally you would split you tables onto different drives to increase performance thus you might have a scenario where the InnoDB tables where configured to be placed on a another drive or folder. If you have it please check the previous MySQL configuration file and check for the following line: innodb_data_home_dir = /ibdata
This will indicate where the files are located. I have not tried this but you should be able to point the current config to the old innodb location if this is the case. If that does not work I think restoring will be you best bet.
Good luck!
I have a user Database that I managed to recover after a Hardware failure, however when I try and import it to my new MYSQL database in PHPMyAdmin it says that it cannot read it due to it being for another version of MYSQL. I have no idea what version of MYSQL my older corrupted server was?
I'm having to get my customers to manually re-register and me setting everything up manually again which is going to take hours.
The file I have is "users.MYD". Is there any way of importing ignoring compatibility issues?
My advice is to install the same version of MySQL that you previously had, stick that MYD file (and others) into it, start MySQL, mysqldump out the data and then insert that into your new MySQL database.
[ appended ]
After much searching around, it does appear that the problem here is that the old database was a MySQL 4.1 database (or older), and you can't install MYD/frm files from a 4.1 db on to a MySQL 5.0 database - the way to do that is to mysqldump the data and import it into the new database. The challenge here therefore is to find a MySQL 4.1 database, which probably involves installing a very old operating system.