Restore database in mysql command line - mysql

I have taken a backup of a database from one server and trying to restore it in another server.
Mysql version is 5.5
When I try to restore the database using the following command, screen -r
mysql -u root -p password mydb < mydump.sql
ERROR 1005 (HY000) at line 356: Can't create table 'mydb.mytable' (errno: 150)
I understand this is foreignkey constraint problem. The dump file has the following statement inside.
/*!40014 SET #OLD_FOREIGN_KEY_CHECKS=##FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
But it is still failing. My dumo file is very large is size, so opening it and editing is not possible. So instead of adding SET FOREIGN_KEY_CHECKS=0; in the dump, can I directly set it inside the mysql commandline like the following?
mysql> SET FOREIGN_KEY_CHECKS=0;
...
mysql> source "mydump.sql";
...
mysql> SET FOREIGN_KEY_CHECKS=1;
Will it work? My database reload takes hours to complete. So I am asking the help here before spending hours on this.
Thanks for the help.

Usually, I'll just pipe in 2 sql files -- first, a one-liner with SET FOREIGN_KEY_CHECKS=0;, and then dump file. You needn't worry about setting it back; it will only last for the current session (which will terminate when the files have been loaded).
FYI, you can also use sed -i 1i"SET FOREIGN_KEY_CHECKS=0;" dump.sql if you want to permanently prepend this line without visually editing the file.

Related

Update another table in MySQL when i use "source" command line

I have two database and i want to import/export form one to other with source command line.
The names of my databases is melka and demelka.
I want to copy form melka to demelka. for this i follow this steps:
Export from melka DB and save in D:/db/melka.sql and then run this command line
cd D:\wamp64\bin\mysql\mysql5.7.24\bin
mysql -u root
USE demelka;
source D:/db/melka.sql
But after executing the above commands, melka Table is updated And demelka Table is empty.
Environment:
I use WAMP 3.1.7
and mysql5.7.24
Thanks to #madhur-bhaiya
I am open my melka.sql file in editor and deleted the following commands from within and corrected them
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `melka` /*!40100 DEFAULT CHARACTER SET latin1 */;
USE `melka`;

Access denied; you need (at least one of) the SUPER privilege(s) for this operation

