I try to insert some lines from csv file to MySQL database "elevage" by command line. The file is names "animal.csv". Below is my request:
`mysql> LOAD DATA LOCAL INFILE 'F:/MYSQL/animal.csv'
-> INTO TABLE Animal
-> FIELDS TERMINATED BY ';' ENCLOSED BY '"'
-> LINES TERMINATED BY '\r\n'
-> (espece, sexe, date_naissance, nom, commentaires);
and I run into this error message
`ERROR 3948 (42000): Loading local data is disabled; this must be enabled on both the client and server sides`.
Then have used the following code:
`SHOW GLOBAL VARIABLES LIKE 'local_infile'`;
and I found: local_file was "OFF". Then I tried to set it to "ON" using the following code :
`SET GLOBAL local_infile=1;`
Unfortunately, I run into another error message:
`ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation`
Although, when I check the grants for the user "student" in which I'm working:
mysql> SHOW GRANTS FOR CURRENT_USER();
I get:
+--------------------------------------------------------------+
| Grants for student#localhost |
+--------------------------------------------------------------+
| GRANT USAGE ON *.* TO `student`#`localhost` |
| GRANT ALL PRIVILEGES ON `elevage`.* TO `student`#`localhost` |
+--------------------------------------------------------------+
2 rows in set (0.00 sec)
which means that "student" has all the privileges on the database "elevage".
Please advice.
The SYSTEM_VARIABLES_ADMIN privilege (as well as the deprecated SUPER privilege) is not a per-database privilege, but rather a per-server privilege. And, it's an administrators' privilege, not a users' privilege.
Why do you need such privileges to use LOAD DATA? Because that command requires its user to write files directly into the database server machine's file space. So users of that command must be completely trusted by the database server.
To use LOAD DATA LOCAL you'll need to get a server administrator to grant those privileges to you, with something like this:
GRANT SUPER, SYSTEM_VARIABLES_ADMIN ON *.* TO 'student'#'localhost';
If this is a shared server, it seems unlikely that your administrator will grant you this privilege. If it's your own server, you are the administrator, and you can use your root account either to grant your student account the privilege, or use the root account directly to run your LOAD DATA command.
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.
I have not been introduced to mysql, but had to work with it. I installed it and tried to run this:
mysql> CREATE TABLE h7vsk1200001 (quid VARCHAR(15), suid VARCHAR(15), iden FLOAT, alen INT, mism INT, gapo INT, qsta INT, qend INT, ssta INT, send INT, eval FLOAT, bits INT);
Which I understand is the basis for a table, with its names for columns and its datatypes. Whenever I run it, I get this error message:
bash: error sintáctico cerca del elemento inesperado `('
By the way, I'm using Ubuntu 14.04 if that matters. Also, if I try to run the CREATE TABLE command without arguments I get:
$ mysql> CREATE TABLE
ERROR 1045 (28000): Access denied for user 'carlos'#'localhost' (using password: NO)
Consider that I have little experience with bash and no experience with mysql (as you may have denoted)
You first need to launch the mysql shell. You can't run queries like this in bash: you need to use a MySQL client. You're getting the first error because bash is trying to parse the parentheses, and the second error is the result of you running the mysql command while piping (>) the output to a new file called CREATE.
Note you're getting the ACCESS DENIED because you apparently don't have access as the user carlos without a password. Use mysql -u myusername -p to log in with username myusername and to have mysql prompt for a password.
thom#lethe-arch:~$ # bash shell
thom#lethe-arch:~$ mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 443
Server version: 10.0.14-MariaDB-log MariaDB Server
Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| test |
+--------------------+
2 rows in set (0.01 sec)
mysql> -- type queries here
(Note: MariaDB is a fork of MySQL and behaves exactly the same)
Seems you have to create a user 'carlos' and allow necessary permissions like:
mysql> use mysql;
mysql> CREATE USER 'carlos'#'localhost' IDENTIFIED BY 'yourpassword';
mysql> GRANT ALL PRIVILEGES ON . TO 'carlos'#'localhost' WITH GRANT OPTION;
When I try to change the priveleges on a mysql db I get the following error:
Please make sure the used account has rights to the MySQL grant tables. Error executing 'DESCRIBE mysql.db'
Is this also why it will not let me import tables in from another DB? When i try I get the error:
Operation failed with exitcode 1
09:20:16 Restoring D:\design and photos\boo.com\db dump\070113.sql
Running: mysql.exe --defaults-extra-file="c:\users\darren\appdata\local\temp\tmpslubjs.cnf" --host=87.117.239.19 --user=boo8_yu52 --port=3306 --default-character-set=utf8 --comments < "D:\design and photos\boo.com\db dump\070113.sql"
ERROR 1044 (42000) at line 1: Access denied for user 'boo8_yu52'#'%' to database ' boo8_6652'
It does however let me create tables manually. Can't work it out at all.
make sure that the account you are using is granted with grant option
and the account should have permissions on mysql database in which the db grant table exits
or the best way is to assign the permission with the root account
see the link below may be useful for you
http://blog.loftninjas.org/2008/04/22/error-1044-42000-at-line-2-access-denied-for-user-root-to-database-db/
I have searched and found this post (http://stackoverflow.com/questions/1814297/cant-load-file-data-in-the-mysql-directory) but it is not working for me.
i am un Ubuntu 12.04 and MySQL version is 5.5.22-0ubuntu1
I have logged into MySQL as root and so grants should all be okay:
mysql> show grants;
+---------------------------------------------------------------------+
| Grants for root#localhost |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'#'localhost' WITH GRANT OPTION |
| GRANT PROXY ON ''#'' TO 'root'#'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+
I am trying to insert some data from a text file into a MySQL database and the LOAD_FILE function doesn't seem to work properly
I created a test file, permissions of 777 and copied to root of the install (I tried changing owner/group to root:root and mysql:mysql and still no good):
mysql> select load_file('/test.txt');
+------------------------+
| load_file('/test.txt') |
+------------------------+
| NULL |
+------------------------+
1 row in set (0.00 sec)
But if I try this:
mysql> select load_file('/etc/hosts');
It works fine. If I copy the test file into /etc it still fails.
has anyone seen this before or can perhaps point me to another way to load into the database?
To use load_file, the following conditions must be met (from the documentation):
The file must be located on the server host
You must specify the full path name to the file, and you must have the FILE privilege.
The file must be readable by all and its size less than max_allowed_packet bytes.
If the secure_file_priv system variable is set to a nonempty directory name, the file to be loaded must be located in that directory.
If the file contains SQL statements that you want to execute, an easier approach might be to pipe it in:
mysql -u foo -p dbname < filename.sql
Im not an expert on MySQL, but ive observed that MySQL version 5.5 has a problem with UBUNTU OS.
Even after following the documentation in mysql docs LOAD_FILE() didnt work.
There is a service called apparmour, preventing the function LOAD_FILE() from executing, i tried stopping that service but still it persisted.....
I know this doesnt solve your problem, but at least it'll help u find where the problem is......
Consider this one-liner (note, I'm on Ubuntu):
printf "$(cat update_xml.sql)" "$(cat my.xml | sed s/"'"/"\\\'"/g)" | mysql -h myRemoteHost -u me -p***
In update_xml.sql there is:
UPDATE
myTable
SET
myXmlColumn = '%s'
WHERE
...
Adding this for future reference. Probably won't help the OP.
As noted before, AppArmor is to blame. You need to whitelist the paths needed for load_file into the provided profile which can be found here: /etc/apparmor.d/usr.sbin.mysqld. The apparmor.d documentation can be found here. This is the recommended way as AppArmor has its reasons to be there.
Alternatives:
This is the unrecommended method. Disable the usr.sbin.mysqld profile so you won't expose all the services. Simply link the profile to /etc/apparmor.d/disable with ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/usr.sbin.mysqld. Reload the profiles with /etc/init.d/apparmor restart. It probably makes sense for a development machine.
This is the highly unrecommended method, if you don't actually need AppArmor. The profiles can be unloaded with /etc/init.d/apparmor teardown. Disable the init script with update-rc.d -f apparmor remove.
All the above stuff requires root privileges, but I skipped the ever repetitive sudo in front of all the commands.