Reputation: 8274
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.
Upvotes: 280
Views: 522834
Reputation: 5631
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.
You can also force the import command to import the table anyway despite this error (and any others) with the option --force
or -f
.
--force
Continue even if an SQL error occurs
Ref https://dev.mysql.com/doc/refman/8.4/en/mysqlimport.html
Upvotes: 376
Reputation: 21
In case someone is having a hard time trying to run Djando. I've found the inconvenience in seetings.py mysql connection
"OPTIONS": {
'init_command': "SET sql_mode='STRICT_TRANS_TABLES', innodb_strict_mode=1"
}
Give the permissions for your MYSQL user, (i don't really know if it the correct solution but it works for me...)
GRANT ALL PRIVILEGES ON *.* TO 'user'@'localhost' WITH GRANT OPTION;
Upvotes: 0
Reputation: 141
Simplest Soluction login: aws rds/ or other mysql server and assign required permissions, run below commands(you can change username and host)
GRANT SESSION_VARIABLES_ADMIN ON *.* TO root@'%';
GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO root@'%';
Upvotes: 2
Reputation: 91
Now you can grant SET_USER_ID
to the user which is running the import on a mysql RDS instance:
GRANT SET_USER_ID ON *.* TO 'import_user'@'%';
then you can run:
mysql -h xxxx.rds.amazonaws.com -u import_user -ppass db < db.sql
SET_USER_ID from mysql doc:
A user with this privilege can specify any account as the DEFINER attribute of a view or stored program
Upvotes: 0
Reputation: 397
Some SET statements might require privileges,so you can try removing them:
sed -i '/^SET/d' dump.sql
Upvotes: 0
Reputation: 379
My Problem: I want to dump the database from A provider to restore a database on the database cluster on B provider with MySQL version 8 both via DBeaver.
Solution: I follow this step was worked. I hope this solution will help you.
Remove DEFINER
GRANT ALL PRIVILEGES ON [database_name].* TO '[database_user]'@'[database_host]';
FLUSH PRIVILEGES;
Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/;
Upvotes: 0
Reputation: 11117
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' ...
Upvotes: 1
Reputation: 30113
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
Upvotes: 5
Reputation: 1
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
Upvotes: 0
Reputation: 1065
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.
Upvotes: 84
Reputation: 95958
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.....
sed -i '22d' all.sql
Import the data to your RDS:
mysql -h<host> -u<user> -p<password>
$ source all.sql
Upvotes: 1
Reputation: 641
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.
Upvotes: 1
Reputation: 1244
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
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 '+'*/ '';
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
Upvotes: 33
Reputation: 1
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.
Upvotes: -1
Reputation: 471
All the above solutions are fine. And here I'm gonna combine all the solutions so that it should work for all the situations.
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
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
Upvotes: 11
Reputation: 3801
When you restore backup, Make sure to try with the same username for the old one and the new one.
Upvotes: 3
Reputation: 323
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
Upvotes: 4
Reputation: 729
* 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! :)
Upvotes: 0
Reputation: 14477
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
Upvotes: 15
Reputation: 1964
I commented all the lines start with SET
in the *.sql
file and it worked.
Upvotes: 3
Reputation: 286
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
Upvotes: 23
Reputation: 80639
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
Upvotes: 385