So I try to import sql file into rds (1G MEM, 1 CPU). The sql file is like 1.4G
mysql -h xxxx.rds.amazonaws.com -u user -ppass --max-allowed-packet=33554432 db < db.sql
It got stuck at:
ERROR 1227 (42000) at line 374: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
The actual sql content is:
/*!50003 CREATE*/ /*!50017 DEFINER=`another_user`#`1.2.3.4`*/ /*!50003 TRIGGER `change_log_BINS` BEFORE INSERT ON `change_log` FOR EACH ROW
IF (NEW.created_at IS NULL OR NEW.created_at = '00-00-00 00:00:00' OR NEW.created_at = '') THEN
SET NEW.created_at = NOW();
END IF */;;
another_user is not existed in rds, so I do:
GRANT ALL PRIVILEGES ON db.* TO another_user#'localhost';
Still no luck.
Either remove the DEFINER=.. statement from your sqldump file, or replace the user values with CURRENT_USER.
The MySQL server provided by RDS does not allow a DEFINER syntax for another user (in my experience).
You can use a sed script to remove them from the file:
sed 's/\sDEFINER=`[^`]*`#`[^`]*`//g' -i oldfile.sql
Remove the 3 lines below if they're there, or comment them out with -- :
At the start:
-- SET ##SESSION.SQL_LOG_BIN= 0;
-- SET ##GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
At the end:
-- SET ##SESSION.SQL_LOG_BIN = #MYSQLDUMP_TEMP_LOG_BIN;
Note that the comment characters are "dash dash space" including the space.
A better solution is to stop these lines from being written to the dump file at all by including the option --set-gtid-purged=OFF on your mysqldump command.
Another useful trick is to invoke mysqldump with the option --set-gtid-purged=OFF which does not write the following lines to the output file:
SET ##SESSION.SQL_LOG_BIN= 0;
SET ##GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET ##SESSION.SQL_LOG_BIN = #MYSQLDUMP_TEMP_LOG_BIN;
not sure about the DEFINER one.
When we create a new RDS DB instance, the default master user is not the root user. But only gets certain privileges for that DB instance. This permission does not include SET permission. Now if your default master user tries to execute mysql SET commands, then you will face this error: Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation
Solution 1
Comment out or remove these lines
SET #MYSQLDUMP_TEMP_LOG_BIN = ##SESSION.SQL_LOG_BIN;
SET ##SESSION.SQL_LOG_BIN= 1;
SET ##GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
Solution 2
You can also ignore the errors by using the -f option to load the rest of the dump file.
mysql -f <REPLACE_DB_NAME> -u <REPLACE_DB_USER> -h <DB_HOST_HERE> -p < dumpfile.sql
Just a MacOS extra update for hjpotter92 answer.
To make sed recognize the pattern in MacOS, you'll have to add a backslash before the = sign, like this:
sed -i old 's/\DEFINER\=`[^`]*`#`[^`]*`//g' file.sql
Problem: You're trying to import data (using mysqldump file) to your mysql database ,but it seems you don't have permission to perform that operation.
Solution: Assuming you data is migrated ,seeded and updated in your mysql database, take snapshot using mysqldump and export it to file
mysqldump -u [username] -p [databaseName] --set-gtid-purged=OFF > [filename].sql
From mysql documentation:
GTID - A global transaction identifier (GTID) is a unique identifier created
and associated with each transaction committed on the server of origin
(master). This identifier is unique not only to the server on which it
originated, but is unique across all servers in a given replication
setup. There is a 1-to-1 mapping between all transactions and all
GTIDs.
--set-gtid-purged=OFF SET ##GLOBAL.gtid_purged is not added to the output, and SET
##SESSION.sql_log_bin=0 is not added to the output. For a server where
GTIDs are not in use, use this option or AUTO. Only use this option
for a server where GTIDs are in use if you are sure that the required
GTID set is already present in gtid_purged on the target server and
should not be changed, or if you plan to identify and add any missing
GTIDs manually.
Afterwards connect to your mysql with user root ,give permissions , flush them ,and verify that your user privileges were updated correctly.
mysql -u root -p
UPDATE mysql.user SET Super_Priv='Y' WHERE user='johnDoe' AND host='%';
FLUSH PRIVILEGES;
mysql> SHOW GRANTS FOR 'johnDoe';
+------------------------------------------------------------------+
| Grants for johnDoe |
+------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `johnDoe` |
| GRANT ALL PRIVILEGES ON `db1`.* TO `johnDoe` |
+------------------------------------------------------------------+
now reload the data and the operation should be permitted.
mysql -h [host] -u [user] -p[pass] [db_name] < [mysql_dump_name].sql
Full Solution
All the above solutions are fine. And here I'm gonna combine all the solutions so that it should work for all the situations.
Fixed DEFINER
For Linux and Mac
sed -i old 's/\DEFINER\=`[^`]*`#`[^`]*`//g' file.sql
For Windows
download atom or notepad++, open your dump sql file with atom or notepad++, press Ctrl+F
search the word DEFINER, and remove the line DEFINER=admin#% (or may be little different for you) from everywhere and save the file.
As for example
before removing that line: CREATE DEFINER=admin#% PROCEDURE MyProcedure
After removing that line: CREATE PROCEDURE MyProcedure
Remove the 3 lines
Remove all these 3 lines from the dump file. You can use sed command or open the file in Atom editor and search for each line and then remove the line.
Example: Open Dump2020.sql in Atom, Press ctrl+F, search SET ##SESSION.SQL_LOG_BIN= 0, remove that line.
SET ##SESSION.SQL_LOG_BIN= 0;
SET ##GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET ##SESSION.SQL_LOG_BIN = #MYSQLDUMP_TEMP_LOG_BIN;
There an issue with your generated file
You might face some issue if your generated dump.sql file is not proper. But here, I'm not gonna explain how to generate a dump file. But you can ask me (_)
Issue
Below statement or line your Dump file creating issue
DEFINER=username#`%
Simple Solution
The solution that you can workaround is to remove all the entries from SQL dump file and import data from the GCP console.
cat DUMP_FILE_NAME.sql | sed -e 's/DEFINER=`<username>`#`%`//g' > NEW-CLEANED-DUMP.sql
above command will help to remove all those lines from the dump file and create the new fresh dump file without Definer.
Try importing new file(NEW-CLEANED-DUMP.sql).
If you are on AWS RDS
You might see face issue, if your dump file is larger you can check the first 20 lines using
head -30 filename
once you can see output look for line and line number
SET ##SESSION.SQL_LOG_BIN= 0;
SET ##GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET ##SESSION.SQL_LOG_BIN = #MYSQLDUMP_TEMP_LOG_BIN;
we will remove these lines by line numbers for example 17,18,24 line number
sed -e '24d;17d;18d' file-name.sql > removed-line-file-name.sql
For importing database file in .sql.gz format, remove definer and import using below command
zcat path_to_db_to_import.sql.gz | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | mysql -u user -p new_db_name
Earlier, export database in .sql.gz format using below command.
mysqldump -u user -p old_db | gzip -9 > path_to_db_exported.sql.gz;
Import that exported database and removing definer using below command,
zcat path_to_db_exported.sql.gz | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | mysql -u user -p new_db
When you restore backup, Make sure to try with the same username for the old one and the new one.
I commented all the lines start with SET in the *.sql file and it worked.
If it helps, when I tried to restore a DB dump on my AWS MySQL RDS, I got this error:
ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER,
SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation
I didn't have to change the DEFINER or remove/comment out lines. I just did:
GRANT SESSION_VARIABLES_ADMIN ON *.* TO myuser#'myhost';
GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO myuser#'myhost';
And I was able to do the restore.
None of the above solutions worked for me. I had to do the following:
Use the following flags with mysqldump:
mysqldump --databases <db1> <db2> --master-data=1 --single-transaction --order-
by-primary --foce -r all.sql -h<host> -u<user> -p<password>
Remove the line that looks like:
CHANGE MASTER TO MASTER_LOG_FILE='binlog.....
In my file, that was line #22, so I ran: sed -i '22d' all.sql
Import the data to your RDS:
mysql -h<host> -u<user> -p<password>
$ source all.sql
In my case (trying to execute a SQL file into AWS RDS) the beginning of my SQL statement looked like this:
DROP VIEW IF EXISTS `something_view`;
CREATE ALGORITHM=UNDEFINED DEFINER=`root`#`%` SQL SECURITY DEFINER VIEW `something_view`...
All I had to do to fix it was to remove ALGORITHM=UNDEFINED DEFINER='root'#'%' SQL SECURITY DEFINER part of the above statement.
So the new statement looks like this:
CREATE VIEW 'something_view' ...
* Answer may only be applicable to MacOS *
When trying to import a .sql file into a docker container, I encountered the error message:
Access denied; you need (at least one of) the SUPER privilege(s) for
this operation
Then while trying some of the other suggestions, I received the below error on my MacOS (osx)
sed: RE error: illegal byte sequence
Finally, the following command from this resource resolved my "Access Denied" issue.
LC_ALL=C sed -i old 's/\DEFINER\=`[^`]*`#`[^`]*`//g' fileName.sql
So I could import into the docker database with:
docker exec -i dockerContainerName mysql -uuser -ppassword table < importFile.sql
Hope this helps! :)
Issue in dump.
Please try to get dump by following way:
mysqldump -h databasehost --user=databaseusername --password --single-transaction databasename | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | gzip > /tmp/database.sql.gz
Then, try to import by following way:
zcat /tmp/database.sql.gz | mysql -h database_host -u username -p databasename
Need to set "on" server parameter "log_bin_trust_function_creators" on server side. This one you can easily find on left side blade if it is azure maria db.

