i'm migrating my website from a shared hosting to a VPS.
I setup all (files, mail, etc) and now i'm migrating database.
In phpmyadmin I export database to my pc, but when i trying to import database in new host (with phpmyadmin) i have only 12 tables of 47. I tried all avaible options, i tried with compression... I checked also table and these are not correctly populated. In the past i do this operation so many time without problem and i don't understand what can be.
Please can you help me?
I've found that sometimes PHPMyAdmin has issues with large files. This might be corrected by tweaking PHP's settings in php.ini (extend timeout, raise upload_max_filesize), but it may just be easier to upload the sql file to the server and import it via the command line.
Related
I've been working on a project for a couple of months now with a few other developers and it has got to the point where we all have different changes to the DB we are working with, but all of the changes are local, meaning the server is out of sync with all of our local changes.
What is the best way to handle this? At the moment I tried to basically export my database from my local PC with phpMyAdmin and import that .sql file into the database on the server but as some of the tables already exist on the server it just gives out an error...
Would I have broken my database on the server by trying to import that sql file?
What do I do?
Ok so here's what I would do in your position...
Use this tool: http://www.clevercomponents.com/downloads/dbc/dbcdownload.asp
With the database compare tool, it should identify the differences in structure between two databases.
This generates an SQL file which will alter the target (your server) database to match the master (your local).
Always backup your target database before attempting something like this, just in case it goes wrong.
I am importing a mysql database from the webserver to my local system for a migration from drupal 6 to drupal 8.
I did an Export with phpmyadmin on the server. Then I created the database locally also with phpmyadmin and imported my dump from the server via phpmyadmin's import function.
Then I created the user with the setting of my drupal 6 configuration.
I can see the database in phpmyadmin if I connect with my local root user.
I cannot connect with the user created from the settings ( lets call that the drupal_db_user)
If I call the drupal site on my local apache ( apache & mysql server are running or my phpmyadmin would not work) I get the messeage from drupal:
"The mysqli error was: Unknown database 'my_drupal_db'."
Via Mysqlworkbench I am also not able to conntect to the my_drupal_db with the drupal_db_user.
I use locally php 5.6 and mysql 5.6 on a ubuntu system.
Creating the user and db via mysql console also did not help.
Any clue what might be wrong here? I suspect it could be the password encryption, but I have no clue how to check / change that other than trying the two options phpmyadmin (version 4.6) is offering me.
I guess you dont need to backup on your pc as the files that you exported from server is a backup on its own. Just download the sql file update to drupal 8 and finally import the file and you should have it installed.
Or simply try importing the exported file from server to another subdomain drupal 8 as a test. To check If it really works.
Found the problem.
after at least 3 hours poking around and cursing.....
When I created the database locally I had by mistake an whitespace in front of the db name.
Which by the way was possible... I didn't know you could even create databases with whitespaces in the name.
What let me find the error was this post:
https://drupal.stackexchange.com/questions/27050/fatal-error-pdoexception-sqlstate42000-1049-unknown-database
and the hint with this query:
SELECT * FROM my_drupal_db.users
which of course failed and made me really question the database name.
Hope that helps someone else saving 3 hours!
I normally migrate databases for wordpress installs using wp_sync_db plugin. It has never failed before. Now when I'm trying to migrate from my local development server to the live site it's giving the following error.
I've tried only migrating specific fields, but it always runs into an error, just the field will be different.
I've tried to manually import the database to the live site and that is also failing with this error:
I'm not a database expert, and this is really frustrating. I have about two days of work I'm trying to migrate to the live site and can't do it with these errors.
I've been working on trying to solve this issue for a few hours, but have got no where. I've tried deleting the fields mentioned in the error, but that changes nothing. I've tried about 1000 different variations and configurations and it just keeps failing.
Please some database expert step in and save me!
I have no idea about the wp_sync_db plugin, but the phpMyAdmin error comes from having an older version of MySQL on your host which doesn't support the utf8mb4_unicode_ci collation.
You could look for the "Database system or older MySQL server to maximize output compatibility with:" dropdown on the phpMyAdmin export page, then select MYSQL40 there, but you run the risk of losing data if you have multibyte characters stored in your database.
This support page has a good summary of the situation and strongly suggests that you make your local MySQL version match as closely to your hosted version as possible, but that seems like a harsh reality in which to develop. I'm not a WordPress expert, but I believe that if you export for MYSQL40 compatibility and check the resulting imported data for any flaws you should be relatively safe.
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.