Import Full MySQL Dump

I have exported a full backup of a database with HeidiSQL 7.
Now when importing it via PHPMyAdmin, I noticed that I MUST select the database information_schema, because that's how the DB is exported (Or this is how HeidiSQL 7 exports databases as objects to an SQL file?).
However, that is a problem because when I import (the exported file) with HeidiSQL 7 (instead of PHPMyAdmin), while selecting the information_schema database, and clicking on Import SQL file (from the tools menu), it says that access is denied for the root user.
In PHPMyAdmin, the option to import is not available when selecting the database information_schema.
How do I import my full database dump? (This is how I exported it: HeidiSQL > export database objects to SQL file)
Edit:
I tried it with the command line, but without luck:
C:\Programs\XAMPP\mysql\bin>mysql --verbose --user=root Information_schema < DT.
sql
--------------
/*!40101 SET #OLD_CHARACTER_SET_CLIENT=##CHARACTER_SET_CLIENT */
--------------
--------------
/*!40101 SET NAMES utf8 */
--------------
--------------
/*!40014 SET FOREIGN_KEY_CHECKS=0 */
--------------
--------------
/*!40000 ALTER TABLE `CHARACTER_SETS` DISABLE KEYS */
--------------
ERROR 1044 (42000) at line 13: Access denied for user 'root'#'localhost' to data
base 'information_schema'
C:\Programs\XAMPP\mysql\bin>
This is a snippet of the SQL file:
http://pastebin.com/6hwhK2CJ
Note: The password for my root user is blank.
Maybe another solution for my problem:
How do I import only the database I want, from the SQL file? For example a database with the name "Employees"? Because that SQL file should contain a few databases.
Edit2:
(answer to first comment)
I downloaded MySQL Workbench, setup the connection...
03:23:08 Restoring C:\Files\DB.sql
Running: mysql.exe --defaults-extra-file="c:\files\temp\tmplnjwd6.cnf" --host=localhost --user=root --port=3306 --default-character-set=utf8 --comments < "C:\\Files\\DB.sql"
ERROR 1046 (3D000) at line 13: No database selected
Operation failed with exitcode 1
03:23:08 Import of C:\Files\DB.sql has finished with 1 errors
INFORMATION_SCHEMA is a pseudo, read-only database (in fact, it is an "ANSI standard set of read-only views").
You need to remove all dump data related to this pseudo database, as there is absolutely no way to import it.
Notepad++ is able to easily handle a 9 MB file, and also provides nice syntax highlighting.

Mysqldump with InnoDB tables, how to import them without errors?

I've exported a mysqldump of a database with InnoDB tables and foreign key relationships in them, using the --single-transaction flag (that I read somewhere I should use for InnoDB). No problems.
But when trying to import that dump into another existing database (same database, different server) I get all sorts of errors when trying to drop the tables because it would break the InnoDB relationships.
I also read that I should use foreign_key_checks=0 to avoid this, but this is a server variable, not part of the dump process. So I'm trying to figure out how to automate all this since I have a script that backs up the DB, it was working when all we had were MyISAM tables:
mysqldump -u user -p'password' --single-transaction -q database | ssh user#backup.com mysql -u user -p'password' database
Thanks.
You can dump into a file, add the required SET FOREIGN_KEY_CHECKS=0; in that file, and then feed the file to mysql.
It turns out that the mysqldump file is smart enough to detect that they are InnoDB tables and puts the appropriate comments at the top of the file. My problem was that when I exported through PHPMyAdmin it didn't put the correct comments on the file, hence causing all this trouble.
Thanks for your response.
You can also add to the mysql command line when restoring without editing the original file. This is very useful as mysql backups can become huge, and editing a GB+ file takes lots of CPU time versus adding this to the commandline,
mysql -D YourDatabaseName -u YourUserName -p --init-command="set ##foreign_key_checks=0"<YourBackupDumpFile.sql

Skip database on import of MySQL dumpfile

I created a dumpfile with this command:
mysqldump -p3307 --quick -u root --password="password" --all-databases > all_databases04292011.sql
I then attempted to import this dumpfile into a new MySQL server, however it fails trying to write to the information_schema database. Is there a way to skip this database on import?
You can write a program editing the all_databases04292011.sql dumpfile, to delete all the records in information_schema database.
It is not that hard, since the dumpfile is well structured.
Just open all_databases04292011.sql using your favourite editor, then find
--
-- Current Database: `information_schema`
--
Delete every line below this until you see the next
--
-- Current Database: `xxxxxx`
--